Model Context Protocol prepares to break with its stateful past

AI seemed simpler in 2024 when Anthropic released the first version of the Model Context Protocol (MCP), an open standard for connecting AI applications to external systems.

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.

On July 28, MCP's maintainers plan to finalize the protocol's 2026-07-28 revision, bringing many changes – including some that aren't backward compatible – that reflect some "hard lessons" the core MCP team learned over the past two years, said Anthropic technical staff member David Soria Parra in a livestream Tuesday.

The 2026-07-28 revision will come with the "most substantial changes we have made to the specification, probably since adding authorization," Parra said. "A lot of things that made MCP are gone."

Parra claims the new MCP will be easier to deploy and use. If users have been updating their SDKs, they shouldn't have much problem upgrading.

But he also warned that the underlying data transfer mechanism has totally been rebuilt, which "makes things on the wire a bit more complicated than they used to be." Protocol-level session tracking will no longer be required.

For those who rolled their own MCP engine, some long days of reconfiguration may be ahead. "If you built your own implementation, it's going to be a lot of uplift to make this correct," Parra admitted.

Anthropic donated MCP in 2025 to the AAIF, a Linux Foundation fund co-founded by Anthropic, Block, and OpenAI. By that time, the SDK was being downloaded over 97 million times a month and at least 10,000 MCP servers had been set up.

MCP is now stateless like the rest of the internet

The chief change is that the new revision removes protocol-level sessions, allowing each request to be handled independently. This "stateless" approach, common in the cloud-native world, is used to scale web services behind a fleet of load balancers.

Anthropic originally built MCP so that servers could be built to expose resources, tools, and prompts. An LLM-connected application can host clients to communicate with these servers via JSON-RPC 2.0. 

However, this approach came with excessive complexity and operational difficulties, especially creating and supervising protocol sessions for every individual action. As Parra acknowledged, the original specification failed to properly define how session details should be preserved, leading to complications. Furthermore, routing grew overly intricate when extra resources were required.

The solution was simple. Under the new revision, information about the protocol version, client identity, and capabilities travels in the _meta parameter with each request, eliminating the need for protocol session tracking.

MCP now operates very much like the Claude Messages API, also stateless, which provides the interface for sending and receiving messages with Anthropic's models.

"I think that it's a very smart and nice way to just move… state away from the server onto the wire protocol and hope that bandwidth is for free," Parra said.

MCP's routing mechanism was also totally gutted. The original messages were sent over JSON-RPC HTTP POST payloads, with the actual operation buried in the JSON body. The new revision also mirrors routing information in HTTP headers, allowing networking gear to route requests without tracking session status or inspecting the JSON-RPC body.

MCP can now be extended however you desire

A number of features in the original MCP have also been deprecated. One is sampling, which seemed useful at the time but turned out to be used rarely. It allowed an MCP server to ask the client's model to generate a completion, but the semantics were confusing and hard to implement, Parra said. 

Roots was also deprecated. It allows clients to tell servers which file system locations are relevant to a session. It was "a very niche thing," Parra said. Logging also got its notice for being excessively chatty, and developers were advised to just use stderr, stdio, or OpenTelemetry. 

"We are widening the surface to the things we thought were useful, but we are also realistic about narrowing [MCP] down to the good pieces that everybody is actively using," Parra said. 

MCP also has been enhanced with extensibility. "I think the extensions are a model for us to really test out things in the protocol before we bake them into the protocol," said Den Delimarsky, an Anthropic technical staff member who also joined the conversation.

There are many use cases that are domain specific where an extension would be helpful, but the potential user base is not big enough to warrant rolling that feature out to everyone. And experimental features will be tested through extensions. 

Extensions can be bundled with the protocol, but have their own release schedule. One official extension is MCP Apps, which allows the MCP to present the user with an interactive app, built in JavaScript, instead of just text or an image. 

MCP's Tasks feature, used for managing long-running operations, has been moved out of the core protocol and into an extension.

In addition to officially recognized extensions, users can build their own, following the instructions and suggestions in the specification, Parra said. 

Features formally marked as deprecated will remain functional for at least 12 months, according to Stacklok's "Enterprise Readiness Guide for the July 2026 MCP Spec Update." Stacklok, which offers an MCP platform, warns that this is not a blanket guarantee of interoperability with legacy implementations. 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 report noted.