MCP 2026-07-28 removed sessions: the v0.3 MCP profile needs a different correlation anchor

[imran-siddique]

What changed upstream

MCP revision 2026-07-28 removed the construct the v0.3 MCP profile was going to bind to. From the changelog, major changes 1 and 2:

Remove protocol-level sessions and the Mcp-Session-Id header from the Streamable HTTP transport. List endpoints (tools/list, resources/list, prompts/list) no longer vary per-connection. Servers that need cross-call state use explicit, server-minted handles passed as ordinary tool arguments (SEP-2567).

Make MCP stateless: remove the initialize/notifications/initialized handshake. Every request now carries its protocol version and client capabilities in _meta (SEP-2575).

There is no MCP session any more, and no handshake in which one could be established.

Why it lands here

ROADMAP.md scopes the v0.3 item as the normative MCP profile, "claim shape and binding rules for MCP tool-call transcripts... for upstream contribution to MCP spec governance."

Our own description of that evidence is written in session terms:

• §3.3 names the row "Session evidence": the Trust Record, policy hash, runtime measurement and tool_transcript.hash "bind the governed session".
• §3.3.3 requires a receipt to bind "back to the TRACE session, transcript entry, or call".
• session_id is a signed field with a MUST: a verifier rejects a disclosure whose session_id does not match the receipt stream under verification.

Nothing in v0.2 is invalidated by this. TRACE's session_id names a receipt stream we mint, not an MCP session, and the same is true of cMCP's audit-chain session_id. The exposure is confined to the profile: writing binding rules that map a transcript onto an MCP session, and then proposing them upstream to the body that has just removed sessions, is a bad opening and an easy one to walk into given how §3.3 currently reads.

What the profile should anchor on instead

Two candidates, both named by the revision itself.

1. OpenTelemetry trace context. Minor change 2 documents traceparent, tracestate and baggage as _meta conventions (SEP-414). For a stateless protocol this is the standards-aligned correlation hook, and it is already what an operator is likely to have.
2. Server-minted handles as tool arguments, which is what SEP-2567 names as the replacement for cross-call state. This puts correlation inside the transcript we already hash rather than beside it.

Either way the profile should say explicitly that the correlation identifier is TRACE's or the server's, and is not an MCP protocol construct.

A second-order consequence for transcripts

Major change 9 removes SSE stream resumability:

A broken response stream loses the in-flight request; clients MUST re-issue it as a new request with a new request ID.

So a transcript cannot assume request ids are stable across a retry, and must tolerate abandoned attempts sitting beside the completed one. Any per-call ordering or completeness claim in the profile needs to survive that, and tool_transcript already carries the caveat that the record does not expose every call without the transcript bytes.

Adapter surface to check

Roots, Sampling and Logging are deprecated (SEP-2577), under a twelve-month window. Any producer adapter that reads them keeps working for now but should not gain new dependencies on them.

Status of the reference implementation

cMCP has already migrated and is ahead of this document. src/cmcp_runtime/mcp/server.py speaks 2026-07-28 outbound and keeps the handshake revisions for legacy clients only, with a comment explaining that 2026-07-28 "must never be the answer to a handshake: it names a protocol in which this request does not exist".

So this is a specification-language gap rather than an implementation gap, which is the cheap kind to fix, and cheapest before the profile is drafted rather than after.

Ask

Decide the correlation anchor before the v0.3 MCP profile is written, and reword §3.3's session framing so the profile does not inherit a construct that upstream has removed.

[Mayur021]

Both anchors correlate calls. There is a second binding the profile has to choose, and 2026-07-28 made it harder rather than easier.

Before SEP-2567, tools/list varied per connection, so a session carried an implicit snapshot of what the tools claimed to do. That is gone, and there is no handshake left to pin one to. At verification time nothing says what the called tool was declared to do at the moment it was called.

tool_transcript.hash binds which tools were called, with what parameters and responses. It does not bind the contract they were called under. That stops being academic once the protocol is stateless, because declarations move underneath.

We measured this. 35 crawls of the public MCP registry between June and August 2026, 44,172 tools on 2,043 servers. 83.8% of tools declare at least one canonical effect annotation, and 59.3% hold a declaration still bound to an unmutated contract. The gap is 24.5 points, and it stays between 21.6 and 24.7 across every threshold tested. Over the longest uninterrupted 21-day window, 18.3% of the declaring and judgeable tools saw a confirmed contract mutation. The corpus holds 783 confirmed declaration changes, and 86.0% of first declarations land on the permissive pole. All four annotation defaults are restrictive, so that move produces no change event for a monitor to fire on.

The consequence here is that a Level 1 record can verify cleanly and the relying party still cannot tell whether the tool that ran means now what it meant then.

Suggestion for the profile: require a digest over the declaration set in force at call time, the canonicalized tools/list result, carried in the transcript and covered by tool_transcript.hash. Section 3.2 already reaches this case where it says the canonicalization rule covers a bridge profile's declaration and tool-call digests, where no schema constrains the input. The mechanism is there. The profile is where it becomes required.

Method and data: https://doi.org/10.5281/zenodo.22649163