​

MCP Gateway

The Model Context Protocol (MCP) lets agents call tools on MCP servers. KnoxCall puts those calls behind the same governance as the rest of your AI egress — so an agent presents a short-lived, sender-constrained KnoxCall token instead of a long-lived server credential, and every tools/call is screened before it reaches the upstream. Point an MCP client at https://<your-slug>.knoxcall.com/v1/mcp/<server-slug>.

​

What it governs

For a request through an MCP server, the gateway:

• initialize / ping / discovery — pass through to the upstream.
• tools/list — returns only the tools your allowlist permits (intersected with the token’s tool scope). Tools you haven’t allowed are never advertised.
• tools/call —
  1. Authorizes the tool against the allowlist — a call to a tool that isn’t allowed is rejected with a JSON-RPC error and never forwarded.
  2. Screens the arguments through the prompt firewall — an injection attempt in a text argument is blocked.
  3. Redacts PII in the arguments before forwarding, so sensitive data never reaches the upstream MCP server.
  4. Forwards the (redacted) call to the upstream.
  5. Redacts PII in the result on the way back to the client.

Every governed call is recorded (ai_gateway_mcp_calls) with its outcome and PII-redaction counts, and emits alertable audit actions (ai_gateway.mcp_tool_call / mcp_tool_blocked / mcp_pii_redacted).

​

The credential

MCP tool access uses a tool-bound phantom token (kind tool), DPoP-bound by default — sender-constrained, short-lived, and revocable. This is the credential the MCP spec recommends and that almost nobody productizes: your agent never holds the upstream server’s key, and a leaked token is useless without its DPoP key.

​

Discovery & audience-bound tokens (OAuth 2.1)

A standards-compliant MCP client (Claude Code, Claude Desktop, Cursor) auths without any KnoxCall-specific wiring:

1. Protected-resource metadata — RFC 9728. On a 401, the client fetches:
   GET https://<your-slug>.knoxcall.com/.well-known/oauth-protected-resource/v1/mcp/<server-slug>
   
   which returns the authorization server to use and that tokens must be DPoP-bound:
   {
     "resource": "https://<your-slug>.knoxcall.com/v1/mcp/<server-slug>",
     "authorization_servers": ["https://<your-slug>.knoxcall.com"],
     "bearer_methods_supported": ["header"],
     "dpop_bound_access_tokens_required": true,
     "dpop_signing_alg_values_supported": ["ES256"]
   }
   
2. Authorization-server metadata — RFC 8414. The client reads https://<your-slug>.knoxcall.com/.well-known/oauth-authorization-server to find the token endpoint.
3. Resource-indicated token — RFC 8707. When exchanging a workload identity for a token at /v1/oauth/token, the client passes a resource naming the exact MCP server:
   resource=https://<your-slug>.knoxcall.com/v1/mcp/<server-slug>
   
   The minted token is audience-confined to that resource — bound into its capability HMAC, so a token issued for /v1/mcp/weather cannot be replayed against /v1/mcp/payments. The resource must name an MCP server on your own domain; a foreign or malformed resource is rejected. Multiple resource indicators are not supported — pass exactly one.

​

Two kinds of MCP server

• Upstream — proxies an external MCP server (its transport + URL), governed as above.
• Collection — synthesizes MCP tools from a KnoxCall route collection: each governed route becomes a tool, executed through the existing proxy (secret injection, rate limits, sandbox, audit — all unchanged). Expose the APIs you already run as MCP tools with zero new execution machinery.

Register servers + tools under the gateway’s MCP tab.