Every MCP server running in production today was designed around a session. That session - the initialize handshake, the Mcp-Session-Id header, the sticky infrastructure holding it together - is gone as of today, July 28, 2026.
The update finalizes MCP's transition to a fully stateless architecture, hardens its authentication model, establishes a formal 12-month deprecation policy, and graduates two headline capabilities - interactive server-rendered interfaces and long-running asynchronous tasks - into official protocol extensions.
This is not an incremental spec bump. MCP's maintainers describe the 2026-07-28 revision as bringing "the most substantial changes we have made to the specification, probably since adding authorization." If you run a remote MCP server, or your agent framework calls one, the question is not whether this affects you - it does - but how much migration you actually have to do right now.
Why sessions were always the wrong foundation
Sessions made sense when MCP servers ran on a developer's laptop. Back then, developers primarily used the protocol on their personal computers - as those laptop-bound demos were adapted for multi-client enterprise use, MCP servers moved into the cloud, where the original design quickly created scalability problems.
The concrete problem: load balancing was impractical. Because a client was "pinned" to whichever server instance held its session, standard round-robin load balancers couldn't distribute traffic - you needed sticky sessions or a shared session store, infrastructure overhead that has nothing to do with MCP's purpose.
The fix is complete removal, not patching.
The initialize/initialized handshake and the Mcp-Session-Id header are eliminated entirely. Routing information moves into per-request headers - new Mcp-Method and Mcp-Name headers describe what each request is, so any request can land on any server instance with no requirement that repeat requests hit the same machine.
A remote MCP server that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer, route traffic on an Mcp-Method header, and let clients cache tools/list responses for as long as the server's ttlMs permits.
What the spec actually breaks for builders
The stateless model is not a blanket non-event. Servers using the 2026-07-28 revision may not work with older clients, and vice versa. "Compatibility requires both sides to share a supported protocol era, or for one side to implement deliberate fallback or translation."
The sharpest edge is elicitation. Old-spec servers could push a request back to the client mid-call over the open SSE connection. That pattern no longer exists.
Multi Round-Trip Requests (SEP-2322) replaces server-initiated calls like sampling and elicitation. A server returns an InputRequiredResult carrying inputRequests plus an opaque requestState; the client gathers answers and re-issues the original call with inputResponses. This fits the stateless model because all state lives in the payload, not a held connection.
The safety property this creates is worth calling out: server-initiated requests may now only be issued while the server is actively processing a client request. Earlier spec versions recommended this; it's now required. A user is never prompted out of nowhere, and every elicitation traces back to something they (or their agent) started.
If you have a gateway in front of your servers, check what version translation it supports. A gateway that fronts an MCP server target upgrading to 2026-07-28 before its clients do can translate between versions - but this translation does not currently support elicitations and sampling calls from servers to clients. If a 2025-* client calls a tool on a 2026-* server that requires elicitation, it receives an error.
The other explicit break: anyone who shipped against the experimental 2025-11-25 Tasks API must migrate to the new extension lifecycle. The Tasks extension is now governed under the formal extensions framework, which means it has its own versioned lifecycle - not the protocol's.
Enterprise-Managed Authorization is the quieter change that matters more
For most teams, the stateless transport change is a migration checklist. The Enterprise-Managed Authorization (EMA) extension is a policy change with real access-control consequences.
The standard MCP authorization model is user-scoped: every employee authorizes every server, one OAuth consent screen at a time. In a large enterprise deployment, that means manual onboarding per tool, no central audit trail, and no way to stop someone from connecting a personal account to a work server.
EMA makes the organization's identity provider the authority for MCP server access: a client obtains an Identity Assertion JWT Authorization Grant from the IdP during single sign-on and exchanges it for an access token from the MCP server's authorization server, so the user is never redirected through a per-server consent screen. Admins enable a server once for the org; users inherit access automatically, scoped to whatever groups and roles they already hold.
That is a meaningful shift. The old model put authorization decisions at the user layer; EMA pulls them up to the admin layer, where IT can enforce them. For any team that has been letting individuals connect MCP servers to their own accounts without central visibility, this is the change most worth acting on.
Beagle in action#platform-eng, 11:02amHow to decide what to migrate now versus later
The 12-month deprecation window is real runway, not a soft suggestion. Features formally marked as deprecated will remain functional for at least 12 months; Stacklok warns that this is not a blanket guarantee of interoperability with legacy implementations.
A practical triage:
Migrate now if your server uses
Mcp-Session-Id, sticky sessions, or a shared session store - these are the things that actively block horizontal scaling.Migrate now if you use the experimental Tasks API from 2025-11-25. Anyone who shipped against the experimental 2025-11-25 Tasks API must migrate to the new extension lifecycle.
Evaluate EMA now if you are onboarding more than a handful of engineers to a shared MCP server - the per-user consent model does not scale.
Defer if you use roots, sampling, or HTTP+SSE only - these are deprecated with the 12-month window, not removed.
| What you have | Urgency | Why |
|---|---|---|
Mcp-Session-Id in headers |
High | Incompatible with 2026-07-28 servers |
| Experimental Tasks (2025-11-25) | High | API replaced; explicit breaking change |
| SSE-based elicitation | Medium | Replaced by Multi Round-Trip Requests |
| Per-user OAuth consent | Medium | EMA is available; old model still works |
roots or sampling |
Low | Deprecated, 12-month runway |
Beta SDKs for Python, TypeScript, Go, and C# shipped June 29, 2026, so teams can test the new revision now, and the MCP maintainers are explicit that nothing already running breaks on July 28 - adoption is opt-in.
The non-obvious thing here: MCP 2026-07-28 is designed to be the last revision that breaks compatibility. The formal deprecation policy and the extensions framework exist precisely so that future capabilities - whatever comes after Tasks and MCP Apps - ship without requiring another migration sprint. The disruption is front-loaded by design.
tools/list responses are cached by ttlMsMCP stateless protocol: common questions
What does it mean for MCP to go stateless?
Stateless means every MCP request carries its own protocol version, identity, and capabilities - no prior session required. The server processes the request and returns a response; it holds nothing between calls. This lets any server instance handle any request, which makes standard HTTP load balancing work without sticky sessions or shared state.
Do I have to upgrade my MCP server on July 28?
No. The MCP maintainers are explicit that nothing already running breaks on July 28 - adoption is opt-in. The old spec continues to work within the 12-month deprecation window. The urgency applies only if you need to interoperate with new 2026-07-28 clients or servers, or if you shipped against the experimental 2025-11-25 Tasks API.
What is Enterprise-Managed Authorization in MCP?
EMA makes the organization's identity provider the authority for MCP server access: a client obtains an Identity Assertion JWT Authorization Grant from the IdP during single sign-on and exchanges it for an access token from the MCP server's authorization server, so the user is never redirected through a per-server consent screen. One admin action enables a server for the entire org.
What happens to server-initiated elicitation in the new spec?
The SSE-based elicitation model is replaced by Multi Round-Trip Requests.
A server returns an InputRequiredResult carrying inputRequests plus an opaque requestState; the client gathers answers and re-issues the original call with inputResponses.
A 2025-spec client calling a 2026-spec server that requires elicitation will get an error - the gateway translation gap is the immediate practical risk.
What are MCP Apps and the Tasks extension?
They are the two new official extensions that ship with this revision: server-rendered UIs through MCP Apps, and long-running work through the Tasks extension.
Both now have their own versioned lifecycle under the extensions framework, which means they can evolve independently of the core protocol spec. Teams using Beagle or similar agents that call long-running tools should check whether their MCP client handles Tasks extension responses gracefully even if it does not yet implement the full extension.