MCP 2026 Specification: Stateless Core and Migration Guide

The Model Context Protocol publishes the largest revision in its history. The release candidate was locked on May 21, 2026, and the ten-week window since then has been a validation period for SDK maintainers and client implementers. The MCP 2026 specification does something protocols rarely do this late in their adoption curve. It removes the session layer entirely and rebuilds the transport around self-contained requests.

The change is not cosmetic. Under the previous revision, every Streamable HTTP interaction began with an initialize call, and the server returned an Mcp-Session-Id header that pinned the client to whichever instance issued it. That design was serviceable for a developer running one server on a laptop. It became a liability the moment a platform team tried to run the same server behind a load balancer with autoscaling and rolling deploys.

What existed before was a protocol shaped by local, single-user assumptions. Sticky routing was mandatory, shared session stores were common, and gateways had to inspect request bodies to make routing decisions. Rolling deployments broke in-flight tool calls because session state lived in process memory. Teams solved this with Redis, sticky cookies, and a lot of glue code that no vendor supported.

This blog covers what actually changed in the specification, why the maintainers chose a clean break, and what the new request shape looks like on the wire. It covers the Extensions framework, the redesigned Tasks lifecycle, MCP Apps, and the six authorization proposals that align the protocol with real OAuth and OpenID Connect deployments. It closes with a concrete migration sequence, the risks the specification explicitly leaves to implementers, and the questions engineering leaders should be asking before August.

Why the 2025 Transport Model Broke at Enterprise Scale

The failure mode was operational rather than functional. MCP worked correctly in the 2025-11-25 revision, but it worked correctly only under deployment conditions that enterprises could not sustain. Session affinity is the constraint that quietly dictates your entire infrastructure design. Once a protocol requires it, horizontal scaling stops being a routing concern and becomes a state replication problem.

The sticky session tax

Session pinning forces three separate costs onto a platform team. Each one compounds as the number of MCP servers in an organization grows. The costs are predictable, and most teams running production agent infrastructure have already paid them.

• Load balancers must maintain consistent hashing or cookie-based affinity, which prevents even distribution of long-tail traffic across replicas.

• Shared session stores such as Redis become a hard availability dependency, and their failure takes down the tool calling for every connected agent.

• Rolling deploys and pod evictions terminate in-flight sessions, so clients must detect the failure and rebuild context that the protocol was supposed to hold.

• Gateways cannot route or rate limit intelligently without parsing the JSON-RPC body, which adds latency and couples the edge to protocol internals.

Where the pain actually shows up

The symptom most teams report is not a crash. It is intermittent, unreproducible tool failures that appear only under load or during deployment windows. An agent loses its tool list mid-task, or an elicitation prompt never returns because the Server Sent Events stream was severed by a proxy timeout. Debugging these incidents consumes senior engineering time because the failure is distributed across the client, the gateway, and the server.

KriraAI builds and operates production AI systems for enterprise clients, particularly those scaling SaaS platforms with advanced agent protocols like MCP, and this pattern appears consistently in agent deployments that outgrew their first architecture. The teams that hit it hardest are the ones with the most successful pilots. Success means more concurrent agents, more replicas, and more exposure to exactly the failure modes the session model creates.

What the MCP 2026 Specification Actually Changes

The MCP 2026 specification makes the protocol stateless at the transport layer, making it easier to build scalable distributed systems with modern AI Agent Development Services. Six Specification Enhancement Proposals work together to achieve this, completing a transport plan the maintainers published in December 2025. The practical result is that any request can land on any server instance. Sticky routing and shared session stores are no longer requirements imposed by the protocol itself.

The request shape, before and after

The old flow required two round trips before any useful work happened. A client sent initialize, received a session identifier, then echoed that identifier on every subsequent call. The new flow collapses this into one self-contained request that carries everything the server needs.

The initialize and initialized handshake is removed under SEP-2575, and the Mcp-Session-Id header is removed under SEP-2567. Protocol version, client information, and client capabilities now travel inside the _meta object on every individual request. A tool call in the new revision is a single POST with an MCP-Protocol-Version header and a JSON-RPC body. Nothing about it depends on a prior exchange with that specific replica.

Discovery replaces the handshake.

Removing the handshake creates an obvious question. Clients still need to know what a server can do before they start calling it. The specification answers this with a new server/discover method that clients call when they need capabilities up front. Discovery becomes an ordinary, cacheable request rather than a mandatory connection ritual.

This is the design decision that makes a stateless MCP server operationally boring in the best sense. Capability negotiation becomes optional and on demand rather than blocking and per connection. Clients that already know a server can cache what they learned and skip discovery entirely. The result is fewer round trips on the hot path and no per-connection state to reconcile.

Statelessness Is Not the Absence of State

The most common misreading of this release is that applications must now be stateless. They do not. The protocol stops managing state on your behalf, complementing approaches like Agent Memory Governance for secure, auditable agent systems.

Which is a different claim entirely. Your application keeps whatever state it needs, but it manages that state explicitly rather than hiding it in transport metadata.

The explicit handle pattern

The recommended approach is the pattern HTTP APIs have always used: a tool mints an explicit handle such as a basket identifier, and the model passes that handle back as an ordinary argument on later calls. The state becomes a first-class value in the conversation rather than an invisible header. The maintainers argue this is more powerful than session state, because the model can compose handles across tools and hand them between steps.

There is a real design consequence here that architects should think through. Handles are now visible to the model, which means they are also visible in traces, logs, and evaluation datasets. That improves observability and debuggability substantially. It also means handles must be treated as untrusted input, validated server side, and scoped to the authenticated principal.

Multi-round-trip requests replace held connections.s

Servers still need to ask clients for input mid-call. Elicitation and confirmation prompts are core to safe agent behaviour. SEP-2322 replaces the held SSE stream with an InputRequiredResult that carries inputRequests and an opaque requestState blob. The client collects the answers and reissues the original call with inputResponses and the echoed requestState.

Because everything needed to resume lives in the payload, any replica can pick up the retry. A related change, SEP-2260, now requires that servers issue these requests only while actively processing a client request. That closes a genuine user experience and security gap. Users can no longer receive prompts that appear from nowhere with no traceable origin.

Operating the Traffic: Routing, Caching, and Tracing

Three smaller proposals do disproportionate work for anyone running this infrastructure. They turn MCP traffic into something a standard edge stack can reason about. This is the part of the release that platform engineers will feel first.

Streamable HTTP now requires Mcp-Method and Mcp-Name headers under SEP-2243, so load balancers, gateways, and rate limiters can route on the operation without parsing the body. Servers must reject requests where the headers and the body disagree, which prevents a class of routing confusion attack. This single change lets you apply per-tool rate limits at the edge. It also lets you route expensive tools to dedicated capacity without touching application code.

List and resource read results now carry ttlMs and cacheScope fields modelled on HTTP Cache-Control, under SEP-2549. Clients know exactly how long a tools/list response stays fresh. They also know whether that response is safe to share across users, which matters enormously for multitenant hosts. Cache invalidation no longer requires a long-lived stream.

W3C Trace Context propagation in _meta is now documented under SEP-414, fixing the traceparent, tracestate, and baggage key names. A trace that begins in a host application can now follow a tool call through the client SDK, the server, and downstream services. It arrives in an OpenTelemetry-compatible backend as a single span tree. For any serious enterprise MCP deployment, this is the difference between guessing and knowing.

Extensions Become the Protocol's Growth Path

The second structural change in this release is governance rather than transport. SEP-2133 formalises extensions with reverse DNS identifiers, negotiation through an extensions map on capabilities, dedicated repositories with delegated maintainers, and independent versioning. Capabilities can now ship, mature, and stabilise outside the core specification. This is how the protocol avoids the fate of standards that accrete features until nobody implements all of them.

Tasks graduate and change shape

Long-running work was the most requested capability in the 2025 revision. Tasks shipped as an experimental core feature on 2025-11-25, and production use surfaced enough redesign that the maintainers moved it into an extension instead. A server can now answer a tools/call with a task handle, and the client drives it with tasks/get, tasks/update, and tasks/cancel.

Two details matter for anyone who already built on the experimental API. Task creation is server-directed, meaning the client advertises support and the server decides when a call runs as a task. The tasks/list method is removed entirely, because it cannot be scoped safely without protocol-level sessions. Teams that shipped against the earlier lifecycle need a deliberate migration, not a version bump.

MCP Apps and the sandboxed interface surface

MCP Apps, defined in SEP-1865, lets servers ship interactive HTML interfaces that hosts render inside a sandboxed iframe. Tools declare their UI templates in advance, so hosts can prefetch, cache, and security review them before anything executes. The rendered interface communicates back over the same JSON-RPC base protocol used elsewhere in MCP.

That last point is the important one architecturally. Every action initiated from the UI travels the same audit and consent path as a direct tool call. There is no privileged side channel. KriraAI applies this constraint when designing agent interfaces for regulated clients, because a consistent audit path is what makes an agent system reviewable rather than merely functional.

Authorization Hardening and the Enterprise Identity Layer

Authorization received the most attention of any area in this release. Six SEPs align the specification with how OAuth 2.0 and OpenID Connect are actually deployed in production. The changes are individually small and collectively significant for anyone standing up an enterprise MCP deployment.

The most urgent item for client implementers is issuer validation. SEP-2468 requires clients to validate the iss parameter on authorization responses per RFC 9207, mitigating a class of mix-up attack that is more prevalent in the single client, many server pattern MCP encourages. Future revisions are expected to reject responses that omit iss entirely. Authorization servers should begin supplying it now.

The remaining proposals fix practical deployment friction that has cost teams real time.

• SEP-837 has clients declare their OpenID Connect application_type during Dynamic Client Registration, avoiding servers that default desktop and CLI clients to web and then reject localhost redirects.

• SEP-2352 binds registered credentials to the issuing authorization server and requires reregistration when a resource migrates.

• SEP-2207 documents how to request refresh tokens from OpenID Connect-style authorization servers.

• SEP-2350 and SEP-2351 clarify scope accumulation during step-up authorization and the well-known discovery suffix, respectively.

What Enterprise Managed Authorization covers and what it does not

Running in parallel with the core specification, the Enterprise Managed Authorization extension reached stable status on June 18, 2026, letting organisations centrally provision MCP server access through their identity provider so users get connected servers on first login without per-application OAuth. It builds on Cross App Access and the Identity Assertion JWT Authorization Grant, an IETF draft. Adoption at launch included Anthropic, Microsoft, and Okta.

The boundary of this extension is frequently misunderstood, and getting it wrong creates a false sense of security. The enterprise layer decides whether a user may connect a given client to a given server and at what scope, but it does not inspect MCP traffic after the token is issued. Organisations still need their own controls governing what happens once an agent is inside a system. Connection governance and per-action authorization are different problems.

A Migration Plan for Production MCP Servers

MCP server migration is best treated as a staged programme rather than a cutover. The maintainers have been explicit that nothing already running breaks on July 28, and adoption is opt-in. Beta SDKs for Python, TypeScript, Go, and C# shipped on June 29, 2026, so teams can test the revision now. The sequence below reflects how KriraAI structures protocol migrations for clients running production AI systems.

1. Inventory every MCP server you operate and classify each one by whether it holds state in process memory between calls.

2. For each stateful server, design an explicit handle to replace the implicit session, and decide where that handle's backing state will live.

3. Audit your client authorization code against the six authorization proposals, starting with iss validation, because that is the change most likely to break silently.

4. Replace any server code that holds an SSE connection open for elicitation with the Multi Round Trip pattern using InputRequiredResult and requestState.

5. Rebuild against the beta SDKs and run your servers against the conformance suite scenarios that Standards Track proposals are now required to satisfy.

6. Deploy a stateless variant behind a plain round-robin load balancer, then verify that autoscaling and rolling deploys no longer interrupt in-flight tool calls.

7. Migrate any implementation built on the experimental Tasks API to the new server-directed lifecycle, and remove all dependence on tasks/list.

8. Flip your declared protocol version only after conformance and load testing pass, and keep deprecated features functional throughout.

Two smaller changes deserve a place on the checklist because they break code quietly. The error code for a missing resource moves from the MCP custom -32002 to the standard JSON-RPC -32602 Invalid Params under SEP-2164, so any client matching on the literal old value needs updating. Tool input and output schemas are also lifted to full JSON Schema 2020-12 under SEP-2106, allowing composition, conditionals, and references.

Limitations, Open Risks, and What the Specification Leaves to You

Honest assessment matters more than enthusiasm here, because this release shifts real responsibility onto implementers. Security analysts have noted that the new specification moves critical security responsibilities from the protocol itself to developers and platform operators. That is the inherent trade of statelessness. When the protocol stops holding state, it also stops enforcing the invariants that state made possible.

The first open risk is denial of service through long-running work. Tasks let a client dispatch expensive operations without holding a connection, which is exactly the point. It also means resource consumption is no longer bounded by connection lifetime. Servers must implement their own admission control, quota accounting, and task expiry, and the specification does not prescribe how.

The second risk sits in the requestState blob. It is opaque to the client and carries whatever the server needs to resume. If it is not signed and validated on return, it becomes a tamper surface. Treat it as untrusted input on every retry, exactly as you would a client-supplied cursor or continuation token.

Deprecations, timelines, and the MCP vs A2A protocol boundary

Roots, Sampling, and Logging are deprecated in this release, with tool parameters, direct LLM provider integration, and OpenTelemetry named as their respective replacements. These are annotation-only deprecations, and the feature lifecycle policy guarantees at least twelve months between deprecation and the earliest possible removal. There is no emergency here, but there is a planning horizon.

The MCP vs A2A protocol question also becomes clearer with this release. MCP governs the vertical relationship between an agent and its tools, while A2A governs horizontal coordination between agents. A2A servers publish an AgentCard declaring skills and security schemes, and communicate over JSON-RPC using an eight-state task lifecycle. Production systems commonly run both, with A2A routing work to a specialist agent and MCP giving that agent its tools. Choosing between them is a category decision, not a competitive one.

Conclusion

Three things matter most from this release. The first is mechanical: the MCP 2026 specification makes the protocol stateless by removing the handshake and the session identifier, so every request carries its own context and any replica can serve it. The second is where this matters most, which is any enterprise MCP deployment running multiple replicas behind a load balancer, because sticky routing and shared session stores stop being architectural requirements.

The third takeaway is what to do. Inventory your servers, identify where session state is hiding, replace it with explicit handles, and audit your authorization code against issuer validation before anything else. Treat the twelve-month deprecation window as planning time rather than permission to defer. Teams that migrate deliberately over the coming quarter will avoid the compressed, higher-risk migrations that follow SDK deprecations.

KriraAI builds and delivers production AI systems for enterprise clients, and stays close to the research and standards frontier precisely so that adoption decisions are made on evidence rather than announcement cycles. We do not chase novelty. We adopt emerging techniques and protocols when they are stable enough to produce measurable value, and we design agent architectures that survive the next revision as well as this one.

If your organisation is running agent infrastructure on the Model Context Protocol, or evaluating whether to build on it, the period before August is the right time to assess exposure. We would welcome a conversation about what the MCP 2026 specification means for your specific architecture and roadmap.