MCP 2026-07-28 Update: Stateless Protocol, New Auth

The connective tissue of the agent ecosystem just got its largest rewrite. On July 28, 2026, the Agentic AI Foundation — the Linux Foundation directed fund that now stewards the project — published the 2026-07-28 revision of the Model Context Protocol (MCP), the standard that lets AI applications call external tools, read data sources, and drive other systems. Maintainers describe it as the biggest change to MCP since it launched, and it reaches deep into how production servers are built, deployed, and secured.

The revision does four consequential things at once: it removes protocol-level sessions, deletes the initialization handshake, deprecates three long-standing features, and rewrites authorization around token validation. It also introduces a formal extensions framework meant to govern how the protocol evolves from here. Taken together, the changes push MCP from a design shaped by local, single-machine tools toward one built for distributed, multi-tenant deployments.

Sessions are gone

The headline change is the elimination of the stateful session model at the protocol layer. Under the prior 2025-11-25 spec, a remote MCP server established a session that pinned a client to a specific server instance. That single design decision rippled through every serious production deployment. Operators needed sticky load-balancer routing to send a client’s follow-up requests back to the same instance, a shared session store — typically Redis — so instances could coordinate, and often request-body inspection at the gateway to extract the session identifier before routing.

The 2026-07-28 spec removes that machinery. A cluster of Specification Enhancement Proposals — the process the project uses to ratify changes — retires the protocol-level session, with SEP-2567 removing the construct that bound a client to one instance. The practical result is that any server instance can now handle any request. Statelessness at the protocol layer means MCP servers behave like ordinary HTTP services: horizontally scalable, trivially load-balanced, and far cheaper to run at scale. Servers that need continuity across calls must now manage it themselves, in application state, rather than leaning on the protocol to do it.

The handshake is deprecated

Closely related is the removal of the initialize/initialized handshake, retired under SEP-2575. Previously, a client and server exchanged an opening round trip to negotiate protocol version and advertise capabilities before any real work began. That handshake assumed a persistent connection — exactly the assumption the session change is designed to break.

In its place, the protocol version, client information, and client capabilities now travel in a _meta field attached to every request. A new server/discover method lets a client fetch a server’s capabilities on demand rather than negotiating them up front. The effect is a protocol where each request is self-describing and self-contained — no prior context required — which is precisely what a stateless, any-instance-answers model needs.

Three features marked for retirement

The spec deprecates three core features that have been part of MCP since its early days: Roots, Sampling, and Logging. Deprecation here is a signal, not an immediate removal. The project has committed to documented replacements for each and at least 12 months of continued function, giving implementers a runway to migrate rather than a cliff. Server and client authors who lean on these features should read the migration notes now and plan the transition inside that window.

Authorization, rewritten

The most security-relevant work is the authorization rewrite, carried by a set of SEPs that tighten how tokens are issued and checked. The change that matters most for anyone running remote servers is a hardening against a class of OAuth mix-up attacks, in which a client can be tricked into sending a token minted by one authorization server to a different, attacker-influenced endpoint.

The fix follows RFC 9207: clients must now validate the issuer (iss) field on the tokens they receive, confirming that a token actually came from the authorization server the client believes it is talking to. A related enhancement requires OpenID Connect applications to declare their client type during registration, closing ambiguity that attackers could otherwise exploit. If you are building agents that authenticate against MCP servers — or servers that accept those tokens — this is the part of the spec to read line by line. It aligns MCP more closely with mainstream identity practice; readers new to the terrain can start with our primers on OAuth and OAuth grant types.

A framework for extensions

Finally, the revision introduces a formal extensions framework — a structured way to add capabilities to the protocol without forcing every change through the core spec. This is as much about governance as engineering: it gives vendors and the community a sanctioned path to experiment, and it gives the maintainers a mechanism to promote successful extensions into the standard over time. For a protocol that went from a single company’s internal design to a Linux Foundation project in under two years, a disciplined evolution process is arguably overdue.

The migration clock

The changes did not land as a surprise. The project shipped a release candidate roughly ten weeks before the final spec, and that window was explicitly framed as the migration timeline — time for SDK maintainers and server implementers to validate the rewrite against real workloads before it became binding. Cloud platforms moved in step: managed MCP gateways from the major providers announced support for the 2026-07-28 shape, positioning themselves to absorb the statelessness change on customers’ behalf.

For teams running MCP in production, the work is concrete. Audit any dependence on sticky routing or a shared session store, because the protocol no longer requires — or provides — them. Move version and capability negotiation off the handshake and into per-request metadata. Add issuer validation to every token check. And inventory usage of Roots, Sampling, and Logging against their replacements before the 12-month clock runs out.

What it means

MCP’s first design optimized for the world it was born into: a developer wiring a local model to local tools on one machine. The 2026-07-28 revision optimizes for where the ecosystem actually went — fleets of remote servers, multi-tenant gateways, and agents authenticating across organizational boundaries. Dropping sessions is the load-bearing decision. It converts MCP servers from stateful, affinity-bound services into ordinary horizontally scalable web services, which lowers the operational cost and complexity of running them at scale — a real win for anyone deploying multi-agent systems or building tooling like enterprise agent standards.

The winners are platform operators and infrastructure teams, who inherit a protocol that fits standard cloud patterns instead of fighting them, and security teams, who get issuer validation and tighter registration by default rather than as bolt-ons. The cost lands on maintainers of existing servers, who face a genuine migration: statelessness, the vanished handshake, and the auth rewrite each touch code that has been stable for a year. The deprecations of Roots, Sampling, and Logging add to that list, softened only by the 12-month grace period.

The larger signal is institutional. A protocol this central to how AI agents act in the world is now governed by a foundation with a formal proposal process, a release-candidate cadence, and an extensions framework — the trappings of infrastructure meant to last. The thing to watch is adoption speed: whether the major SDKs, the popular server frameworks, and the managed gateways converge on 2026-07-28 quickly, or whether the ecosystem splinters across spec versions during the transition. The cleaner the cutover, the sooner the promised savings — cheaper servers, simpler scaling, safer auth — actually show up in production.