MCP Goes Stateless: What's Actually in the 2026-07-28 Spec
The largest revision of the Model Context Protocol since launch, in plain terms: stateless core, extensions, new auth rules, and what you need to migrate.
On July 28, the Model Context Protocol shipped its largest revision since launch. If you build or run MCP servers, this one is not optional reading. The protocol you integrated in 2025 has structurally changed, and the old shapes are now on a twelve-month deprecation clock.
This is not an essay. It is a field note: what changed, why, and what you need to do about it.
Sessions are gone
The 2026-07-28 spec drops the stateful, bidirectional design for a stateless request/response core. Concretely:
The initialize/initialized handshake is removed. So is the Mcp-Session-Id header. Each request is now self-describing: it carries the protocol version (MCP-Protocol-Version: 2026-07-28), client identity, and capabilities in the _meta field (io.modelcontextprotocol/clientInfo).
Why it matters: any server instance behind an ordinary load balancer can answer any request. No sticky sessions, no shared session store, no warm-up round trips. MCP servers now scale like plain HTTP services, which is what most operators were painfully faking with session-affinity workarounds.
If your server kept per-session state, the guidance is explicit: mint an explicit handle from a tool and have the model pass it back as an argument. State becomes visible to the model instead of hidden in transport plumbing.
Multi Round-Trip Requests replace server-initiated requests
With no open stream, a server can no longer push a request back to the client mid-call. The replacement is Multi Round-Trip Requests (SEP-2322): a tool that needs more input returns resultType: "input_required" with the prompts it needs, and the client retries the original call with the answers in inputResponses. Confirmations and missing-parameter collection now work over a fully stateless transport.
Infrastructure finally gets a seat
Two changes are aimed squarely at the people running gateways rather than writing tools:
Header-based routing (SEP-2243). Requests must carry Mcp-Method and Mcp-Name headers, so rate limiters, WAFs, and gateways can route and authorize without parsing JSON bodies.
Cacheable lists (SEP-2549). tools/list, prompts/list, resources/list, and resources/read responses now carry ttlMs and cacheScope, so clients can stop re-fetching tool catalogs on every conversation.
Extensions: the core gets smaller, on purpose
The spec now has a formal extensions framework. Extensions are identified by reverse-DNS IDs, negotiated through an extensions map in capabilities, live in their own repositories with their own maintainers, and version independently of the core spec.
Three notable ones:
- Tasks (
io.modelcontextprotocol/tasks, SEP-2663) moved out of the experimental core. Long-running work is now polling-based (tasks/get, plus a newtasks/update), with change notifications consolidated into a single opt-insubscriptions/listenstream. - MCP Apps lets servers ship interactive HTML interfaces that hosts render in a sandboxed iframe.
- Enterprise Managed Authorization for organizations that need centrally administered auth.
The direction is clear: a small, stable, boring core, with innovation pushed to the edges where it can move fast without breaking everyone.
Authorization got harder to get wrong
Several production-security fixes landed at once:
- Authorization servers must return the
issparameter per RFC 9207, and clients must validate it (SEP-2468). - Clients declare
application_typeduring registration, fixing the localhost-redirect mess for CLI and desktop apps (SEP-837). - Client credentials are bound to the authorization server that issued them and cannot be replayed across providers (SEP-2352).
- Dynamic Client Registration is formally deprecated in favor of Client ID Metadata Documents (CIMD).
The deprecation list
Written down, with a mandatory twelve-month support window (SEP-2577):
- Roots, Sampling, and Logging are deprecated as core features.
- The legacy HTTP+SSE transport is deprecated.
The spec also introduces a formal deprecation policy, so future removals come with predictable timelines instead of surprise breakage.
SDK status
All four Tier 1 SDKs (TypeScript, Python, Go, C#) support 2026-07-28 today, with migration docs for the breaking changes. The Rust SDK supports it in beta.
What to actually do
- If you run MCP servers behind session-affinity hacks, plan the move to the stateless core. This is the payoff release.
- If your tools relied on server-initiated requests, port them to the
input_requiredretry pattern. - If you use Roots, Sampling, Logging, or HTTP+SSE, you have twelve months. Start now, not in month eleven.
- If you do OAuth, check the
issvalidation and CIMD guidance before your next security review. - Set
ttlMson your list responses. Your clients’ context windows and your egress bill will both thank you.
The full changelog is in the official announcement and the spec itself. The 2026 roadmap post explains where this is heading next.
¶ Fin.