MCP Gets Its Stateless Core: The Protocol Just Stopped Hand-Waving

On May 21, the MCP maintainers (David Soria Parra and Den Delimarsky) published the 2026-07-28 release candidate of the protocol. The blog post calls it “the largest revision since launch.” That is accurate, and it understates what changed. The Model Context Protocol just stopped being a research artifact you tolerated in production and started being a vendor-evaluable surface you can write into a contract.

The headline numbers do most of the talking. Six SEPs (Specification Enhancement Proposals) address statelessness. Six more harden authorization. The maintainers locked in a 12-month minimum deprecation window. Three primitives that were inherited from the original 2024 design (Roots, Sampling, Logging) are now formally deprecated. Two extensions (MCP Apps and Tasks) ship as the first official examples of the new reverse-DNS extension model. There is a 10-week validation window before the spec is final on July 28.

The teams that have spent the past nine months arguing that MCP “is not ready for production” now have a concrete date when that claim stops being true.

The Stateless Inflection

The most important change is structural. Until this RC, an MCP server held session state. Every request from a client had to land on the same instance, because that instance remembered who the client was and what tools were already negotiated. That single fact dictated every deployment pattern downstream of it. Sticky sessions in your load balancer. Session affinity in your service mesh. Custom logic in your CDN to honor session cookies. A team that wanted to run MCP behind plain round-robin DNS in front of three Lambda containers could not, because the second request would land on a different container and the negotiation would be gone.

The stateless core fixes that at the protocol level. State now lives in the application, where it always belonged. An MCP server in the 2026-07-28 spec is a stateless HTTP service. You can put it behind any load balancer that distributes requests randomly. You can cache responses at the edge. You can scale horizontally without coordination. You can deploy it the way you deploy every other internal HTTP service, with no protocol-aware infrastructure in the path.

This is the change that turns MCP from a thing your platform team has to plan around into a thing your platform team can ignore. For an enterprise running a service mesh, an API gateway, and a CDN, “looks like HTTP” is the entire ballgame. The protocol just earned the right to be deployed on the infrastructure you already operate.

Six SEPs to ship this. Worth understanding why it took six. Stateless transport is not just “remove the session ID.” It required rethinking how tool capabilities are negotiated, how subscriptions to long-running resources work without an open connection, how authorization tokens are scoped per request instead of per session, and how the client knows what the server is capable of without having to ask every time. Each of those is a separate proposal with separate review. Six SEPs is the size of the cleanup.

Authorization Stops Being a Sketch

The second cluster (six more SEPs) closes the authorization story. Until this RC, MCP authorization was a documented intent. The spec said “use OAuth 2.1.” The implementations did roughly that, with enough variation to make a security review a research project.

The RC aligns the protocol with OAuth and OIDC at the level a security team actually cares about. Token issuer (iss) validation is now in the spec, not in the guidance section. Scope semantics are defined. Token audience binding is defined. The maintainers explicitly removed ambiguity around which token can be used by which client against which server. The intent is that an MCP server’s authorization story should be auditable against the same playbook your existing SaaS vendors use.

This is the change that lets a CISO sign off without writing a custom risk acceptance. When the OAuth flow against your MCP server looks indistinguishable from the OAuth flow against your CRM, the same controls apply: the same identity provider, the same scope inventory, the same token lifetime policy, the same revocation path. The protocol stopped requiring you to invent new controls.

The Deprecation Policy Is the Procurement Win

Buried under the headline changes is the item that matters most to procurement: a formal deprecation policy with a 12-month minimum window between deprecation and removal. Roots, Sampling, and Logging are the first primitives to enter that window. They are being removed because they were under-used, awkwardly scoped, or duplicated by better mechanisms (Tasks subsumes long-running work; Apps subsumes UI surface concerns). The point is not which primitives are leaving. The point is the calendar.

Twelve months is enough time for a vendor to update an SDK, ship a new release, and give customers a migration path. It is also enough time for a procurement team to write the contract clause that says: “If a primitive your server depends on is deprecated, you have nine months from the announcement to ship a compatible upgrade, and we are entitled to remediation if you do not.” Until last week, no such clause was writable, because there was no defined deprecation cadence to point at. Now there is.

The 12-month window is also what makes it safe to deploy MCP servers in environments that have 24-month software refresh cycles. Two refresh cycles cover one deprecation cycle with margin. The protocol just became deployable in regulated industries that had been waiting for exactly this commitment.

Extensions Get a Namespace

MCP Apps and Tasks ship as the first two extensions under a reverse-DNS naming scheme. Apps brings UI surface concerns into the protocol (the client can render server-supplied UI in a controlled way). Tasks brings long-running work into the protocol (the server can hand back a task handle, the client can poll or subscribe, the work survives a disconnect). Both have been validated in real implementations over the past nine months. Both now have a stable home in the spec.

The reverse-DNS scheme matters more than the two specific extensions. It means a vendor can ship com.acme.mcp.proprietary-thing as a recognized extension, and a client can advertise that it supports org.modelcontextprotocol.apps without confusion. The namespace is the mechanism that lets the protocol grow without forking. Until now, every vendor-specific feature was either a private extension nobody else could discover or a proposal to change the core spec. The reverse-DNS path is the middle road, and it is the one every other healthy protocol ecosystem has converged on.

What to Do in the Next 10 Weeks

The 10-week validation window before July 28 is when you get to influence the final shape of the spec. Three actions are worth scheduling.

First, audit your current MCP deployments for stateful assumptions. If you have sticky-session config in a load balancer because of MCP, mark it for removal. If you have a service-mesh policy that pins clients to instances, the same. The migration is not automatic, but the cleanup is straightforward and the operational simplification is permanent.

Second, run a token-flow review against your MCP servers under the new authorization rules. The iss validation, scope semantics, and audience binding are the three places where existing implementations are most likely to drift from the spec. A 60-minute review with your identity team will surface what needs to change.

Third, write the deprecation clause into your next MCP vendor contract. The 12-month window is the artifact that makes the clause defensible. If you are signing a contract this quarter without that clause, you are signing one that expires the day a primitive your vendor uses gets removed.

The MCP RC is not a feature release. It is the moment the protocol stopped being a thing you adopted on faith and started being a thing you can evaluate. The vendors who were waiting for that moment to take it seriously will be the ones moving fast in Q3. The buyers who keep treating MCP as research will be the ones writing remediation checks in 2027.

This analysis synthesizes The 2026-07-28 MCP Specification Release Candidate (Model Context Protocol, May 2026).

Victorino Group helps procurement and platform teams turn protocol changes into vendor evaluation criteria before they harden into defaults. Let’s talk.