MCP deleted the session: where does state live now?

Sources cited in this piece · Model Context Protocol (MCP) specification revision 2026-07-28, Key Changes (quoted verbatim) · prior revision 2025-11-25 · secondary ecosystem reporting, labeled as such

In late July, the Model Context Protocol (MCP) published its largest structural revision to date: version 2026-07-28. The changelog's headline items read like an operation report from a protocol removing its own skeleton. The initialize/notifications/initialized handshake: removed. The Mcp-Session-Id header: removed. Per-connection list endpoints: removed. The summary sentence is the whole thesis in one line — “Make MCP stateless.”

Whenever a protocol deletes its session, the real question is not what was removed but where the removed thing went. State does not evaporate; it relocates. So the deep-dive question of this piece: after 2026-07-28, where does state live — and what is still missing from that table?

1. What was removed, verbatim

Two entries carry the change. On the transport: “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). On the handshake: “Make MCP stateless: remove the initialize/notifications/initialized handshake. Every request now carries its protocol version and client capabilities in _meta” (SEP-2575). Two further entries complete the picture: Tasks move out of core into an official extension (SEP-2663), and Roots, Sampling and Logging are deprecated with a twelve-month window (SEP-2577, SEP-2596).

2. Where state went: three carriers, one deletion

The revision does not abolish state; it re-homes it. First carrier: the request itself. Each request now carries its protocol version and client capabilities in _meta, clients “SHOULD identify themselves on each request” (io.modelcontextprotocol/clientInfo), and servers identify themselves in every result (io.modelcontextprotocol/serverInfo). Version mismatch returns UnsupportedProtocolVersionError. Identity became a per-request field.

Second carrier: a mandatory self-description. New RPC: “Add server/discover: servers MUST implement this RPC to advertise their supported protocol versions, capabilities, and identity” (SEP-2575). The server, too, now introduces itself inline instead of once at a handshake.

Third carrier: the application layer. Cross-call state is not the protocol's business anymore — “explicit, server-minted handles passed as ordinary tool arguments.” The session moved from transport headers into function parameters. And on the authorization side, OAuth Dynamic Client Registration (RFC 7591) is deprecated in favor of Client ID Metadata Documents (PR #2858) — client identity, too, becomes a published document rather than a registration handshake.

3. Why the protocol chose this

The motivation is scale, and the changelog states it by implication: list endpoints that “vary per-connection” force every intermediate hop to know which connection it is serving; a handshake binds the conversation to a transport lifetime. Stateless requests survive load balancers, restarts, retries and multi-tenant gateways — the same forces that shaped HTTP itself. Secondary ecosystem reporting documents the transition cost honestly: clients have not all caught up, so which revision you get depends on the agent, and the fallback negotiation has its own failure modes. That turbulence is the price of the cleanup, not evidence against it.

Our interest is narrower and architectural: the revision is a quiet datapoint in a larger argument. Connection-borne state does not survive scale; state has to move into the message or into the application. MCP chose both, deliberately splitting the two: identity into per-request _meta, semantics into tool arguments. What it did not choose — yet — is making either one verifiable.

4. The two missing rows

Look again at the table above. The identity row is a field the client fills in about itself: SHOULD identify, never MUST verify — nothing in the request binds clientInfo to a key, and nothing asks whether the assertion is still true an hour later. The freshness row is empty because a stateless protocol that restarts every call has no carrier for “standing”: trust either lives in a long-lived OAuth grant — back in the connection-shaped world the revision just left — or it does not live anywhere.

This is where our two pillars meet the design, and we state the boundary precisely. Where a statement lives is an addressing question — the Resonant Time Transfer Protocol (RTTP) derives an address from a canonical authority and carries intent, identity and standing in the packet itself, so the message does not need a session to know who is speaking. Whether a statement stands is an attestation question — Identity Quality Assurance (IQA) seals that answer into a fixed-size envelope with a 120-second lease and verification that completes offline. An MCP _meta field could carry such an envelope tomorrow; the wire format forbids nothing. We are not proposing a fork — we are naming the rows a stateless design still leaves unassigned.

5. The closing perspective

Deleting the session was the correct call, and the courage to remove — not just add — is rarer in standards work than it should be; the new deprecation policy with its twelve-month window (SEP-2596) is good hygiene. Read the revision as a direction statement: the industry's biggest tool protocol just bet that the durable unit of agent computation is the self-describing request, not the long-lived connection. We agree with the bet. Our whole architecture is that bet, taken further — until the self-description is signed, leased, and verifiable offline, “stateless” names where the verification gap begins, not where the problem ends.

Sources　[1] Model Context Protocol specification, revision 2026-07-28, Key Changes (modelcontextprotocol.io) — SEP-2567, SEP-2575, SEP-2663, SEP-2577, SEP-2596 and PR #2858 quoted verbatim, accessed 2026-10-18　[2] Prior revision 2025-11-25 (modelcontextprotocol.io), referenced for scope comparison　[3] Secondary ecosystem reporting on client support and migration friction (9io.ai migration guide; gravity.fast standards overview, updated 2026-10-09) — labeled as secondary; no figures cited beyond the general statement that client adoption is uneven　[4] Editorial note: individuals are cited by affiliation only; the “largest structural revision” characterization follows the scope of the changelog itself (session removal, handshake removal, feature deprecations, authorization rework).

One line: a stateless protocol makes every request introduce itself — the next step is making that introduction checkable, leased, and true even when the network is not.