MCP Goes Stateless: What the 2026 Release Candidate Changes

If you run a remote MCP server, the ground just shifted. The 2026-07-28 release candidate makes MCP stateless at the protocol layer.

That sounds dry. It is not. It is the biggest revision since MCP launched in late 2024 — people are calling it "MCP 2.0."

The session handshake is gone. Tasks and Apps became extensions. Three core features got deprecated. Auth got hardened to match real OAuth.

The RC locked on May 21, 2026. The final spec ships July 28, 2026. That is your migration window.

Skip this and your "working" server breaks the day a client upgrades. Read it and you ship the change calmly. Let me walk you through every piece.

What the 2026 release candidate actually is

MCP versions are dated, not numbered. The current stable spec is 2025-11-25. The next one is 2026-07-28, and its release candidate is live now.

A release candidate means the surface is frozen. SDK maintainers get a ten-week validation window to ship support before the spec goes final.

The headline features are a stateless core, the Extensions framework, the Tasks and MCP Apps extensions, authorization hardening, and a formal deprecation policy.

If you only have time for one sentence: MCP moved from a promising integration protocol to infrastructure you can standardize on in production.

New to the protocol entirely? Start with what the Model Context Protocol is, then come back. The rest of this assumes you know the basics.

Why MCP went stateless

Here's the problem the old design created. Every connection started with an initialize/initialized handshake and got an Mcp-Session-Id.

That session ID pinned a client to one specific server instance. The state lived in transport, not in your app.

Now agitate it. To scale a remote MCP server you needed sticky sessions, a shared session store, and a gateway doing deep packet inspection to figure out where each request belonged.

That is a brutal tax on anything cloud-native. Round-robin load balancing? Off the table. Autoscaling? Painful. Every restart dropped live sessions.

The fix: kill the handshake. Protocol version, client info, and capabilities now travel inline in a _meta field on each request — not once at connection setup.

A server that needed sticky routing can now sit behind a plain round-robin load balancer. No shared store. No packet inspection. Any instance can serve any request.

When you do need state — a shopping basket, say — the server mints an explicit handle (a basket ID) and the model passes it back as a tool argument. State becomes visible to the agent instead of hidden in transport.

The new request model: Mcp-Method and inline metadata

With sessions gone, requests have to carry their own context. Two new headers do the heavy lifting on Streamable HTTP POSTs.

• Mcp-Method — the JSON-RPC method being called (like tools/call)
• Mcp-Name — the specific tool or resource name

Why headers? So a load balancer, gateway, or rate-limiter can route and throttle on the operation without opening the request body. That is a big win for infra teams.

Server-to-client round trips changed too. Long-lived SSE streams are no longer the only path.

When a server needs input mid-call, it returns an InputRequiredResult with a requestState payload. The client gathers the answer and reissues the original call with inputResponses.

Because everything needed to resume is in the payload, any server instance can process the retry. That is the whole point of stateless — self-contained requests.

Tool schemas also got an upgrade. They now support full JSON Schema 2020-12 — oneOf, anyOf, allOf, conditionals, and $ref. Output schemas are unrestricted; input schemas keep an object root.

Tasks, MCP Apps, and the Extensions framework

The RC introduces a real Extensions framework so features can evolve without bloating the core. Extensions get reverse-DNS identifiers, capability negotiation, and independent versioning.

Two big extensions ship alongside it.

The Tasks extension

Long-running work finally has a first-class home. A server answers a tools/call with a task handle instead of blocking.

The client then drives it with tasks/get, tasks/update, and tasks/cancel. Task creation is server-directed — the server decides when a call should run async.

MCP Apps

MCP Apps let a server ship interactive HTML UIs rendered in a sandboxed iframe inside the client. Tools declare UI templates so the client can prefetch and security-review them.

UI actions flow through the same JSON-RPC path as direct tool calls — no separate channel to secure. Want the deep version? I wrote a full guide to building MCP Apps.

Caching with ttlMs and built-in tracing

Without a persistent session, clients need a way to know how long data stays fresh. The RC borrows from HTTP Cache-Control.

List and resource-read results now carry ttlMs and cacheScope fields. A client knows exactly how long a tools/list response is fresh, and whether it is safe to share across users.

That kills a real annoyance: you no longer need a long-lived SSE stream just to learn that a tool list changed.

Observability got formalized too. W3C Trace Context propagation is now documented with fixed keys: traceparent, tracestate, and baggage.

So distributed traces correlate across SDKs and show up as unified span trees in your OpenTelemetry backend. For anyone running MCP in production, that is a quiet but huge upgrade.

Authorization hardening

Six SEPs (spec enhancement proposals) tighten how MCP does OAuth 2.0 and OpenID Connect to match real-world deployments.

The changes that will touch your code:

• Clients must validate the iss parameter on authorization responses, per RFC 9207
• Clients declare application_type during Dynamic Client Registration, so a CLI or desktop client is not misclassified as a web app
• Credentials bind to a specific authorization-server issuer
• Scope accumulation during step-up and .well-known discovery are clarified

None of this is novel auth theory. It is MCP catching up to how OAuth is actually deployed — which is exactly what an enterprise security team wants to see before they approve it.

What's being deprecated

The RC ships a formal deprecation policy for the first time. Features move through Active → Deprecated → Removed, with a minimum twelve-month window between deprecation and removal.

Three features enter deprecation now:

The twelve-month window means nothing breaks on July 28. But if your server leans on Sampling, plan the move to a direct provider API call now.

How to migrate before July 28

You do not need to rewrite everything. Most servers need a focused checklist. Here's the order I'd work in.

1. Upgrade the SDK — wait for your language's Tier-1 SDK to ship RC support during the ten-week window, then bump it
2. Drop session assumptions — stop relying on Mcp-Session-Id; move any per-session state into explicit handles passed as tool arguments
3. Emit the new headers — make sure Mcp-Method and Mcp-Name are set on Streamable HTTP requests
4. Migrate Tasks — if you used experimental async Tasks, switch to the tasks/get / tasks/update / tasks/cancel lifecycle
5. Add ttlMs to your list and resource responses so clients cache correctly
6. Fix auth — validate iss, declare application_type, bind credentials to the issuer
7. Plan deprecations — schedule the move off Roots, Sampling, and Logging within the 12-month window

Then test it against a real client. A spec change is exactly the kind of thing that looks fine in unit tests and falls over in a live agent loop.

For the broader picture beyond the RC, my 2026 MCP roadmap breakdown covers what lands after July.

How MCP Playground helps you test the new spec

Reading the spec is half the work. The other half is confirming your server still behaves once a real model drives it — the part curl and Postman can't check. MCP Playground runs in the browser: paste a server URL, pick from 15+ models, and watch every tool call as structured JSON.

No local setup, no API keys, no client to rebuild. When you refactor for the new spec, that model-in-the-loop test is what surfaces the regressions a migration hides — a tool the model can no longer find, an argument shape that drifted, an auth flow that broke.

Test the behavior, not just the wire format. See it break here before your users do.

Frequently asked questions

Further Reading

• The 2026 MCP Roadmap: What's Changing for Developers
• Remote MCP Servers Explained
• Build MCP Apps: A Developer's Guide
• MCP Server OAuth Authentication Guide
• Deploy an MCP Server with Docker in Production
• What Is the Model Context Protocol (MCP)?
• Official: The 2026-07-28 Specification Release Candidate
• Official: MCP Specification Changelog