Skip to main content

Documentation Index

Fetch the complete documentation index at: https://qwady.wiki/llms.txt

Use this file to discover all available pages before exploring further.

ThornGuard is not Claude-only. It works today with most developer-managed MCP clients that support either a remote MCP URL plus custom headers or a local bridge command.

​
Current Support Model

ThornGuard works best today with one of these patterns:
  • Direct remote HTTP setup with a URL and custom headers
  • Local stdio bridge such as mcp-remote that connects to ThornGuard on the client’s behalf
The current public deployment now prefers:
  • x-thornguard-license for ThornGuard auth
  • x-thornguard-activation-id for the active client instance
  • x-thornguard-activation-proof for that activation’s local proof-of-possession
  • x-thornguard-session-id for managed session binding
  • a managed protected URL such as /mcp/:connection-id
Legacy compatibility path:
  • /mcp plus x-mcp-target-url for upstream routing
OAuth / JWT support exists as an additive path, but it is deployment-configured and is not the default public onboarding flow today.

​
Compatibility Snapshot

Platform / ModeWorks TodayNotes
VS Code / CopilotYesVerified CLI launcher path today. Direct remote HTTP also works when the MCP surface accepts a URL plus custom headers
CursorYesVerified CLI launcher path today, with direct remote HTTP available in header-capable MCP setups
ZedYesVerified CLI launcher path today. Manual remote HTTP depends on a header-capable MCP configuration surface
Claude DesktopYesVerified local launcher / bridge path today
WindsurfYesVerified CLI launcher path today
ClineYesVerified CLI launcher path today. Config written to Cline’s globalStorage settings
ContinueYesVerified CLI launcher path today. Config written to ~/.continue/config.json
Direct remote MCP clientsYesBest on managed protected URLs; legacy header-routed remote HTTP still works during migration
Native OAuth-only remote connector flowsPartialStill not fully first-class until actor-scoped OAuth onboarding and connector UX are productized end to end
Protecting an MCP server you operateYes, with setupSupported today by routing clients through ThornGuard first

​
Direct HTTP Setup

Use this when your client lets you configure:
  • a remote MCP URL
  • custom headers
  • optional environment-backed secrets
This is the cleanest current setup for editors and service entry points that can supply a remote MCP URL plus custom headers. Prefer a managed protected URL for saved connections whenever possible.

​
Local Bridge Setup

Use this when your client expects to launch a local command instead of talking directly to a remote HTTP MCP server. This is the common pattern for Claude Desktop today and the most reliable universal path when you want ThornGuard to generate the exact client-specific launcher shape for Claude Desktop, VS Code, Cursor, Zed, Windsurf, Cline, or Continue.

​
Security Notes

  • Prefer secret inputs, environment files, or keychain-backed storage over hardcoded tokens in config files.
  • Local bridge tools may log CLI-passed headers before traffic reaches ThornGuard.
  • ThornGuard sanitizes secrets in its own audit trail and webhook deliveries, but it cannot sanitize logs emitted locally by the MCP client or bridge tool.
  • The ThornGuard CLI (@thornguard/cli) uses platform-native secure storage: macOS Keychain, Linux Secret Service (secret-tool), and Windows DPAPI. A plaintext file fallback is available as an explicit opt-in for environments without keyring support.

​
If You Operate the Upstream Service

If you are protecting an MCP service you own, see Protect Your MCP Server.