MCP’s largest rewrite yet drops protocol-level sessions and hardens OAuth, but the deprecation policy underneath is what actually makes it behave like infrastructure.
Model Context Protocol’s biggest update since its 2024 launch carries a claim buried in its own spec text. The protocol had been built like a research prototype, and the 2026–07–28 revision exists to make it behave like infrastructure instead.
Few features in the release matter as much as that prototype-to-infrastructure framing, and it changes how you should read everything else that shipped on July 28.
The 2026–07–28 specification, finalized yesterday after a ten week release candidate window that started May 21, is the largest revision since MCP launched. Six Specification Enhancement Proposals work together on the transport layer alone, and several more touch authorization, tool schemas, and how the protocol governs itself going forward.
The initialize handshake is gone (SEP-2575), along with the Mcp-Session-Id header that used to pin a client to one server instance (SEP-2567). Removing both changes three things at once:
Under the 2025–11–25 spec, calling a tool meant opening a session first, then carrying its ID on every call after that:
Under 2026–07–28, the same call is one request, routable to any server instance, with client info riding along in _meta instead of a prior handshake:
A stateless protocol still needs a way for a server to ask the client for something mid-call, an elicitation prompt being the common case. Two SEPs rebuild that flow so it works without a persistent connection:
The client gathers the answer and re-issues the original call with inputResponses and the echoed requestState. Because everything the retry needs travels in the payload, any server instance can pick it up, not just the one that asked the question.
Three smaller changes make the resulting traffic easier to operate at scale:
Gateway and hosting products that sit in front of MCP servers, from Docker’s MCP Gateway to Cloudflare’s Workers-based MCP hosting to Azure API Management to MCP360, inherit this routing simplification directly. None of them need to keep a client pinned to a specific instance anymore, which is exactly the operational complexity this part of the spec was written to remove.
MCP Apps (SEP-1865), server-rendered UIs in a sandboxed iframe, and the Tasks extension, long-running work that used to be bolted onto the core spec, both move into their own versioned repositories with dedicated maintainers. A broader extensions framework (SEP-2133) now backs both: extensions get reverse-DNS IDs, get negotiated through an extensions map on client and server capabilities, and version independently of the core spec.
Extensions negotiation matters for anything sitting between a client and many MCP servers. Gateway products in that position, among them Kong’s AI Gateway, Bifrost, MCP360 and MintMCP, now need to pass a downstream server’s advertised extensions through to the client rather than terminate them at the gateway, or an extension a server offers never reaches the client that could use it.
Clients must now validate the iss parameter on authorization responses under RFC 9207 (SEP-2468), closing a mix-up attack path that is more common in MCP’s one-client, many-server pattern than in typical OAuth setups.
A feature lifecycle shows up for the first time (SEP-2577): Active, Deprecated, Removed, with a mandatory twelve month window between the last two.
Read individually, these look like cleanup. Read together, they describe a protocol choosing a different identity.
The same deprecation policy immediately does its first job. Three features that shipped in earlier spec versions move to Deprecated status, each with a named replacement rather than a vague sunset notice:
These are annotation-only deprecations. The methods, types, and capability flags keep working in this release and in every specification version published within a year of it. Removing any of them outright will need its own separate proposal under the lifecycle policy, not a quiet drop in a future changelog. If your server or client still leans on any of the three, the twelve month minimum gives you a concrete planning window rather than an open-ended one.
Tool inputSchema and outputSchema are lifted to full JSON Schema 2020–12 (SEP-2106). A few specifics worth knowing before you touch a tool definition:
The easy story about the stateless rewrite is operational. No more sticky sessions, no shared session store, no deep packet inspection at the load balancer just to route a request. The story is true, and it will save real infrastructure cost if you’re running MCP servers at scale. It also misses what actually happened architecturally.
For two years, MCP kept state the way a research prototype keeps state. It pinned state to whichever process happened to answer the first request, the fastest way to ship something that works in a demo. It is also the same design HTTP itself carried in its early cookie-and-session era, before REST convinced a generation of API designers to put state in named, addressable resources instead of hiding it in the transport layer. MCP is completing a plan the maintainers laid out in The Future of MCP Transports back in December 2025. Servers that need state across calls now mint an explicit handle, a basket ID, a browser ID, and hand it back to the model as an ordinary argument. The handle stays visible to the model instead of hidden in a header, which means the model can reason about it, pass it between tools, and inspect it in ways a buried session ID never allowed. If you’re building tool servers, design around visible state from the start.
The explicit handle pattern is a small technical choice with a real philosophical claim underneath it. An agent protocol should expose state to the thing doing the reasoning, instead of hiding it for the sake of transport convenience.
The part of this release most readers will skip past is a single requirement buried near the bottom of the spec announcement, and it turns out to be more consequential than the stateless rewrite.
A Standards Track proposal can no longer reach Final status until a matching scenario lands in the conformance suite (SEP-2484), the same suite the SDK tier system scores official SDKs against. Most fast-moving AI tooling projects run on a ship-and-break culture instead. A capability lands, gets used in production, then gets redesigned six months later because nobody wrote the constraint down the first time.
Tasks is the proof inside this very release. It shipped experimental in the previous spec version, saw production use, and needed a full redesign before it could graduate to an extension. If you shipped against the experimental Tasks API in the previous spec version, plan to migrate to this new lifecycle rather than assume it carries over. tasks/list is gone entirely in the new design, since it cannot be scoped safely without protocol-level sessions to anchor it to. The deprecation policy and the extensions framework exist to stop the ship-then-redesign cycle from repeating. New capabilities now ship as opt-in extensions, version independently, and only enter the core spec once they have proven themselves.
Tying spec status to test coverage is how every protocol that survives ends up behaving, whether it is TCP/IP, HTTP, or SMTP. The interesting part is watching an AI-era protocol get there in two years instead of two decades, because the field around it is moving too fast to afford the slow version.
The authorization changes are easy to skim past because they read like a list of RFC numbers. They are the clearest signal in the whole release about who MCP is now being built for.
Requiring iss validation addresses a real attack class in exactly the deployment shape MCP creates: one client application, potentially dozens of MCP servers, each capable of pointing at its own authorization server. If your authorization server doesn’t supply iss yet, this is the moment to add it, since a future spec version is expected to require clients to reject responses that omit it.
Declaring OpenID Connect application type during dynamic client registration (SEP-837) fixes a specific, common failure where a desktop or CLI client gets misclassified as a web client and has its localhost redirect rejected outright. Binding registered credentials to the issuing authorization server (SEP-2352) closes a gap that only shows up once an organization migrates a resource between identity providers, the kind of migration that happens once real enterprises are already relying on this.
Three smaller SEPs round out the authorization work:
None of these are demo-day features. They are the kind of hardening that shows up after a protocol has been through enough security review to have a list. An agent protocol earns that list by getting adopted by teams whose job is to say no. MCP earning that list this early is a leading indicator for where the protocol is headed.
Agent protocols are still mostly judged by how exciting the first demo looks: how fast a new developer can wire up a tool call, how impressive the agent looks doing something autonomous on stage.
Infrastructure gets judged by a different standard over the long run: how invisible it becomes, whether it scales without special-casing, survives ten years of extensions without a rewrite, and lets a security team say yes without a six month review. MCP’s July 28 rewrite is built for that standard.
Watch what happens next across the rest of the agent protocol space. Google’s A2A protocol, built for agent-to-agent coordination rather than agent-to-tool calls, is governed by the same Linux Foundation umbrella MCP now sits under, and it is a reasonable bet that A2A follows a similar arc as its own usage scales past demos. If you’re deciding which agent protocol to build serious infrastructure against next, watch for the same sequence MCP just went through: a governance document, a conformance suite, and a deprecation policy, arriving in that order, from a protocol that decided early on to be boring on purpose.
Model Context Protocol’s 2026–07–28 Spec Puts Governance Before Speed was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.