The MCP release candidate that dropped ahead of the July 28 final spec got read for its funeral notices: Sampling, Roots, and Logging are on their way out. That's the change with a body count, so it got the headline. But it isn't the change that will touch every server you run.
The one that does is quieter and structural: MCP is no longer a session. The initialize/initialized handshake is gone. The Mcp-Session-Id header is gone. A server no longer holds any per-connection state, because there is no connection to hold — client info and capabilities now ride in _meta on every request. The protocol became stateless, and once you see why, the rest of the rewrite reads like a set of forced moves.
Why "stateless" is the whole story#
Here is the thing statelessness buys, in one sentence: you can put an MCP server behind a plain round-robin load balancer.
That sounds like a devops footnote. It isn't. The old session model pinned each client to one server instance for the life of the connection — the instance that completed the handshake was the only one that knew who you were. Scaling that means sticky sessions, connection draining on deploy, and a whole class of "works on one replica, breaks on three" bugs. Every team that tried to run an MCP server as real production infrastructure hit the same wall: the protocol assumed a long-lived stateful socket, and the internet is built out of stateless, interchangeable boxes.
The old MCP assumed a socket. Production assumes a load balancer. The 2026-07-28 spec finally picks the load balancer.
By moving client identity and capabilities into _meta on every request, the new spec makes each request self-describing. Any instance can answer any request. Deploys stop being special. Autoscaling just works. This is the boring-infrastructure move, and it's the right one — but it can't be done in isolation, because MCP had features that depended on the socket being there.
The forced move: elicitation without a held connection#
The socket wasn't only carrying identity. It was the channel a server used to reach back mid-call — to ask the human a question (elicitation) or, until this revision, to borrow the client's model (sampling). Both worked by holding a Server-Sent Events stream open and pushing a prompt down it. Kill the persistent connection and that mechanism has nowhere to live.
The replacement is Multi Round-Trip Requests (SEP-2322), and it's the cleverest part of the spec. Instead of pushing a prompt down an open stream, the server returns one. A tools/call that needs input comes back not with a result but with an InputRequiredResult: a list of inputRequests plus an opaque requestState blob. The client gathers the answers, then re-issues the original call with an inputResponses field and the echoed requestState. All the context needed to resume lives in the payload, not in a server's memory — so the retry can land on a completely different instance than the one that asked the question.
It's continuation-passing style, dressed as a wire protocol. And it's the same reason the whole thing scales: state travels with the request.
Tasks, Apps, and the audit path#
Two more pieces fall out of the same logic.
Tasks — the primitive for work that outlives a single call — moved from an experimental core feature to a proper extension, with a lifecycle rebuilt around statelessness. A tools/call now returns a task handle; the client drives it with tasks/get, tasks/update, and tasks/cancel. Notably, tasks/list was removed — a stateless server has no session-scoped inventory of "your" tasks to enumerate. If you want a list, you track the handles you were given.
MCP Apps (SEP-1865) are the genuinely new surface: a server can now ship an interactive HTML interface that the client renders in a sandboxed iframe. The discipline is the interesting part. UI templates are declared upfront so the client can prefetch and security-review them, and every interaction the UI triggers routes through the same JSON-RPC audit path as a direct tool call. The UI can't reach past what a logged, auditable tool call could do. That's the difference between "we added a webview" and "we added a webview that can't become a side channel."
Alongside those, an Extensions framework (reverse-DNS identifiers, capability-map negotiation, independent versioning) lets add-ons evolve outside the core spec's cadence, and six SEPs harden authorization — mandatory iss validation per RFC 9207 (SEP-2468), OIDC application_type declaration in Dynamic Client Registration (SEP-837), issuer binding for registered credentials (SEP-2352). Production-grade OAuth alignment, in other words.
What actually breaks#
For all the surface area, the wire-level break list is short and mechanical:
- No handshake. Nothing calls
initialize. If your server waits for it, it waits forever. - No session routing. The
Mcp-Session-Idheader is gone; stop keying anything on it. - Two new required headers.
Mcp-MethodandMcp-Nameare now mandatory on requests. - One silent error-code change. A missing resource now returns
-32602(the JSON-RPC standard "invalid params") instead of the old MCP-specific-32002. Any client that branches on-32002will quietly stop recognizing the error.
None of these are hard to fix. The -32002 → -32602 change is the one to watch, precisely because it fails silently — no exception, just a code your error handler no longer matches.
The spec also folds in the plumbing that boring infrastructure needs: explicit caching via ttlMs and cacheScope (SEP-2549), and W3C Trace Context propagation — traceparent, tracestate, baggage (SEP-414) — so a tool call can be traced across SDKs and services like any other distributed request.
What it means if you ship agents#
Read the whole release as one decision: MCP chose to be infrastructure over being clever. The session model was more expressive — a server could reach into your runtime, borrow your model, hold a live conversation over a socket. The stateless model gives all of that up in exchange for the one property that matters when you're running more than one replica in front of paying users: any box can serve any request.
That's the trade every protocol makes when it grows up. HTTP made it. This is MCP making it. If you build on MCP, the practical takeaway is that your server is about to get much easier to operate and slightly less magical to write — and that's the correct direction for anything you intend to keep running.
The final spec publishes July 28, 2026. Nothing switches off that day, but new clients will speak the stateless protocol, so the migration clock is running.
Next: we turned this into a concrete checklist — how to make your MCP server stateless before July 28, with the old-vs-new code for the elicitation change.



