--- title: "Capability: MCP gateway" canonical_url: "https://tokenobserve.com/platform/mcp-gateway" published: 2026-09-02 last_updated: 2026-10-21 --- # Capability: MCP gateway The half of an agent that moves money is a tool call, not a sentence. This is the checkpoint that call goes through. ## What it is This describes customer-hosted upstream tool governance. The initial cloud environment disables arbitrary MCP destinations; hosted first-party reports use the workspace MCP endpoint and current report grants. Token Observe’s MCP gateway is one Streamable HTTP endpoint in front of every registered upstream Model Context Protocol server, and the same policy engine that governs a model call governs a tool call. Tools reach an agent namespaced server.tool and filtered to its grants, and every call is authorised again at execution, because filtering a list is a usability feature and a client can guess a name. Each descriptor is hashed when an operator approves it and re-checked on every refresh, so one rewritten upstream is quarantined. ## Facts - Transport: Streamable HTTP, spec 2025-11-25 down to 2025-03-26 - Authorisation: Re-derived from the token; sessions hold no permissions - Tool integrity: Descriptor hashed at approval; drift quarantines - Inspection bounds: Depth 32, 5,000 nodes, 65,536 characters ## The limit Only refuses what it is shown: A tool call routed around it is not governed here ## Why it exists: Governing the model call governs the half that only produces text. The half of an agent that moves money, writes to a system of record or emails a customer is a tool call, and in most deployments it goes straight from the agent’s process to the upstream server: no permission check outside the agent’s own code, no record an auditor can read, and no way for a rule about refunds to bind when one is issued. The tools themselves are the second problem, because they are an instruction surface. A tool’s name, description and input schema are text the model reads and obeys, so an upstream that changes them rewrites what your agent believes it is doing without touching a line of your code. The version that matters is patient: a tool that behaved for six weeks, then acquired a new sentence. ## How it works - Answer the list with the pinned, granted, inspected subset: Authority is re-derived from the bearer token on every request; sessions carry no permissions. The catalogue is every enabled upstream server’s tools, namespaced server.tool and filtered to the caller’s grants, and each descriptor is scanned in its own right, so one carrying a credential or matching the injection heuristics is withheld rather than shipped into the model’s context. - Re-authorise the call, and answer an invisible tool as unknown: The call path checks permissions again from scratch. Existence and visibility collapse into one answer: a tool that does not exist and a tool this agent was never granted both return unknown tool, because confirming a tool exists is an inventory disclosure. The probe is still traced. - Inspect the arguments, then decide with the same evaluator: The whole argument tree is walked under one budget, and crossing any bound refuses the call rather than forwarding an uninspected remainder. Then kill switch, lifecycle, permissions intersected across every hop, budget and rate ceilings, and policies in priority order. - Scan what comes back, then deliver it: The result is inspected under the same bounds and re-evaluated against data-class and injection rules only, so a rate rule or an approval just satisfied does not fire twice. A refusal on the way back is terminal and says so, because the tool has already run. ## Where it runs in the request path The whole request path, run on a tool call ## What it does not do - Token Observe cannot refuse a tool call that never reaches it. Evaluating the calls a model proposes extends the reach to agents that execute tools themselves, but that is defence in depth rather than a guarantee. - An unpinned tool is not blocked. Refusing every unreviewed tool would make the gateway unadoptable, so an unreviewed tool stays callable and is described to the model as unverified. - A quarantine screen cannot show you a diff. Only the hash of the approved descriptor is stored, not its text, so what changed cannot be reconstructed; the console shows the descriptor as it reads now and says so. - Non-text tool output is withheld, not inspected. Images, audio, blobs and fetched resources are refused after the tool has already run, because there is no bounded media decoding or OCR on this path. A result whose JSON keys carry something the redaction plan covers is withheld rather than repaired, for the same reason a key is never rewritten on the way out. - Injection scoring on a tool result is nine fixed weighted patterns with a 1.25× multiplier, not a classifier. A novel phrasing that matches none of them scores zero. - Trace event content is capped and summarised past roughly sixteen thousand characters. One enormous payload is recorded as evidence that it happened rather than kept whole. ## Read next - https://tokenobserve.com/platform/agent-permissions - https://tokenobserve.com/platform/effect-contracts - https://tokenobserve.com/platform/shadow-ai-radar ## Questions and answers Q: Why does the gateway check permissions twice? A: Because filtering a tool list is a usability feature, not access control: a client can call a name it was never shown, so the call path re-evaluates from scratch. A tool the agent cannot see returns the protocol error unknown tool, without distinguishing “does not exist” from “not yours”, because confirming existence is an inventory disclosure. A tool it can see but may not use returns an error-flagged result the model can act on. Q: What happens when an upstream tool’s description changes? A: It is quarantined on the next catalogue refresh and refused until a human approves it again: the mismatch hides the tool, records the drift with both hashes, publishes an event and raises a high-severity radar finding. Unpinned tools are treated differently on purpose: they stay usable, and their description tells the model the descriptor is unverified. Q: Does the gateway govern tool calls an agent executes itself? A: Not directly, and Token Observe is explicit about it. When a model proposes a tool call, the model gateway evaluates that proposal against the same rules before returning the response, so a refunds rule binds whether or not execution is routed here. That is defence in depth rather than a guarantee: it can only refuse a proposal it is shown. The long-form detail on this capability (the anchored sections, the worked policies and the error envelopes) is on the page itself at https://tokenobserve.com/platform/mcp-gateway.