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-remotethat connects to ThornGuard on the client’s behalf
x-thornguard-licensefor ThornGuard authx-mcp-target-urlfor upstream routing
Compatibility Snapshot
| Platform / Mode | Works Today | Notes |
|---|---|---|
| VS Code / Copilot | Yes | Best current fit for direct remote setup with http/sse, headers, and secure inputs/env support |
| Cursor | Yes | Good fit for remote URL + headers, environment-backed variables, and dynamic registration |
| Zed | Yes | Good fit for custom MCP servers with url, headers, and tool permission controls |
| Claude Desktop | Yes, via bridge | Commonly used through mcp-remote |
| Native OAuth-only remote connector flows | Partial | Not yet first-class until ThornGuard stops depending on client-supplied x-mcp-target-url and fully productizes OAuth-based onboarding |
| Protecting an MCP server you operate | Yes, with setup | Supported today by routing clients through ThornGuard first |
Recommended Setup Patterns
Direct HTTP Setup
Use this when your client lets you configure:- a remote MCP URL
- custom headers
- optional environment-backed secrets
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.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.