On July 28, MCP maintainers plan to finalize the protocol’s 2026-07-28 revision, and it is not a “minor update.” Anthropic technical staff member David Soria Parra says this is the biggest overhaul since MCP’s launch because “a lot of things that made MCP are gone,” and he flags that some of the changes are not backward compatible.

The headline stake is protocol sessions. In the new MCP revision, protocol-level session tracking will no longer be required, because MCP becomes stateless. Instead, information about protocol version, client identity, and capabilities travels in the _meta parameter with each request. That design shift sounds clean in theory, but it has direct operational consequences, and Parra is blunt about what it means for teams who built their own MCP servers: “If you built your own implementation, it's going to be a lot of uplift to make this correct.”

To understand why this is a big deal, rewind to how MCP started. When Anthropic released the first version of MCP in 2024, it was initially used in laptop-bound demos. As those demos moved toward multi-client enterprise use, MCP servers drifted into the cloud, where the original session-heavy design quickly ran into scalability and operational friction. Parra points to “hard lessons” learned over the past two years, including that the original specification failed to properly define how session details should be preserved. That ambiguity made it harder to build reliable systems, especially when routing and extra resources got involved.

Now the core team is rebalancing the protocol around how modern cloud systems actually scale. Statelessness is common in the internet world: requests can be handled independently by a fleet behind load balancers. Under the new revision, each request carries the needed context, so the infrastructure does not need to maintain protocol sessions as a prerequisite. Parra even frames it as moving state away from the server and onto the wire protocol, “and hope that bandwidth is for free.” The parallel he draws is explicit: the new MCP operates very much like the Claude Messages API, which is also stateless.

This is not just a software architecture tweak. Parra also says the underlying data transfer mechanism has been “totally rebuilt,” which “makes things on the wire a bit more complicated than they used to be.” That matters because interoperability is a two-sided game. Stacklok’s “Enterprise Readiness Guide for the July 2026 MCP Spec Update” warns that deprecated features will remain functional for at least 12 months, but that there is no blanket interoperability guarantee with legacy implementations. Servers using the 2026-07-28 revision may not work with older clients, and vice versa. In other words: planning upgrades is not optional if you care about production continuity.

The spec overhaul also guts routing. The original MCP used JSON-RPC with operation buried in the JSON body sent over JSON-RPC HTTP POST payloads. The new revision mirrors routing information in HTTP headers, which allows networking gear to route requests without tracking session status or inspecting the JSON-RPC body. If you run security tooling, traffic controls, or platform routing rules, this affects how your systems “understand” MCP traffic at the network layer. It also changes where the operational complexity lives: from session orchestration to request metadata and header-level routing.

Meanwhile, MCP is trimming features that didn’t earn their keep. Sampling is deprecated because it was rarely used and semantics were confusing and hard to implement, Parra says. Roots is also deprecated; it lets clients tell servers which file system locations are relevant to a session, but Parra calls it “a very niche thing.” Logging is getting narrowed too. Developers were advised to use stderr, stdio, or OpenTelemetry because MCP logging was considered excessively chatty.

The strategy behind the narrowing is clear: keep the pieces “everybody is actively using,” while expanding through extensibility instead of expanding the core spec indefinitely. Den Delimarsky explains extensions as a way to test protocol ideas before they get baked into the standard. Extensions can have their own release schedule, and experimental behavior can be prototyped there rather than forcing every user to absorb it. An official extension is MCP Apps, which lets MCP present an interactive app built in JavaScript instead of only text or an image. And MCP’s Tasks feature, which manages long-running operations, has moved out of the core protocol and into an extension. Users can also build their own extensions following the specification’s instructions.

Finally, the compliance and enterprise governance angle is hard to ignore. 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. That scale makes “breaking changes” feel like a board-level risk, not a developer inconvenience.

Stacklok CEO Craig McLuckie, co-creator of stateless Kubernetes, calls the move from stateful to stateless “necessary.” He argues that the stateful nature of MCP was a by-product of its origins in supporting developers using local coding tools to access resources. Now, as the broader AI community adopts MCP as a mechanism to let enterprises intermediate access to production systems, statelessness gives cyber teams a unified control point to apply agent-aware policy in a form factor platform teams are comfortable running. For executives managing AI platforms, security architecture, and vendor interoperability, the 2026-07-28 revision is a forcing function: either your MCP integration roadmap keeps up, or your “agent” layer becomes a compatibility maze across clients, servers, and internal implementations.