Contents
I run MCP tools inside an agent harness every day, so a protocol revision this large gets my attention fast. The 2026-07-28 Model Context Protocol specification, now shipping as GA SDKs, removes the initialize/initialized handshake and the Mcp-Session-Id header entirely. MCP moves from a bidirectional stateful protocol to a plain request and response one, and that single change quietly unlocks something every server author has wanted since MCP shipped: the ability to deploy behind a round-robin load balancer, on serverless compute, or at the edge, without sticky sessions or shared storage.
Why this matters more than it sounds
Under the old spec, a client opened a session, the server pinned that session to a process holding conversation state in memory, and every subsequent request had to land back on that same instance. That is fine for a single long-running server on a box you control. It is a genuine headache the moment you want to autoscale, run behind Cloudflare Workers or Lambda, or fail over cleanly when an instance dies mid-session. Stateful session affinity is exactly the kind of infrastructure tax that keeps a protocol stuck running on dedicated VMs while the rest of the web moved to elastic, ephemeral compute a decade ago. MCP just paid that tax off.
What actually changed
Every request now carries its own identity. Instead of a session token pointing at server-held state, each request includes its protocol version and client capabilities directly. Any server instance can answer any request cold, which is the whole trick behind removing session affinity.
Two new headers make routing cheap. Mcp-Method and Mcp-Name sit on every Streamable HTTP request, so a gateway, rate limiter, or WAF can route and meter traffic by reading headers instead of parsing and buffering the JSON-RPC body. That is a meaningful cost difference at scale.
Responses can now say how long they are good for. tools/list, prompts/list, resources/list, and resources/read responses carry ttlMs and cacheScope, so a client knows whether it is safe to skip a re-fetch instead of guessing.
Interactive tool calls survive the switch. The old spec let a server pause mid-call and ask the client something over an open stream. Stateless MCP replaces that with Multi Round-Trip Requests: the server returns resultType: "input_required" with what it needs, the client answers, and the server continues on the retry, no persistent connection required.
Try the shape of that change yourself. Toggle between the old handshake and the new single-shot request below, then hit the tools/list button a few times to see ttlMs caching kick in exactly like a real client would apply it.
About the demo
Everything below runs in your browser against mocked responses shaped like the real spec. Nothing is sent anywhere.Where this leaves server authors
The GA SDKs landed with the spec, so this is not a paper proposal, it is something you can adopt this week. If you maintain an MCP server, the practical checklist is short: drop any in-memory session state keyed by Mcp-Session-Id, make sure your handlers read client capabilities from the request _meta instead of a stored session object, and set honest ttlMs values on list responses so clients actually benefit from the new caching contract. If you use MRTR-style prompts mid-tool-call, that logic needs to move from an open stream to the input_required retry loop.
I am adopting this in chi, my own multi-agent research harness, this week. Chi’s gateway currently pins MCP connections per session the old way, which is exactly the kind of code this spec makes obsolete. Once the client libraries stabilize past beta, the plan is straightforward: strip the session-affinity logic out of the gateway, move tool routing to read Mcp-Method and Mcp-Name off the header instead of the body, and let the server instances scale horizontally like every other stateless HTTP service already does.