MCP Goes Stateless: Inside the Biggest Protocol Update Since Launch

Last year, when I first wrote about the Model Context Protocol, I treated MCP primarily as a context story: a common language that lets AI systems reach tools, data, and prompts without a custom integration for every pairing. That was directionally right. But I was looking at it from the model outward.

The new MCP 2026-07-28 specification made me look at it from the infrastructure inward.

A protocol becomes real when teams can stop treating it as special. Until now, running a remote MCP server at scale still came with protocol-specific machinery: an initialization handshake, a session identifier, sticky routing, and often a shared session store. None of that was impossible. It was simply a tax that ordinary HTTP services had already learned not to pay.

MCP's fifth specification release removes that tax. The protocol is now stateless at its core. Every request can describe itself, any server instance can answer it, and extensions can evolve without repeatedly reopening the core protocol. It is the largest change to MCP since its launch, and probably the clearest sign yet that MCP is moving from an interesting AI convention into production infrastructure.

Before getting into the changes, one naming detail matters. This is not officially called "MCP 2.0." The protocol version is 2026-07-28. Some of the official SDKs have moved to version 2.0, which is probably where the shorthand comes from, but the protocol itself continues to use date-based versions.

There is also a governance detail worth getting right. MCP was created at Anthropic, but Anthropic donated it to the Agentic AI Foundation under the Linux Foundation in December 2025. Anthropic announced the Claude rollout on release day, but this specification was released by the MCP project, not by Anthropic alone.

The protocol had a scaling tax

In the previous architecture, a remote MCP interaction started with an initialize request. The client and server exchanged their protocol versions and capabilities, and the server could issue an Mcp-Session-Id. Later calls carried that identifier back.

That worked well enough when one client was talking to one server process. It became awkward behind a load balancer. A request either had to return to the instance that created the session, or every instance needed access to the same session state.

The result looked like this:

The MCP project's official before-and-after animation makes the change easier to see than another paragraph can:

The new request carries its protocol version, client identity, and capabilities with it. For Streamable HTTP, it also carries Mcp-Method and Mcp-Name headers. A gateway can see that a request is calling a particular tool without opening and parsing the JSON body. A normal load balancer can distribute requests across instances. A serverless function can wake up, handle one request, and disappear.

That sounds like a small transport cleanup. Operationally, it is the difference between building around MCP and running MCP like the rest of the web.

Stateless is not memoryless

The word stateless is easy to misread, especially in a protocol with "context" in its name.

MCP becoming stateless does not mean the agent forgets the conversation. It does not prevent a shopping cart, browser session, workflow, or research task from continuing across calls. It means the protocol transport no longer hides that continuity inside a connection-bound session.

If an application needs state, a tool can return an explicit handle such as basket_id, browser_id, or workflow_id. The model passes that handle into the next call like any other argument.

This is not merely a workaround. The model can see the handle, reason about it, pass it between tools, and preserve it across steps. State still exists where the application needs it. The protocol just stops pretending that every interaction needs a hidden session.

That distinction also corrects a common oversimplification in early MCP discussions, including some of my own: MCP is not itself a persistent-memory system. It is a standard way for an AI application to reach capabilities and context. A connected system may expose memory through MCP, but the protocol and the memory are not the same thing.

Multi Round-Trip Requests replace the held-open conversation

Removing sessions creates an obvious question: what happens when a tool needs something from the user halfway through a call?

Imagine an agent is about to delete three files, approve a purchase, or publish a document. The server cannot silently complete the action, but it also should not open an unrelated prompt whenever it feels like it.

The new answer is Multi Round-Trip Requests, or MRTR. Instead of keeping a bidirectional stream open, the server returns an input_required result. The client collects the missing information or approval, then retries the original request with inputResponses attached.

Generating diagram...

The interaction can span multiple round trips without depending on one server process staying alive. Every retry carries what the next instance needs to continue. It is a cleaner fit for serverless infrastructure and a better security boundary: the user is prompted in response to an action they or their agent initiated, not by an unsolicited server request.

The quieter changes may matter just as much

Statelessness gets the headline, but several less visible changes make MCP more operable.

Tool, prompt, and resource lists are now cacheable. Responses include ttlMs and cacheScope, giving clients an explicit freshness hint and telling intermediaries whether a result is public or private. Servers are also expected to return deterministic ordering, which helps keep prompt caches stable instead of invalidating them because the same tools arrived in a different order.

Change notifications have a new home. Clients can opt into a long-lived subscriptions/listen stream for events such as toolsListChanged, promptsListChanged, and resourcesListChanged. This replaces the older mix of HTTP GET streams and individual subscription methods.

Requests are easier to route and govern. The required Mcp-Method and Mcp-Name headers allow rate limiters, gateways, and web application firewalls to make decisions without inspecting request bodies.

Distributed tracing is finally explicit. The specification documents W3C Trace Context fields in _meta, making it easier to follow an operation from the host application, through the MCP server, and into whatever the server calls next.

These changes are not as easy to demo as an interactive MCP App. They are the things teams notice after an integration has been running for six months and somebody has to debug latency, stale schemas, cache misses, or a request that crossed four services.

Extensions get their own lane

The other structural change is the formal extensions framework.

Earlier MCP revisions kept adding capabilities to the same expanding protocol surface. The 2026-07-28 release establishes a smaller core with versioned, opt-in extensions around it. A client and server advertise which extensions they understand; neither has to pretend every MCP product supports everything.

The first major examples are:

• MCP Apps, which let a server deliver interactive UI inside a supporting host.
• Tasks, which model long-running and asynchronous work through operations such as tasks/get and tasks/update.
• Enterprise-Managed Authorization, which allows organizations to provision MCP access through an identity provider.

This matters because an interactive Figma canvas, a background data migration, and a centrally managed enterprise connector are different problems. They can share the same connection standard without forcing every idea into the protocol core.

In that sense, MCP is beginning to resemble a web platform: a stable base, negotiated capabilities, and room for experiments to mature without breaking everyone else.

Authentication becomes more boring and better

Authorization has been one of MCP's most difficult production problems. The new revision does not make OAuth simple, but it aligns MCP more closely with how OAuth 2.0 and OpenID Connect are actually deployed.

Clients must validate the authorization issuer before redeeming a code. Credentials are tied to the issuer that created them and cannot be casually reused across authorization servers. Dynamic Client Registration is now deprecated in favor of Client ID Metadata Documents, while remaining available during the transition.

The release also introduces a formal deprecation policy with a minimum twelve-month window. Roots, Sampling, Logging, Dynamic Client Registration, and the legacy HTTP+SSE transport are now deprecated rather than abruptly removed.

That policy may be one of the most mature parts of the release. A protocol used by thousands of servers cannot keep evolving like a weekend project. Teams need to know not only what is new, but how long the old path will continue working.

The server side is moving first

The ecosystem did not wait for the final release. The TypeScript, Python, Go, and C# SDKs shipped support for 2026-07-28, with Rust available in beta.

The company announcements reveal a consistent pattern. AWS AgentCore Gateway can advertise the old and new versions at the same time, allowing clients to move independently. Cloudflare's MCP servers now handle each request on a fresh stateless server. Netlify supports the new revision while remaining backwards compatible. GitHub's MCP server adopted the specification before its final release. Microsoft's MCP C# SDK 2.0 and Postman's MCP Inspector arrived alongside it.

This is real day-one support, but it is concentrated in SDKs, servers, gateways, and testing tools. The products people actually speak to are a more uneven story.

The specification is ahead of the clients

"Supports MCP" is no longer a sufficiently precise claim.

A product may connect to a remote MCP server and still not understand the latest protocol revision. It may support tools but not extensions. It may cache a tool catalog without listening for changes. It may expose MCP in an API but not in its consumer voice experience.

Dynamic tools are a good example. MCP has supported tool-list change notifications in some form since its early revisions. Yet an open Codex issue shows Codex receiving the older notifications/tools/list_changed event and logging it without refreshing its available tools. ChatGPT takes a more deliberate enterprise approach: OpenAI's MCP app documentation says updates are not automatically enabled. Administrators refresh the action list, review differences, and approve new actions.

That decision is understandable from a security perspective. A server should not be able to add a powerful write action after an administrator approved a harmless read-only catalog. But it also means the server and client can disagree about which tools exist. The new subscriptions/listen mechanism gives the protocol a cleaner answer; it does not force every product to use it.

Voice exposes another gap between APIs and apps. OpenAI's Realtime API can connect to remote MCP servers, but ChatGPT Voice currently does not support apps. xAI's speech-to-speech API supports remote MCP tools directly. Gemini's Live API documents Search and function calling rather than native MCP, while the regular Gemini Interactions API supports remote MCP.

Even Anthropic's release announcement for Claude says support is being rolled out across Claude products. The company that created MCP did not pretend that publishing a specification instantly made every Claude surface protocol-complete.

That is not a failure of the standard. It is what adoption looks like. But it does mean developers should stop asking, "Does this product support MCP?" and start asking better questions:

• Which protocol revision does it negotiate?
• Does it refresh dynamic tool lists?
• Which extensions does it implement?
• Does it support Streamable HTTP, older SSE, or both?
• Can it handle MRTR and user approval?
• Is MCP available in chat, agents, coding tools, and voice—or only one of them?

A standard at the socket, competition above it

The unevenness does not mean companies are abandoning MCP to build private replacements.

OpenAI co-founded the Agentic AI Foundation and describes MCP as the foundation for connectors and apps in ChatGPT. Anthropic continues to invest in MCP Apps, connector observability, enterprise-managed authentication, and private-network tunnels. Google, Microsoft, AWS, Cloudflare, and others are contributing to the same ecosystem.

At the same time, every vendor is building proprietary layers above MCP: tool search, deferred loading, approval systems, app directories, orchestration runtimes, skills, plugins, observability, and enterprise policy.

That is probably the durable shape of this market.

The connection may be standardized. The agent stack above it will not be.

MCP does not need to define the entire agent platform to succeed. It needs to remain the dependable boundary where a tool can describe itself once and work across many clients. The risk is not that vendors add differentiated features. The risk is that "MCP support" becomes a collection of incompatible subsets hidden behind the same label.

What MCP became

The most important thing about MCP 2026-07-28 is that it makes the protocol less exotic.

Remote servers look more like ordinary HTTP workloads. State becomes explicit. Long-running interactions no longer require a hidden, permanent conversation between two processes. Extensions have somewhere to evolve. Authentication and deprecation behave more like the infrastructure enterprises already understand.

That is a less glamorous story than giving AI "superpowers." It is also a more consequential one.

MCP is growing up from a clever integration pattern into shared agent infrastructure. The server side is already moving. Now the clients have to catch up—and be much more specific about what they mean when they say they support it.

If you are deploying MCP in production or have tested the new revision across different clients, I would love to compare notes. Let's connect on LinkedIn.