← All articles
Enterprise Architecture

MCP's Biggest Rewrite Yet: What the Stateless Specification Actually Changes

Vishal Sharma·July 19, 2026·8 min read

The 2026-07-28 Model Context Protocol revision removes the session handshake that made MCP awkward to scale — and in doing so moves a set of security boundaries from the protocol onto the people implementing it. A look at what changes, and what that trade costs.

A snapshot as at 19 July 2026. This is a fast-moving specification; dates below are given explicitly so the post ages honestly.

The Model Context Protocol is about to receive its largest revision since launch. The release candidate was locked on 21 May 2026 and entered a ten-week validation window, with the final specification dated 28 July 2026.

One point of accuracy first, because a surprising number of secondary write-ups have it wrong: as at the date of this post, that specification has not yet shipped. Several blogs already describe the 2026-07-28 revision in the past tense. It is a release candidate under validation. If you are making architectural commitments on the basis of a summary you read somewhere, check whether the author was describing something that had actually happened.

What is actually changing

The session handshake goes away

The headline change is the removal of the initialize handshake and the Mcp-Session-Id header. Every request becomes self-contained, routed on an Mcp-Method header, and tools/list becomes cacheable per server via a ttlMs value.

This is a direct response to a long-standing structural complaint. Stateful MCP fought load balancers. If a session identifier binds a client to a particular server process, horizontal scaling becomes an exercise in sticky routing and session affinity — precisely the pattern that a decade of stateless HTTP service design has taught teams to avoid. Making each request self-describing means an MCP server can finally sit behind an ordinary load balancer and scale like any other web tier.

An extensions framework

Rather than growing the core protocol indefinitely, the revision introduces extensions identified by reverse-DNS names with delegated maintainers. MCP Apps — server-rendered UI in sandboxed iframes, where tools declare UI templates that can be prefetched and security-reviewed — shipped as the first official extension back in January 2026 and becomes a first-class citizen here.

Tasks graduates from experimental

Long-running work gets a stateless, handle-based lifecycle initiated from tools/call. Given how much agent work is genuinely asynchronous, this matters more than its billing suggests.

Authorization gets serious

Six authorization proposals align the protocol with OAuth 2.0 and OIDC, including issuer validation per RFC 9207. Alongside this, a formal deprecation policy — Active, then Deprecated, then Removed, with minimum twelve-month windows — arrives. For anyone who has had a dependency vanish under them, a published deprecation policy is quietly one of the most important items on this list.

The trade nobody should skip past

Stateless is the right architectural call. It is not a free one.

On 26 June 2026, SecurityWeek published an analysis built on Akamai threat research setting out what the model costs. The concerns are specific: predictable state-tracking identifiers that could enable workflow hijacking or cross-tenant access; new MCP-specific HTTP headers that can leak API keys and tokens into proxies and logs; protocol-confusion and desync attacks arising from the new header standards; cross-site scripting risk as MCP Apps become a first-class extension; and denial of service through long-running Tasks — spawn expensive asynchronous work, then disconnect.

Maxim Zavodchik, senior director of threat research at Akamai, put the structural point plainly: since the protocol is transitioning to a stateless model, critical security boundaries now depend entirely on how developers implement them.

That sentence is the whole story. A stateful protocol enforces some things centrally whether or not you understood them. A stateless one hands you the responsibility. The scaling benefit is real, and it is paid for in implementation discipline.

The tooling is already moving

Beta SDKs for the release candidate landed on 29 June 2026, and the version numbers are worth knowing if you are planning a migration:

  • Python — mcp==2.0.0b1, a full API rework in which FastMCP is renamed MCPServer. The decorator API is retained and a migration guide is published.
  • TypeScript — the monolithic @modelcontextprotocol/sdk is retired in favour of separate server and client packages. ESM-only, Node 20+, with tool schemas moving to Standard Schema.
  • Go — v1.7.0-pre.1, minimal breaking changes, same module path, and stateless HTTP as an explicit opt-in.
  • C# — 2.0.0-preview.1, stable v1.x APIs retained, with breaks limited to deprecated capabilities.

Backward compatibility is handled sensibly: clients speaking the new revision fall back to the initialize handshake when they encounter servers on 2025-11-25 or earlier. You are not facing a flag-day migration.

The enterprise piece: managed authorization

Separately, the Enterprise-Managed Authorization extension was declared stable on 18 June 2026. EMA centralises MCP access control through an organisation's identity provider instead of scattering per-server OAuth consent prompts across an estate, using an Identity Assertion JWT Authorization Grant exchanged for access tokens.

The adopter list is substantial on both sides — Okta, Microsoft and VS Code on the client and identity side; Asana, Atlassian, Canva, Figma, Linear and Supabase among servers.

Its stated limitations deserve equal attention. EMA is additive, so organisations without a supporting identity provider still need fallback authentication. More importantly, it gates connection, not runtime action. The extension's own documentation is explicit that it does not replace separate policy enforcement for sensitive runtime decisions. Establishing that an agent may connect to a server is a different question from establishing that this particular call, with these arguments, at this moment, should proceed. Do not let the first be mistaken for the second.

How to read this if you are running an estate

MCP is no longer an interesting protocol from a single vendor. Anthropic donated it to the Agentic AI Foundation — a directed fund under the Linux Foundation — in December 2025, alongside Block and OpenAI, with backing from Google, Microsoft, AWS, Cloudflare and Bloomberg. The official registry recorded 9,652 distinct servers as at 24 May 2026.

That maturity cuts both ways. Governance and a deprecation policy make it safe to build on. Scale and ubiquity make it worth attacking. The practical posture for the next quarter is unglamorous: track the final specification when it lands on 28 July, plan SDK migration deliberately rather than reactively, and treat the stateless transition as what it is — an invitation to re-examine every security boundary you assumed the protocol was holding for you.

A stateful protocol enforces some boundaries whether or not you understood them. A stateless one hands you the responsibility, and trusts you to have read the manual.

Sources

MCPAgentic AIEnterprise ArchitectureIntegrationSecurity

Want to see it in action?

Try the live Document Intelligence demo.

← More articles Try the demo
MCP's Biggest Rewrite Yet: What the Stateless Specification Actually Changes | Vishal Sharma Cloud