Check the gateway against the stateless MCP revision (2026-07-28)

[imran-siddique]

The 2026-07-28 MCP revision moves the protocol away from long-lived sessions, and the ecosystem has moved with it faster than I expected. Cloudflare now runs every request on a fresh stateless server. GitHub dropped its session storage entirely and stopped writing on initialize. Several other hosts shipped support the same week.

We need to know what that does to the gateway, because a policy gate that holds anything across calls has just had its assumptions changed underneath it.

What to check, roughly in order of how bad it would be:

1. Does anything bind attestation evidence to a session or connection lifetime? If a fresh server per request is the norm, an attestation established at initialize and reused for later calls is either not happening or not meaning what we think it means.
2. Is the loaded policy bundle held per session anywhere? Same question. If the bundle is resolved once per connection and the connection is now one request long, that is fine but wasteful, and if it is cached across connections keyed by something session-shaped, that is a correctness problem.
3. Anything else keyed by session id: rate limiting, decision caching, delegation context, audit correlation.
4. Whether our own conformance tests still exercise a realistic transport, or whether they all assume a session that stays up.

The design question underneath, which is the part I actually care about: attestation and statelessness pull against each other. Re-attesting per request is correct and expensive. Carrying the binding in the request means deciding what carries it and what a verifier checks. I do not think there is a settled answer for this anywhere yet, and if we work one out it is worth writing up rather than just fixing quietly.

Refs: MCP specification revision 2026-07-28.

[imran-siddique]

Went through this. Short version: the thing I was worried about is not a problem, and something else is.

1. Nothing binds attestation to an MCP session. SessionManager.create_session() is called in exactly two places, cli.py:42 at startup and mcp/server.py:553 after an explicit reset. A cMCP session is process scoped and has never been an MCP session. The per session TEE report whose nonce commits the chain root (session/manager.py:126-165) is therefore unaffected by anything the transport does. No fix needed.

2. Same for the policy bundle. #492 already moved it off per call re-reading and #497 signs the bundle manifest. Nothing is keyed by a session id from the wire.

3. Nothing else is session keyed either. Audit correlation uses our own session_id, generated locally.

So the correctness worry was misplaced. The compatibility one is real.

The outbound path is not a conformant MCP client

proxy.py:368-380 posts a bare JSON-RPC tools/call straight at entry.server.url and then calls resp.json(). On that path there is no initialize, no Mcp-Session-Id, no MCP-Protocol-Version header, and no Accept header.

A Streamable HTTP server is entitled to answer that POST with text/event-stream. We do not ask for JSON, we get a stream, resp.json() raises ValueError, and we turn it into UpstreamUnavailable.

Failing closed is the right direction and I would not change it. The practical effect is still that we cannot proxy the servers that just migrated, which as of the last few weeks includes some of the most used hosted MCP servers there are. "Fail closed" and "cannot connect to the ecosystem" are the same behaviour from the outside.

Worth being honest that this was already true before the revision. We never spoke the handshake. The revision is what makes it start to matter.

Two smaller things found on the way

transport is documented but never validated. catalog/loader.py:32 says the field is "http-sse", "websocket" or "stdio", and line 227 defaults it to "http-sse". Only is_stdio is ever checked, so every other value, including a typo and including websocket, silently takes the HTTP POST path. There is no streamable-http value at all.

We advertise protocolVersion: "2024-11-05" downstream (mcp/server.py:270). That is a hardcoded string several revisions back.

What I think should happen

Not all in this issue. Suggest splitting:

1. Speak Streamable HTTP outbound properly: initialize, protocol version header, Accept covering both application/json and text/event-stream, and handle an SSE response body. This is the one that unblocks real servers.
2. Validate transport at catalog load, fail closed on an unknown value rather than defaulting into the HTTP path, and add streamable-http.
3. Stop hardcoding the downstream protocol version.

The design note, which is the part worth keeping

SessionState sensitivity is monotonic, it only ever rises, and all of its value comes from many calls sharing one session. That works today precisely because our sessions are process scoped rather than MCP scoped.

If anyone later makes the runtime per request, to look more like the rest of the ecosystem, sensitivity resets to public on every call and the escalation control becomes a no-op without failing anything or logging anything. It would look like it was working.

Writing it here so the next person to propose "make cMCP stateless" finds it. The general shape, that per request execution and accumulated session state pull against each other, is the thing I said was worth writing up, and I still think it is.