Transports and profiles
MCP protocol versions that the PEP accepts, upstream transports, protocol setup and the tool list that the gateway answers.
Several MCP versions are in use at the same time, and they do not describe a call the same way. Version 2026-07-28 repeats the method and the tool name in HTTP headers (Mcp-Method, Mcp-Name). The 2025 versions use only the body. A gateway that accepted both forms mixed would leave room for a message with one name in the header and another in the body, where the PEP authorizes one tool and the server runs another.
So the PEP reads the declared version and selects a single decoder, with no second attempt:
| Declared profile | How the PEP reads the message |
|---|---|
2026-07-28 | Requires MCP-Protocol-Version, Mcp-Method and Mcp-Name consistent with the body |
2025-03-26, 2025-06-18, 2025-11-25 | Reads from the body; rejects Mcp-Method and Mcp-Name |
| No version header | Assumes 2025-03-26, provided there is no modern metadata |
| Unsupported or mixed | Rejects with 400 |
From Xokepoint to the server
On the server side, Xokepoint speaks Streamable HTTP or the original HTTP+SSE. The transport is detected when the server is discovered and is recorded in the review. stdio is not supported, because the server must be on the network for Xokepoint to sit in the path.
The agent and the server negotiate versions independently. An agent on the new version can call an old server, and Xokepoint adapts the tool call between the two, without pretending that the old server implements features that exist only in the new version.
Setup and the tool list
Before calling tools, the client runs setup and discovery: initialize and tools/list in the 2025 versions, server/discover and tools/list in the 2026 version. Every enabled server accepts them, with no setting, after authentication and validation and without going to the PDP.
- Setup.
initializeandserver/discovergo to the server, but Xokepoint answers as the gateway. It announces onlytools, the only family it serves, so a compliant client calls nothing else. It drops the serverinstructions, which a harness would put in the context of the model without review, and names the server as it is in the registry instead of the upstream name and version. - Tool list. Xokepoint answers
tools/listitself, and the request never reaches the server. The list has only the tools that the agent may call: each reviewed and enabled tool for which the delegation of the subject and the capability of the agent pass in OpenFGA, narrowed by theauthorization_detailsof the token. Each tool comes with the definition that the administrator reviewed, never the current text of the server. The list is one page, is not recorded in Investigate, and in version 2026 is marked private and not cacheable.
A tool in the list is not a permission to run it. tools/call always goes to the PDP, in any version, with conditions and resources. The choice also uses the validated JSON-RPC method, never a header alone.
What Xokepoint does not serve from MCP, and why
In MCP every capability is optional: the server declares what it supports, and both sides use only what they negotiated (capability negotiation). For the client, the MCP server is Xokepoint, not the server behind it. Xokepoint declares only what it can govern the way it governs a tool call: a verified subject and agent, a reviewed definition, a policy decision and a trace. Passing a capability through without that would open a path around the gateway. A client that follows MCP calls nothing that was not declared, so this needs no knowledge of how each harness works.
| Left out | What it does in MCP | Why |
|---|---|---|
tools.listChanged | The server tells the client that its tool list changed | The list the client sees is the list of the agent, filtered by its grants. A notice from the server would describe another list, and the notice that matters, a change of grant or review, would have to come from Xokepoint. It can come later. |
prompts | prompts/list, prompts/get: message templates of the server | Prompt text goes into the context of the model. Like a tool description, it would need a review, and prompts/get a decision. Without them, an upstream change would reach the model unchecked. |
resources | resources/list, resources/read, resources/subscribe: data of the server by URI | resources/read reads data. It would need the same authorization as a tool call (delegation, resource relations, conditions) and a trace. Passing it through would be a data path outside the policy. |
logging | logging/setLevel and log messages of the server | logging/setLevel is a control of the client over the server, outside any decision. The 2026-07-28 revision deprecates this capability (SEP-2577). |
completions | completion/complete: suggestions for prompt and resource arguments | It exists only to fill prompts and resources, which are not served. |
experimental, extensions | Methods outside the standard | With no standard contract, there is nothing to validate or govern. |
The server stream (GET) and session DELETE | Messages that the server starts outside a call; the end of a session | A message outside a call has no subject, agent or decision. Both answer 405, which the transport allows (listening for messages, session management). |
instructions of the server | Free text that the client puts in the context of the model | The text was never reviewed and can change at any time, the same risk as an unreviewed tool description. |
serverInfo of the server | Name and version of the implementation | The client talks to the governed server, so it gets the name of the server in the registry. The upstream implementation and version stay private. |
The progress of a tool call does not depend on any of these. The server sends notifications/progress on the response stream of the call, and Xokepoint delivers each event as it arrives (progress).
Long tool calls
A tool call can run for minutes, such as a build, a test run or a report. Xokepoint limits each phase of a call separately:
| Phase | Limit | What resets it |
|---|---|---|
| Authorization: token, delegation, grants, resources and conditions | 6 seconds | Nothing. A decision is always fast. |
| The tool on the server, without a message | 30 seconds | Each event that the server sends on the response stream, such as notifications/progress |
| The whole tool call | 5 minutes, and never past the expiry of the token | Nothing |
A tool that reports its progress can run up to 5 minutes, and the harness shows each step as it arrives. A tool that sends nothing for 30 seconds is stopped, and Xokepoint cancels the request to the server. Setup and the tool list keep the 6-second limit.
Xokepoint does not refuse an MCP request because of load. Capacity grows with the number of instances.