MCP Just Went Stateless: What the 2026 Spec Actually Changes for Your Servers

For its first two years, MCP was a protocol that assumed it was talking to a process on your laptop. That assumption was baked in deep, and nowhere deeper than in the session. Every connection started with a handshake. The client sent initialize, the server replied with its capabilities, the client sent initialized, and from that point on the two sides shared a session identified by an MCP-Session-Id header. It was a reasonable design for a local subprocess. It was a nightmare for anyone trying to run MCP as a real service.The 2026-07-28 spec - now the current official version, released on July 28, 2026 and superseding 2025-11-25 - throws that model out. It is the biggest structural change MCP has made since it launched, and if you run a server, it will break things. Let me walk through what happened and why.Why the session had to die Here is the problem in one sentence: stateful sessions and horizontal scaling are natural enemies. Put an MCP server behind a load balancer, and the session becomes a liability immediately. Because the handshake establishes per-connection state, every subsequent request from that client has to land on the same server instance — the one that holds its session. That means sticky routing, or a shared session store that every instance reads from, or both.You cannot just add three more replicas and round-robin across them. The MCP roadmap put it bluntly: stateful sessions fight with load balancers, and horizontal scaling requires workarounds.Stateful pinned every request to the one instance holding the session; stateless lets any instance answer. For a local stdio server, this cost nothing, because there was exactly one client and one server and no network in between. But the moment MCP servers moved to HTTP and started fronting real backends for real teams, the session turned into the thing standing between you and a normal, boring, scalable deployment. The fix is to make the protocol stateless — not the application, the protocol. And that distinction turns out to be the whole story.What actually changed. The stateless core comes down to four moves. The handshake is gone. No more initialize/initialized, no more Mcp-Session-Id. A request no longer depends on a prior exchange to be valid.Everything the handshake used to carry now travels in _meta. Protocol version, client identity, capability flags - they ride along in a _meta object on every single request. Each call is self-describing. Any instance can read it and act on it with no prior context.Capabilities move to a method. Since there is no handshake to announce what a server can do, the spec adds a server/discover method - which servers must implement and clients may call whenever they want the server's capabilities, identity, and supported versions, as an ordinary stateless request. It is optional for the client: a client can just as well fire any request inline and handle an "unsupported version" error if its version is not supported.Routing moves into headers. Streamable HTTP requests now carry routing headers: Mcp-Method on every request, and Mcp-Name on the calls where the specific target matters - tools/call, resources/read, prompts/get. They let a load balancer or gateway route a call without cracking open the JSON body to see what is inside, and servers must reject any request whose headers and body disagree - a new HeaderMismatch error- so the routing layer can trust them.Add those up, and you get the thing MCP always wanted to be at scale. Any instance can handle any request, a plain round-robin load balancer just works, and there is no shared session store to operate."Stateless protocol" does not mean "stateless app." This is the part that trips people up, so it is worth being precise. Removing the session from the protocol does not mean your application has to forget everything between calls. Plenty of real tools are inherently stateful - a shopping basket, a multi-step workflow, a long import job. Those still work. What changes is where the state lives and who can see it. The spec's answer is the handle pattern. Instead of hiding state in transport metadata that only the server knows about, a tool returns an explicit identifier — a basket_id, a workflow_id, a session_token — and the model passes that handle back as a normal tool argument on the next call. State becomes an ordinary value that flows through the conversation, visible to the model, rather than an invisible binding pinned to one server instance.It is a small shift with a big payoff. The state is still there. It just stopped being the load balancer's problem.The breaking changes, concretely. If you maintain a server, here is the migration list, stripped of ceremony. Most of these follow directly from killing the session; a few are independent cleanups the maintainers folded into the same release. Remove session handling. initialize/initialized, and Mcp-Session-Id are gone. Stop depending on them. Read _meta on every request. Client info and protocol version live there now, not in a one-time handshake. Implement server/discover. Capability discovery is a method call, on demand. Emit the routing headers. Mcp-Method is required on every request and Mcp-Name on tools/call, resources/read, and prompts/get; your server must reject requests where the headers contradict the body. Add cache metadata. tools/list and resource reads now carry ttlMs and cacheScope, modeled on HTTP Cache-Control, so clients can cache your tool list instead of re-fetching it constantly. Stop holding SSE streams open for prompts. Multi-round-trip interactions return an InputRequiredResult the client responds to, rather than a stream you keep alive waiting for input. Change one error code. A missing resource now returns -32602 (Invalid Params), not the old proprietary -32002. Support full JSON Schema 2020-12. Input and output schemas can now use composition — oneOf, anyOf, allOf — plus conditionals and references. Output schemas are no longer restricted. Propagate trace context. W3C Trace Context — traceparent, tracestate, baggage in _meta - is now the documented way to correlate a request across SDKs and gateways, which finally makes MCP traffic legible to OpenTelemetry-based observability. Migrate any Tasks usage. The experimental Tasks feature from 2025-11-25 moves to the new lifecycle, and it is not backward compatible. None of these is exotic on its own. Taken together, they are a real morning's work, and the trace-context and cache-metadata additions in particular are the difference between a toy and something you can actually operate.Extensions become first-class. The other half of the release is about growing the protocol without bloating its core. MCP now has a formal extensions framework. An extension gets a reverse-DNS identifier, is negotiated through an extensions map in client and server capabilities, lives in its own ext-* repository with its own maintainers, and versions independently of the main spec. Extensions even get their own standards track in the enhancement-proposal process, so a capability can ship as experimental, prove itself in the field, and only then be considered for the core — instead of every good idea having to fight its way into the base protocol on day one.Two official extensions ship with the release: MCP Apps lets a server ship an interactive HTML UI that renders in a sandboxed iframe, with the tool declaring a UI template up front so the client can prefetch it and security-review it. This is MCP quietly growing a front end. Tasks graduates from an experimental core feature to a proper extension. A long-running operation returns a taskId instead of blocking; the client drives it with tasks/get, tasks/update, and tasks/cancel; and because the task is not tied to a live connection, it survives a dropped connection instead of dying with it. The framework matters more than either extension. It is the mechanism that lets MCP evolve as a platform rather than a monolith.The Quiet Headline: A Deprecation Policy Buried under the stateless news is the change that will matter most over the next three years, and it is the least flashy one: MCP now has a formal feature lifecycle. Features move through three states — Active, Deprecated, Removed — and a feature must sit in Deprecated for at least twelve months before it can be removed. The 2026-07-28 deprecations, therefore, cannot be pulled before July 2027 at the earliest. The new lifecycle: a feature must sit Deprecated for at least twelve months before removal. That sounds like bureaucracy. It is actually a promise. It means the protocol can keep changing — dropping bad ideas, promoting good ones out of extensions - without periodically detonating every implementation in the ecosystem. A stable, published deprecation window is exactly the thing enterprises were waiting for before betting on MCP, and it is what lets the maintainers keep moving without breaking faith with the people who shipped against last year's spec. The first cohort of deprecations, all still functional for now, tells you where MCP thinks it went wrong: Roots — the local-filesystem concept never generalized to remote servers. Replace it with tool parameters, resource URIs, or server configuration. Sampling — letting a server ask the client to run an LLM call created a backwards trust dependency. Call your LLM provider directly from the server instead. Logging — redundant now. Use stderr for stdio servers, or structured OpenTelemetry for anything real. Dynamic Client Registration — it never fit the enterprise auth model, which is why last November's spec already nudged toward Client ID Metadata Documents. Use explicit OAuth registration. HTTP+SSE transport — superseded by streamable HTTP. If you read the earlier security work on MCP, the DCR deprecation should feel familiar - it is the same identity story continuing. On top of it, the release adds six authorization enhancements that tighten how MCP uses OAuth and OpenID Connect: issuer validation per RFC 9207, tokens bound to the authorization server that issued them, a documented OIDC refresh-token flow, and clearer scope-accumulation rules for step-up auth, among others. The security posture keeps hardening in the same direction it has been heading all year.What to do now This is not a preview you can wait out — 2026-07-28 is the current specification, and the Tier 1 SDKs for TypeScript, Python, Go, and C# already ship it. The migration clock is running, and every deprecation window started counting from the release date. A sane order of operations: Grep your server for initialize and Mcp-Session-Id. Everything downstream starts there. If your server leans on sticky sessions, that is your biggest migration. Make every handler read _meta, and stand up server/discover. Add the routing headers and the cache metadata - these are cheap and immediately useful. Audit your deprecations. Roots, Sampling, Logging, DCR, and HTTP+SSE all keep working for at least a year, so this is planning, not panic. Do it deliberately. Look hard at the extensions. Tasks solves the long-running-operation problem you have probably already hacked around, and Apps opens a door you may want to walk through. The through-line of the whole release is one sentence: MCP stopped being a protocol for talking to a process on your laptop and became a protocol for talking to a service in a cluster. The session was the last thing tying it to the old world. Now it is gone, and the rest of the changes are just the consequences of finally being honest about where MCP actually runs.