Most technology leaders still talk about the Model Context Protocol the way they talked about it eighteen months ago: a promising but early integration layer that connects agents to tools, worth watching but not yet worth building enterprise infrastructure around. That assumption no longer holds. The TypeScript and Python SDKs have each crossed one billion total downloads, and the ecosystem is now running close to half a billion downloads a month across the Tier 1 SDKs. The 2026-07-28 specification release is the clearest evidence yet that MCP has stopped behaving like an early-stage protocol and started behaving like production infrastructure, and the changes in this release are the kind that only get made once real deployment experience forces the issue.
The most consequential change in this release is architectural, not cosmetic. MCP has retired the initialize/initialized handshake and the Mcp-Session-Id header entirely. Every request now carries its own protocol version, client identity, and capabilities, and a server can answer it without any memory of what came before. A client that wants a server's capabilities up front can call the new server/discover method, but nothing in the protocol requires it.
The practical effect is that any request can land on any server instance behind a plain round-robin load balancer, with no shared session store and no sticky routing. Organizations running MCP servers at scale have spent the last year building workarounds for exactly this problem: session affinity rules, shared Redis stores for session state, and retry logic for when a load balancer sends a follow-up request to an instance that has never heard of the client. Removing the session from the protocol layer removes the need for most of that infrastructure.
This does not mean applications built on MCP must themselves be stateless. The maintainers were explicit that state which needs to persist across calls should be minted as an explicit handle by a tool and passed back by the model as an argument, rather than hidden in the transport. That is a meaningful design choice. State that a model can see and reason about is state a model can be governed on. State hidden in a session header is not.
Server-initiated calls back to the client, for elicitation, sampling, and root listing, previously required a bidirectional stream that stayed open for the life of the interaction. Multi Round-Trip Requests replace that with a pattern that fits the new stateless core: a server that needs something from the user returns resultType: "input_required" along with the specific requests it needs answered, and the client resubmits the original call with the answers attached.
Consider a tool that deletes records or provisions infrastructure. Under the old model, getting a confirmation from the user required an open stream for the duration of the call. Under MRTR, the server can ask, the client can answer on its own schedule, and the whole exchange still fits inside a stateless request and response cycle. Several implementers, including the teams behind Supabase MCP and Cloudflare's Agents SDK, have already pointed to this as unlocking approval flows they could not build under the old transport model without giving up statelessness. That is a genuine expansion of what a stateless protocol can safely do, not a workaround.
The MCP maintainers have said directly that authorization is where implementers spend most of their integration time, and this release is more a response to a year of support tickets than a theoretical security exercise. Three changes matter most.
Issuer validation, per RFC 9207. Authorization servers now return an iss parameter, and clients must validate it before redeeming a code. This closes an authorization-server mix-up vulnerability class where a client could be tricked into exchanging a code with the wrong authorization server. This is the kind of gap that shows up in a real security review of an OAuth-based integration, and MCP closes it at the protocol level instead of leaving it to every implementer to catch independently.
Client ID Metadata Documents replacing Dynamic Client Registration. DCR continues to work for backward compatibility, but it is formally deprecated. CIMD is the direction, and organizations building new MCP clients should plan for that now rather than building fresh integrations against a mechanism the specification has already marked for removal.
Credential binding to the issuer that minted them. Client credentials can no longer be reused across authorization servers, closing another cross-server confusion path.
These are the standard hardening moves that any organization running OAuth-based integrations at scale eventually has to make, and MCP has now made them mandatory at the protocol level rather than optional at the implementation level.
Two smaller but operationally significant changes round out this release. Streamable HTTP requests must now include Mcp-Method and Mcp-Name headers, which means a gateway, rate limiter, or web application firewall can route and meter traffic without parsing the JSON body of every request. And responses from the list and read methods now carry cache hints and a deterministic order, which lets clients cache tool catalogs and keep prompt caches stable across reconnects instead of re-fetching and re-serializing the same tool list on every session.
These changes allow for a MCP gateway that scales cleanly rather than one that has to open and inspect every request body to do its job.
Roots, Sampling, and Logging have been deprecated, and the legacy HTTP+SSE transport is on a twelve-month offramp. Organizations with MCP integrations that depend on session identifiers or the older transport have real migration work ahead, not a configuration flag to flip. The maintainers have committed to a formal deprecation policy with a minimum twelve-month window, which is a meaningful commitment, but it does not eliminate the work. Teams that built infrastructure specifically to manage session affinity should plan to decommission it deliberately rather than assume it becomes dead weight automatically.
MCP was never going to stay a promising early protocol forever. This release is the point where it stops asking to be trusted with production traffic and starts being built for it.
Let's talk about where you are today and where you want to go - our experts are ready to help you move forward.
