Most early MCP servers were built like chat connections: a client connected, shook hands, held a session open and the server pushed requests back when it needed something. That worked on a laptop. It worked less well behind a load balancer, in serverless runtimes, or anywhere a connection could drop. The 2026-07-28 specification addresses that head on1.
What changed, in one table
| Before | From 2026-07-28 | Why it matters |
|---|---|---|
initialize handshake and Mcp-Session-Id | Removed; each request carries protocol version and client capabilities in _meta | Any request can land on any instance2 |
| Capabilities learned at connect time | Optional server/discover call that servers must implement | Up-front version selection when clients want it2 |
| Server-initiated elicitation, sampling and roots requests | Multi Round-Trip Requests: the server returns input_required and the client retries with answers | No held-open bidirectional stream3 |
| Method and tool names only in the JSON body | Mcp-Method and Mcp-Name headers required on Streamable HTTP | Gateways route and authorise on headers4 |
| List results with no freshness hints | ttlMs and cacheScope, plus deterministic tool order | Client caching and stable prompt caches2 |
SSE resumability with Last-Event-ID | Removed; a broken stream means re-issuing the request | Simpler transport, but retries must be safe2 |
The release also moved Tasks into an official extension, hardened authorisation with RFC 9207 issuer validation, deprecated Dynamic Client Registration in favour of client metadata documents, and introduced a formal deprecation policy with a twelve-month minimum window1.
The playbook
1. Inventory what depends on sessions
List every server and find where it relies on connection state: per-session caches, "current project" set at connect time, server-pushed requests, resumable streams. Those are your migration items. Servers that only expose stateless tools usually need little more than an SDK upgrade.
2. Replace hidden state with explicit handles
The specification's answer to cross-call state is an explicit, server-minted handle returned by a tool and passed back as an ordinary argument2. The maintainers note this works better than transport-hidden state because the model can see the handle and thread it between tools1. Store the state behind the handle in a shared store, scoped to the user, with an expiry.
3. Rework interactive tools with MRTR
Tools that asked the user for confirmation or a missing parameter mid-call now return an interim result with resultType: "input_required"; the client gathers the answers and retries the original request with them3. Design these tools so a retry is safe, and keep any correlation data in the request state rather than server memory.
4. Make retries safe everywhere
Without stream resumability, a dropped response stream means the client re-issues the request with a new ID2. Any tool with side effects needs idempotency, the same discipline as in idempotent payment pipelines.
5. Move routing and policy to the gateway
With Mcp-Method and Mcp-Name on every Streamable HTTP request4, a gateway can rate-limit, authorise and meter per tool without parsing bodies. Plain round-robin load balancing now works. This is the natural place to enforce the controls in securing MCP servers.
6. Use the cache hints
Return a deterministic tool order and sensible ttlMs values. Stable tool lists help clients cache catalogues and keep upstream prompt caches warm, which matters for cost, as covered in prompt caching.
7. Plan the deprecations
Roots, Sampling and Logging are deprecated, with suggested migrations: pass paths through tool parameters or configuration instead of Roots, call model providers directly instead of Sampling, and use stderr or OpenTelemetry instead of protocol Logging25. Trace context now has documented conventions in _meta, which fits the approach in LLM observability.
Stateless MCP doesn't make your system stateless. It makes your state visible, which is exactly where an auditor, an SRE and the model all need it to be.
Sequencing for an enterprise estate
- Gateway first, so routing and policy work for both old and new protocol versions during the transition.
- High-traffic, stateless servers next: the easiest wins for scalability.
- Interactive and stateful servers last, with handles and MRTR designed and tested properly.
- Registry metadata updated to show which protocol versions each server supports, as in an enterprise MCP registry.
How I can help
I design and migrate enterprise MCP estates, from gateways and registries to server patterns that survive load balancers and retries. See my AI architecture work, or analyse your challenge and bring the result to a call.
- 1The 2026-07-28 SpecificationModel Context Protocol blog · 28 Jul 2026
- 2Key changes (2026-07-28 changelog)Model Context Protocol specification
- 3Multi Round-Trip RequestsModel Context Protocol specification
- 4Streamable HTTP transportModel Context Protocol specification
- 5Deprecated featuresModel Context Protocol specification