MCP Goes Stateless on Monday. The Session Handshake Is Gone, and So Is the Reason Servers Were Hard to Run.

The release candidate for the next Model Context Protocol specification landed last week and the final spec ships on Tuesday, July 28, 2026. David Soria Parra and Den Delimarsky signed the announcement. It is the largest revision since MCP launched in November 2024, and every line in the change log points in the same direction. The protocol just stopped pretending it lives inside one process.

The one-sentence version: MCP is now stateless. No initialize handshake, no Mcp-Session-Id header, any request can hit any server instance. The knock-on effects run through Apps, Tasks, authorization, and a formal deprecation policy, but the stateless core is the change that reorganizes everything else.

What Ships Tuesday

Why Stateless Is the Whole Story

Every headline change here is downstream of one architectural bet: a request is self-contained, a response is self-contained, and server instances are interchangeable. That reads like a sentence from a compliance document, and in a sense it is. It is the sentence that lets an MCP server run behind a normal load balancer, autoscale on ordinary horizontal replicas, and deploy on serverless without a shared session store bolted to the side.

The previous protocol required an initialize handshake before any real work. The client announced itself, the server issued an Mcp-Session-Id, and every subsequent request carried that id back. If the load balancer routed you to a different replica, the id was garbage. The workaround was sticky routing, which is a soft way of saying autoscaling did not really work. If a replica died mid-conversation, the client had to re-handshake and re-hydrate state, which is a soft way of saying reliability did not really work either.

Both of those problems came from one place, and the spec removed the place. Client information now travels via a _meta field on every request. No id, no sticky header, no shared session store on the server side. The scaling story just got dramatically simpler, and it got that way through subtraction rather than addition.

Apps and Tasks Get Their Own Track

The Extensions framework is the second load-bearing change. Extensions get reverse-DNS identifiers, capability negotiation, independent version cadence, and their own Standards Track repositories. MCP Apps and Tasks are the first two official ones, and both are shipping alongside the core rather than inside it.

MCP Apps let a server ship interactive HTML that the host renders in a sandboxed iframe, with templates prefetched and security-reviewed before execution. That is what turns a tool call from a JSON round trip into a small application surface with pointer events, progress bars, and interactive forms. The design constraint is intentional: the host owns the sandbox, the server owns the pixels, and the model still calls tools underneath. The product target is any MCP client that already has a chat surface (Claude, Claude Code, Cowork, VS Code, plus every third-party host) and wants tools to render richer output without giving each vendor a bespoke SDK.

Tasks graduates the other direction, out of the experimental core and into an extension. The redesign is stateless in the same shape as the rest of the protocol. Servers return a task handle from tools/call. Clients poll tasks/get and push input via tasks/update. The old tasks/list, which required the server to remember every task in flight, is removed outright. Handles are visible to the model, which also means the model reasons about them, which is a small but real correctness win for agent loops that used to lose track of long-running work when the transport lost track first.

Authorization Grows Up

Six security proposals harden the authorization spec against real-world OAuth 2.0 and OpenID Connect deployments. The list reads like a compliance change log. Clients now validate the iss parameter on authorization responses per RFC 9207. Registrations declare an application_type. Refresh token guidance stops being implementation-defined. The Enterprise-Managed Authorization work reached stable on July 6, 2026, with Okta named as the reference identity provider and Anthropic's Claude, Claude Code, Cowork, plus VS Code as reference clients.

What that means for anyone shipping an MCP server into a real company: the identity story is now the story an enterprise architecture review already has language for. You do not need to invent an auth story on top of an auth story. The path from the corporate identity provider to the MCP server to the tool call is one continuous OAuth 2.0 flow, and the pieces of that flow that used to be footnotes in a draft are now normative clauses. That is the difference between a protocol you can pitch to a CIO and a protocol you can only pitch to a friend.

What Breaks

Servers that expect initialize as the first message will fail. The Mcp-Session-Id header is gone, and any host code parsing it is dead. Roots, Sampling, and Logging are deprecated in the core (kept working for at least 12 months, then removed). Tasks that were session-bound need to be rebuilt around explicit handles. tasks/list is gone entirely, so any UI that enumerated in-flight jobs has to move that state into the client.

The recommended migration pattern is more disciplined than the old one and better for the model. Return an explicit handle from a tool call (a basket_id, a job_id, a search_cursor), then take that handle as an argument on the follow-up call. The state is now visible to the model instead of hidden in transport metadata, and the server no longer needs to remember which client had which id. This is the same shape of change REST APIs went through in the mid-2010s when session cookies died on the mobile edge and everyone moved to tokens.

What This Does to the Edge

The stateless move is the change that finally makes MCP a first-class citizen at the edge. We wrote up Cloudflare and AWS embedding x402 into the edge two weeks ago. Both providers pushed paid MCP tool calls into their respective request fabrics on the assumption that MCP would eventually stop needing a sticky server. As of Tuesday, it does not. Any request hits any Worker isolate, any Fargate task, any Lambda cold start. The pricing story for hosted MCP shifts from “pay for the persistent connection” to “pay for the call,” which is exactly the mental model x402 already assumed.

Our own MCP stack sits inside this shift. The @tensorfeed/mcp-server npm package wraps the TensorFeed REST API as MCP tools, and the paid tools settle in USDC on Base through x402. The old protocol required us to hold the session while the agent decided whether to pay. The new protocol lets every request stand on its own, which is the shape a payment-required rail has always wanted. We are shipping a stateless upgrade of the server alongside the spec, and the migration will not touch the tool catalog. The auth layer will pick up the OAuth 2.0 hardening for enterprise agents that need SSO, and the free tools will keep working with no auth at all.

For anyone else running an MCP server: the 12-month deprecation window means you do not need to rewrite this week. You do need to plan the rewrite this quarter. A server that held state in the transport is going to keep holding it for a while, and then it is going to break. Better to write the new shape now while the old shape still works than to run the fire drill in July 2027.

Our Take

MCP as an open protocol has been running the same trajectory as every other successful agent-era standard we cover. First a narrow reference implementation shipped by the vendor with the loudest voice, then a burst of real production adoption that exposes the seams, then a formalization pass that quietly rebuilds the load-bearing pieces to match how the protocol is actually used. HTTP went through this. OAuth went through this. MCP is going through it now, and the 2026-07-28 revision is the pass where the seams get rebuilt.

The stateless bet is the right one. It closes the operational gap between MCP and every other successful transport of the last decade, and it lands at the exact moment the agent-payments rail needed a protocol that could survive being priced per call. The extensions framework is the right shape too. It gives Apps and Tasks their own version cadence without dragging the core along, and it gives the ecosystem a place to iterate without every experiment turning into a breaking spec change.

The thing to watch is the extension market itself. First-class extensions are only first-class if hosts actually ship them, and the interesting split will be whether Anthropic, OpenAI, Google, and the third-party host ecosystem all implement MCP Apps and Tasks on the same calendar. If they do not, extensions become the new place fragmentation hides. If they do, MCP's 97 million installs become the substrate for a much richer surface than a chat window with tool calls.

Three signposts through the rest of the year. Whether Anthropic ships MCP Apps in Claude Desktop and Claude Code by Q4. Whether OpenAI adopts the 2026-07-28 auth hardening for its own MCP surface in ChatGPT. And whether the first paid, x402-metered MCP Apps land on any of the hosted registries (ours, Cloudflare's, Apify's, the official one) before the end of Q3. The protocol just got the scaffolding it needed. The next six months are about whether the ecosystem builds on it.