On 28 July 2026 the Model Context Protocol shipped its 2026-07-28 specification — in the maintainers’ own words, “MCP’s most important since remote MCP first launched over a year ago.” If you build or operate MCP servers, the headline change is simple to state and consequential to sit with: protocol-level sessions are gone. The initialize/initialized exchange, the Mcp-Session-Id header, the whole connection-scoped session model — retired. Every request now travels independently.
The maintainers are direct about why, and about what that removal hands to you. Both quotes are worth reading exactly as written, because the second one is the whole argument of this piece.
Why sessions left
“It was one of the most highly-requested features from developers who were eager to get better reliability and scalability for their MCP servers.”
Sticky routing and shared session stores were a real operational tax. A stateless core means that request metadata — protocol version, client capabilities — now travels in the message body of every request rather than in connection state a load balancer has to preserve. Any server instance can handle any request. That is a legitimate, sensible engineering trade, and this is not an argument against it.
What the spec says you now own
“Dropping the protocol-level session doesn’t force your application to be stateless. If your server needs to carry state across calls, mint an explicit handle from a tool and have the model pass it back as an argument.”
Read that again. The spec did not remove sessions and leave implementers to work out state by accident — it names the replacement pattern explicitly: mint a handle, thread it through tool-call arguments, done. That is a clean, well-specified answer to “how do I correlate calls that belong together.”
It is not an answer to a different question the spec was never asked to answer: what does a correlated sequence of calls add up to, and was that sum ever something anyone intended? To be exact about who is claiming what — the specification explicitly makes cross-call state the application’s responsibility. That sequence evaluation is a governance responsibility you should then build on top of that state is my argument, not the spec’s.
A handle threaded through ten tool calls tells a server “these ten calls belong to the same logical thread.” It says nothing about whether those ten calls, taken together, should have been allowed. An agent that reads a file, then another, then a third, then a fourth — each one permitted, each one individually unremarkable, each correctly carrying the same handle — can still be exfiltrating a dataset one file at a time. The handle makes the sequence legible. It does not make the sequence governed.
The rest of the release, briefly
The 2026-07-28 spec is not only about removing state. Three other changes matter for anyone running MCP in production:
- A formal Extensions framework, version-independent of the core spec, graduating Tasks (long-running work) and introducing MCP Apps and Enterprise Managed Authorization as adopted extensions.
- Authorization changes: clients must validate the
issparameter per RFC 9207; clients still using Dynamic Client Registration must declare an OpenID Connectapplication_type; and DCR itself is now formally deprecated in favour of Client ID Metadata Documents, though it keeps working for backward compatibility until a future spec version removes it. Real, useful WHO-layer tightening — it makes it harder to confuse or spoof which authorization server issued a credential. - A formal deprecation policy (SEP-2577): Roots, Sampling and Logging are deprecated but guaranteed to keep working for a twelve-month minimum. The legacy HTTP+SSE transport is officially deprecated too, with a year-long offramp. Nothing breaks tomorrow.
None of that authorization hardening touches the sequence question, and it is not supposed to. Validating which issuer signed a credential is a different, earlier question than what a validated principal’s accumulated tool calls composed into. Tightening the first does not narrow the second at all.
The same boundary, now load-bearing at the substrate layer
A mechanism that authenticates or correlates individual actions is not the same mechanism that evaluates what a sequence of those actions adds up to. That is the argument in Authorized but Composed, and it applies to signed receipts and signed requests as readily as to protocol sessions.
MCP differs in degree, not in kind. It is a major substrate for agent tool calls, and its own specification explicitly makes cross-call state the application’s job rather than the protocol’s. That state is also the prerequisite for any application-layer mechanism intended to recognise a bad sequence of individually-fine calls.
That is not a criticism. Naming the boundary honestly, as this spec does, is better than pretending the protocol layer was ever going to solve it. But it does mean the “mint a handle and pass it back” pattern will likely become common across MCP servers. Whether those implementations attach an evaluator to the resulting correlation key is an application-level design choice — not something the spec told them to do or not do, simply a layer the protocol has now made unambiguously theirs to fill or leave empty.
The gap this spec is honest about is precisely the gap cross-session risk composition (DOI 10.5281/zenodo.21400261) exists to close: a stateful layer above the protocol that accumulates risk per handle, per session, per principal, across a rolling window, and escalates when the accumulation crosses a threshold — even when every individual call, correctly correlated by its handle, passed its own check.
If you have already adopted the handle pattern: what reads the handle other than your own tool code? If the answer is “nothing — it is just how we thread state,” then the handle is a correlation key with no evaluator attached. The spec put the state in your hands; what you build on top of it is the open question.
Related reading
Authorized but Composed: the residual-moat argumentAuthorization Was the Easy Part: Who Is Allowed to Evaluate the Sequence
“Expected Behavior” Is Not the Same as Safe