The Model Context Protocol just shipped its biggest spec revision since remote MCP launched over a year ago. Version 2026-07-28, published on July 28, kills the initialize handshake, drops the Mcp-Session-Id header, and turns MCP from a bidirectional stateful protocol into a request/response stateless one. Every request now carries its own protocol version, client identity, and capabilities in a _meta field. Any request can land on any server instance behind a plain round-robin load balancer, no shared session store required.
If you have been running MCP servers in production, this is the change you have been waiting for, or the change that breaks your setup. Probably both. Let me walk through what actually changed, what it means, and the tradeoffs the announcement soft-pedals.
The session is gone
The old MCP flow required a client to call initialize, the server to respond with a session ID, and the client to include that session ID on every subsequent request. The server held state for that session. If you wanted to scale horizontally, you needed sticky sessions or a shared session store. If the connection dropped, the session was lost and you started over.
The new spec removes all of that. Here is what a request looks like now:
The method and tool name travel in HTTP headers (Mcp-Method and Mcp-Name), so a gateway, rate limiter, or WAF can route and meter based on headers without parsing the JSON body. That is a genuinely good design choice. HTTP middleware built around header matching now works on MCP traffic without custom plugins.
If your server still needs to carry state across calls, you mint an explicit handle from a tool and have the model pass it back as an argument. The spec authors make the case that this works better than session state hidden in the transport, because the model can see the handle and thread it between tools. That is probably true for simple cases. For complex multi-step workflows where a human would normally think "this is all one session," you are now responsible for the session abstraction yourself.
Multi Round-Trip Requests replace held-open streams
The old protocol had server-initiated requests for things like elicitation (asking the user for confirmation mid-call), sampling, and roots listing. These required a held-open bidirectional stream. The new spec replaces them with Multi Round-Trip Requests, or MRTR. The server returns resultType: "input_required" along with the requests it needs answered, and the client retries the original call with the answers attached.
This is the change I find most interesting. Supabase's head of product put it well in the announcement's quote wall: they wanted elicitations on their roadmap but could not do it because their MCP server runs statelessly. MRTR fixes that. A tool can now confirm a destructive action (deleting a table, creating a billed resource) by bouncing the request back to the client for approval, then resuming.
The tradeoff is latency. What used to be a single round-trip on a held stream is now two round-trips minimum, and potentially more if the server needs multiple pieces of input. For a human-in-the-loop confirmation that is fine. For a tight agent loop that needs server-side reasoning mid-call, it adds overhead. The spec authors seem to have decided that scaling behind a load balancer is worth the latency tax, and given that every major cloud vendor quoted in the announcement was asking for exactly this, I think they made the right call.
List responses are cacheable now
Responses from tools/list, prompts/list, resources/list, and resources/read now carry ttlMs and cacheScope fields. Clients can cache tool catalogs and stop re-fetching them on every reconnect. This sounds boring. It is not boring if you have ever looked at the request volume an MCP client generates when it polls tool lists.
Honeycomb reported that nearly 20% of their monthly interactive queries now come from agents. Tool catalog polling is a meaningful chunk of that traffic. Cache hints let clients skip the re-fetch, and a deterministic order on list responses means the cache stays valid across reconnects. This is the kind of unglamorous spec detail that pays for itself in real infrastructure savings.
Authorization got harder, which is good
The auth changes are where the spec got stricter. Three things changed.
First, authorization servers must return the iss parameter per RFC 9207, and clients must validate it before redeeming a code. This closes a hole where an authorization server could mix up which issuer minted a code.
Second, client credentials are now bound to the issuer that minted them. No reuse across authorization servers. If you were reusing a client secret across environments, you cannot do that anymore.
Third, Dynamic Client Registration is formally deprecated in favor of Client ID Metadata Documents (CIMD). DCR still works for backward compatibility, but the spec is telling you to stop building new stuff on it. The deprecation window is twelve months minimum, which is the formal deprecation policy the spec now locks in.
The announcement also mentions that application_type during DCR lets authorization servers stop rejecting localhost redirects for desktop and CLI apps. If you have ever debugged an OAuth flow where your CLI client got a redirect_uri error for no obvious reason, this is probably the fix.
Tasks, deprecations, and the twelve-month clock
Tasks moved out of the experimental core and into the io.modelcontextprotocol/tasks extension. Long-running agent work now has a poll-based tasks/get and a new tasks/update. Change notifications moved to a single subscriptions/listen stream that clients opt into per notification type. This is AWS's contribution, and it is the piece that makes long-running agent tasks viable without a held-open connection.
Three things are now deprecated: Roots, Sampling, and Logging. They still work and will keep working for at least twelve months. New implementations should not adopt them. The legacy HTTP+SSE transport is also deprecated with the same year-long offramp.
The formal deprecation policy is the quiet improvement here. A twelve-month minimum window means you can plan upgrades on your schedule instead of reacting to breaking changes. For a protocol that crossed one billion total downloads across its TypeScript and Python SDKs, that predictability matters. Teams running MCP in production now have a contract for how long old behavior stays supported.
The migration cost
The announcement acknowledges migration will be rough. Jeremiah Lowin from FastMCP said FastMCP 4.0 ships first-class support, but the breaking changes are real. If you depended on session identifiers, you are rewriting your client. If you used Roots, Sampling, or the HTTP+SSE transport, you are on a twelve-month migration clock. If your server used server-initiated requests for elicitation, you are porting to MRTR.
Manufact's CTO reported the new SDK v2 cut their package size by 83% and made it 25% faster, which suggests the old SDKs were carrying a lot of session-state machinery that is now gone. That is a nice side effect of the redesign. It also means the SDK API surface changed, so your existing server code needs adjustment, not just a version bump.
My read: the migration is worth it. Stateless HTTP is the most boring, most understood, most scaled workload on the planet. MCP was trying to be a fancy bidirectional protocol, and now it is just HTTP with some headers and a JSON body. Every load balancer, every CDN, every WAF, every observability stack, every autoscaler already knows how to handle that. The protocol grew up.
What this means for the agent ecosystem
The practical impact depends on where you sit.
If you run MCP servers behind a load balancer, you no longer need sticky sessions. You can deploy to any cloud, any container runtime, any serverless platform that speaks HTTP. The Supabase and Cloudflare quotes confirm this. Stateless is the unlock for running MCP at the scale where thousands of agents hit your server concurrently.
If you build agent harnesses, you lose the convenience of a session abstraction. You need to manage handles explicitly if your workflow has state. The spec's argument is that explicit handles are better because the model can see them, and I buy that for simple cases. For complex workflows, you are now writing your own session layer. That is work you did not have to do before.
If you care about authorization and security, the tightening is unambiguously good. RFC 9207 issuer validation, issuer-bound credentials, and the move away from DCR all reduce real attack surface. The auth section is the part of the spec where the changes have the clearest security justification.
If you are just consuming MCP tools from an agent, you probably do not notice anything. The SDKs handle the migration. Your tools still work. The fact that servers can now scale horizontally means you get better reliability as a side effect.
What I am watching next
The spec is shipping today with matching SDKs for TypeScript, Python, Go, and C#. Rust is in beta. The extension framework is now formal, with Tasks joining MCP Apps and Enterprise Managed Authorization as official extensions.
The thing I want to see is how fast the ecosystem moves. Twelve months is a generous deprecation window, but the companies quoted in the announcement are already on the new spec. The question is how fast the long tail of community MCP servers, the ones running on a single VPS behind a hobbyist agent setup, migrate. Those servers do not have a dedicated team to port from sessions to stateless. They will be the ones still running the old spec in eleven months, and they are the ones who will break when the deprecation window closes.
The announcement ends with an honest line: "the most interesting part will be seeing the unexpected things people build with it." Stateless HTTP with tool calls is a simple primitive. Simple primitives get bent into shapes the designers did not predict. I am betting someone will build an MCP server that caches tool results in a CDN layer using the new cache hints, and that will be a thing people copy. The cache hints are the sleeper feature of this release.
MCP version 2026-07-28 is available now. The spec, changelog, SDKs, and migration guides are linked from the announcement. If you are running MCP servers in production, read the migration notes before pulling the trigger. The breaking changes are worth it, but they are breaking, and they will not fix themselves.