MCP Goes Stateless July 28: What Breaks, What Gets Cheaper

The MCP 2026-07-28 specification — the next major revision of the Model Context Protocol — is scheduled to finalize on July 28, 2026, and its headline change is architectural: the protocol core is set to become stateless. The release candidate, published May 21, eliminates the initialize handshake and the Mcp-Session-Id header entirely, which would let any request land on any server instance.

That single change reshapes how remote MCP servers are hosted. It also breaks things. Sessions disappear, the Tasks feature is rebuilt around handles instead of session-bound objects, tasks/list is removed outright, three core features are marked deprecated, and six Specification Enhancement Proposals formally position MCP servers as OAuth 2.1 resource servers. If you operate a stateful MCP server today, you have roughly one week to decide what to migrate now and what to defer.

This post is the operator’s cut: what the announced spec breaks, what genuinely gets cheaper, and what the new 12-month deprecation policy lets you safely postpone. It stays deliberately in the news lane — for the wider protocol landscape, see how MCP compares to A2A, ACP, and UCP.

On May 21, 2026, the MCP maintainers published the release candidate for the “2026-07-28” specification on the official MCP blog — the version string is the finalization date. The candidate carries a deliberate 10-week validation window, from May 21 to July 28, so SDK maintainers and client implementers can test against real workloads before the spec locks.

The revision it replaces is the still-in-force 2025-11-25 specification, whose transports are stdio and Streamable HTTP (the older HTTP+SSE transport was deprecated back in March 2025). The release candidate bundles five threads into one revision: the stateless core, MCP Apps as the first official Extension, a redesigned Tasks extension, an auth-hardening package of six SEPs, and — for the first time — a formal deprecation policy.

Mainstream coverage followed this week: TechCrunch ran an explainer on July 20 framing MCP as “one of the basic building blocks of AI interoperability,” noting that as of April 2026 every major AI assistant platform — Claude, ChatGPT, Perplexity, Grok, and Mistral — supports MCP as a client protocol. The scale is why a wire-format change matters this much.

Today’s protocol is stateful by design. A client opens with an initialize request declaring its version and capabilities, the server answers and hands back a session ID, and every subsequent request on that conversation must carry the same Mcp-Session-Id header. That design is fine for one process talking to one local server over stdio. It falls apart behind a load balancer.

The release candidate deletes the problem instead of patching it. The initialize/initialized handshake and the Mcp-Session-Id header are eliminated entirely. Routing information moves into per-request headers — new Mcp-Method and Mcp-Name headers describe what each request is, so any request can land on any server instance with no requirement that repeat requests hit the same machine. David Soria Parra of the MCP core team summarized the candidate the same way: no handshake, no session ID, any request can hit any instance — plus first-class extensions, auth hardening, and a proper deprecation policy.

The breakage follows directly. Any server code that scopes state to a session ID — caches, workflow progress, per-conversation configuration — has no session to scope to. The migration pattern WorkOS describes in its June 18 explainer is to replace session-scoped state with explicit handles passed as tool arguments: the state moves into the request itself, not a server-side lookup keyed by connection. If you built your server from a stateful template — including patterns from our own guides to building an MCP server from scratch — this is the part of the codebase to re-examine first.

The infrastructure payoff is the industry framing around the change, and it is worth stating precisely. A remote MCP server that previously needed sticky sessions, a shared session store, and deep-packet inspection at the gateway could — under the announced design — run behind a plain round-robin load balancer. Scaling horizontally becomes adding instances, not synchronizing session state across them.

Be careful with the numbers here, because there aren’t any. No source — not the MCP blog, not TechCrunch, not WorkOS — publishes a quantified dollar or percentage infrastructure saving from dropping sticky sessions, and any figure you see attached to this change is invented. The win is structural: fewer moving parts, cheaper-to- operate topology, and compatibility with the boring, well-understood load-balancing infrastructure teams already run. TechCrunch adds commercial color: Arcade, the AI-agent-infrastructure startup where Barbettini works, raised $60M in June 2026 by TechCrunch’s own account — session scaling is a problem companies are funded to solve right now.

Our read on the trend: MCP is retracing the web’s own architectural history at speed. HTTP won partly because statelessness made it trivially load-balanceable, and every serious protocol that reaches production scale eventually sheds connection-bound state for request-bound context. That MCP is making this move roughly a year and a half after its late-2024 debut — while the ecosystem is still growing — suggests the maintainers are optimizing for the enterprise deployments ahead of it, not the desktop integrations behind it.

Whichever count you prefer, the population of servers that will need to absorb this change is five figures. If your team runs production tool servers as part of a wider platform — the kind of work covered in a full TypeScript MCP server development guide — the simplification lands directly on your hosting architecture.

The release candidate makes extensions first-class, and two ship with it. MCP Apps, tracked as SEP-1865, would become the spec’s first official Extension: servers can declare an HTML interface that clients render inside a sandboxed iframe. UI actions route back through the same JSON-RPC channel the underlying tool call uses — no separate wire format and no separate authorization path for the rendered UI. Templates are declared up front so clients can prefetch and security-review them before the tool ever executes, with a cacheable ttlMs window controlling how long a fetched tools/list response can be reused.

One disambiguation worth making: this spec-level MCP Apps is not the same thing as the client-side feature Cursor also calls “MCP Apps” for structured tool output. The extension described here is server-declared, sandboxed-iframe UI defined in the protocol itself. Anthropic has been shipping in this direction already — see Anthropic’s existing MCP Apps implementation inside Claude for the implementation-level view; this post is the spec layer.

Tasks graduates from an experimental core-spec feature to a standalone, formally versioned Extension — rebuilt for the stateless world. Under the redesigned model, a server answers a tools/call with a task handle rather than a session-bound task object, and the client drives execution forward via tasks/get, tasks/update, and tasks/cancel. Task creation is server-directed: the server, not the client, decides which calls become an async task handle and which execute inline. And tasks/list is removed outright — listing “all tasks for this session” is undefined once there is no session to scope the list to. If your client UI enumerates running tasks today, that surface needs a new data source.

The second-largest block of the release candidate is authorization. Six Specification Enhancement Proposals formally position MCP servers as OAuth 2.1 resource servers — an explicit, mandatory alignment, which retires any lingering notion that the spec leaves remote-server auth out of scope. Only one of the six carries a number we can verify (SEP-1865 is MCP Apps, not auth); the auth changes are best understood by the RFCs they lean on, which WorkOS’s June 18 explainer lays out in detail. The table below compresses them into one pass.

Quietly, the most consequential governance change in the release candidate is procedural: a formal deprecation policy. Features must move through an Active → Deprecated → Removed lifecycle with a minimum 12-month window between each phase — ending the ad hoc removals of earlier spec revisions. For anyone planning migration work, that policy is the difference between a fire drill and a roadmap item.

Three current core-spec features are marked Deprecated under the new policy, each with a documented replacement. All three remain functional for at least 12 months after deprecation:

Alongside the removals, one capability quietly expands: tool schemas gain full JSON Schema 2020-12 support — composition, conditionals, and $ref references — versus the constrained subset current implementations rely on. Nothing forces you to adopt richer schemas, which puts this on the “free upgrade, your own pace” side of the ledger.

Most coverage frames the stateless move as a pure win. The security-research view is more balanced — and if you have to sign off on this migration, it belongs in the same brief. Akamai’s threat-research team, reported by SecurityWeek on June 26, identified specific new attack surfaces created by the redesign. With no protocol-enforced session boundaries, predictable state or task-handle IDs could enable workflow hijacking or unauthorized cross-tenant and cross-agent data access if implementers don’t randomize identifiers carefully. The redesigned Tasks model adds a denial-of-service vector: a client can send a single request that spawns an expensive long-running operation, then disconnect — leaving the server burning resources on a task nobody is waiting on.

The new headers carry their own risk. If a server implementation maps API keys, tokens, or PII into Mcp-Method or Mcp-Name, that data becomes visible to load balancers, reverse proxies, and logging systems that were never designed to redact MCP-specific header fields. And MCP Apps’ sandboxed-iframe surface introduces a stored cross-site-scripting risk class that security teams need to explicitly threat-model before shipping interactive tool UIs.

The practical response is to treat the migration as a security review trigger, not just a refactor. Randomize every handle and identifier, budget and expire abandoned tasks, audit what your gateway logs, and threat-model any UI surface before enabling it. For a structured pass, work through a full MCP server security audit checklist alongside the spec migration itself.

Nobody else is framing this as a decision window, but that is what the calendar says: from today, July 21, you have one week until the announced finalization. Not everything needs to move at once — the deprecation policy exists precisely so it doesn’t. The matrix below maps each announced change to whether it breaks something, saves something, or can wait.

WorkOS’s pre-cutover checklist compresses the breaking rows into five actions: remove session-scoped state in favor of explicit handles, add OAuth 2.1 if the server is unauthenticated, add the Protected Resource Metadata endpoint or header, update every client integration to send the new required headers, and load-test multi-instance deployments behind a genuine round-robin load balancer before July 28. How that lands on your team depends on your seat:

One strategic note: a spec transition is a natural moment to revisit whether to build or buy your MCP infrastructure — the stateless design lowers the operational bar for self-hosting, while the auth requirements raise the engineering bar for doing it properly. If you want a senior pass on that decision, or on the migration itself, our AI transformation engagements start with exactly this kind of architecture review.