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.

Use this pattern when you operate an MCP server and want ThornGuard to sit in front of it as a managed security layer. Examples:
  • an internal MCP server shared with your team
  • a vendor-operated remote MCP server exposed to customers
  • an MCP endpoint that needs auditing, approvals, or PII redaction before client traffic reaches it

​
Current Supported Pattern

Today, ThornGuard protects an existing upstream MCP endpoint by having clients connect to ThornGuard first and identify the real upstream with x-mcp-target-url. 
MCP Client -> ThornGuard -> Your MCP Server
At a high level:
  1. Your MCP server keeps running at its existing upstream URL.
  2. Clients connect to https://thorns.qwady.app/mcp.
  3. Clients authenticate to ThornGuard with the primary ThornGuard license key plus that client’s activation proof.
  4. Clients tell ThornGuard which upstream MCP server to reach through x-mcp-target-url.
  5. ThornGuard enforces auth, policy, rate limits, approvals, redaction, and audit logging before the request reaches your service.

​
What You Get Today

  • a managed security layer in front of an existing MCP service
  • audit visibility for every client request
  • data loss prevention on responses
  • policy controls and approval flows
  • activation-aware auth and rate limiting

​
Preferred Setup: Service Profile Through the CLI

If you want the safer local-launch path, create a service profile first: 
npm install -g @thornguard/cli
thornguard auth login
thornguard profile add my-protected-server \
  --kind service \
  --target-url https://mcp.your-company.com/mcp \
  --vendor-name "Your Company" \
  --status-page-url https://status.your-company.com \
  --intel-enabled
Then print client-specific config: 
thornguard print-config --client claude my-protected-server
thornguard print-config --client vscode my-protected-server
This keeps the stable launcher command in the client config while ThornGuard and upstream credentials stay local to the machine.

​
Example Client Configs

​
Direct HTTP Client

{
  "servers": {
    "myProtectedServer": {
      "type": "http",
      "url": "https://thorns.qwady.app/mcp",
      "headers": {
        "x-thornguard-license": "Bearer THORN-YOUR_LICENSE_KEY",
        "x-thornguard-activation-id": "YOUR_ACTIVATION_ID",
        "x-thornguard-activation-proof": "YOUR_ACTIVATION_PROOF",
        "x-mcp-target-url": "https://mcp.your-company.com/mcp"
      }
    }
  }
}

​
Claude Desktop via mcp-remote

{
  "mcpServers": {
    "myProtectedServer": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://thorns.qwady.app/mcp",
        "--silent",
        "--header",
        "x-thornguard-license:${THORNGUARD_LICENSE_HEADER}",
        "--header",
        "x-thornguard-activation-id:${THORNGUARD_ACTIVATION_ID}",
        "--header",
        "x-thornguard-activation-proof:${THORNGUARD_ACTIVATION_PROOF}",
        "--header",
        "x-mcp-target-url:${THORNGUARD_TARGET_URL}"
      ],
      "env": {
        "THORNGUARD_LICENSE_HEADER": "Bearer THORN-YOUR_LICENSE_KEY",
        "THORNGUARD_ACTIVATION_ID": "YOUR_ACTIVATION_ID",
        "THORNGUARD_ACTIVATION_PROOF": "YOUR_ACTIVATION_PROOF",
        "THORNGUARD_TARGET_URL": "https://mcp.your-company.com/mcp"
      }
    }
  }
}
Prefer the CLI-managed profile path over raw bridge JSON whenever possible. Even env-backed bridge configs are still local client configs and are easier to mis-handle than the stable thornguard run <profile> launcher flow.
If you are not using the CLI, create the client activation first with POST /api/license/activations/ensure and keep the returned activation_id plus activation_proof local to that one client instance.
  • Use HTTPS-only upstream MCP endpoints
  • Keep your upstream MCP server protected even if ThornGuard sits in front of it
  • Scope ThornGuard credentials per team or environment
  • Rotate upstream credentials and ThornGuard credentials on a schedule
  • Avoid long-lived copied secrets in client configs whenever OAuth or managed secret storage is available
  • Treat audit export destinations and webhook consumers as sensitive systems

​
What Still Needs Product Work

The current flow works, but it is not yet the ideal onboarding experience for MCP service owners. Current gaps:
  • server registration in the dashboard instead of raw x-mcp-target-url
  • stable protected URLs per upstream connection
  • better native support for OAuth-based remote connector platforms
  • first-class storage and rotation for upstream credentials