What is the MCP 2026-07-28 spec release candidate?

The Model Context Protocol 2026-07-28 release candidate is the largest MCP revision since the protocol launched in November 2024. Locked on May 21, 2026 and slated for final publication on July 28, 2026, it makes MCP stateless at the protocol layer: the initialize/initialized handshake is removed, the Mcp-Session-Id header is removed, and sticky routing is no longer required. It adds an extensions framework (MCP Apps for server-rendered UI, Tasks for long-running work), hardens authorization against OAuth 2.1 / OpenID Connect, and formally deprecates Roots, Sampling, and Logging.

What breaks with the stateless MCP spec?

Three things break for existing MCP server operators. First, session-scoped state (anything you stored keyed by Mcp-Session-Id) must move to server-managed storage or be re-derived per request. Second, session-affinity load balancers (sticky routing to a specific replica) become unnecessary and, in some setups, actively harmful — the spec now assumes any replica can serve any request. Third, clients that depended on the initialize/initialized handshake for capability negotiation must switch to per-request capability discovery via the new extensions framework.

When does MCP 2026-07-28 become final?

The release candidate was locked on May 21, 2026. Final publication is scheduled for July 28, 2026. The specification includes a formal deprecation policy for the first time, so implementations don't have to rip out the old behavior overnight — but new clients and new servers targeting the July 28 spec must be stateless. Anthropic-maintained MCP servers and the reference SDKs are already tracking the release candidate; expect major SDK versions bumping to the new spec through Q3 2026.

What are MCP Apps and MCP Tasks extensions?

MCP Apps and MCP Tasks are the two flagship extensions in the new extensions framework. MCP Apps let a server return server-rendered UI (rich forms, task-specific interfaces) that the client renders to the user — closing the gap with proprietary agent UIs. MCP Tasks is a redesigned long-running-work primitive: tasks are cacheable, traceable, and routable across replicas because the protocol no longer assumes a specific server holds task state. Both are opt-in — a minimal MCP server does not need to implement either.

Do I need to rewrite my MCP server for 2026-07-28?

If your MCP server stores no session state (pure tool-call handler), you're already compliant — just drop the initialize handshake and stop reading Mcp-Session-Id. If your server stores per-session context (memory, staged edits, conversation history), migrate that to durable storage keyed by user/tenant instead of session, or accept that the client re-provides context on each call. If you use Roots, Sampling, or Logging (deprecated), plan a migration during Q3-Q4 2026 — they'll continue working under the deprecation policy but won't get new features.

Quick Answer

MCP Goes Stateless: What the 2026-07-28 Spec Breaks (and Fixes)

Published: July 11, 2026

The One-Line Summary

MCP 2026-07-28 makes MCP stateless at the protocol layer. That single change removes the initialize handshake, removes Mcp-Session-Id, and drops the sticky-routing requirement. Everything else in the release candidate is downstream of that.

Final publication: July 28, 2026. Release candidate locked: May 21, 2026.

Why This Matters

MCP shipped in November 2024 as a stateful protocol modeled loosely after LSP (Language Server Protocol). That was a reasonable starting point for a local-first tool-connection protocol, but it created friction the moment MCP started running as remote HTTP servers at scale:

Load balancers needed session affinity (sticky routing to the replica that owned a session)
Autoscaling was hard (killing a replica killed its sessions)
Multi-region routing was painful (a request had to land on the replica that initialized)
Caching was disabled (session state made responses non-cacheable)

The 2026 release candidate is a rewrite of the protocol layer to remove all four constraints.

What Changes

1. The initialize/initialized handshake is gone

Old MCP required a two-message handshake at session start to negotiate capabilities. Under 2026-07-28, capabilities are discovered per-request via the extensions framework. Clients that hardcoded the initialize sequence must remove it.

2. `Mcp-Session-Id` header is removed

The session identifier that keyed all state is gone. Anything you stored by session id must move to durable storage keyed differently — typically by user/tenant/task id — or be re-derived from request context.

3. Sticky routing is not required (and often wrong)

Any replica can now serve any request. Load balancers should distribute freely. Setups that pinned a client to a replica for session continuity should remove that pinning.

4. Authorization aligns with OAuth 2.1 / OIDC

Clients must validate the iss (issuer) parameter on authorization responses. The authorization model closes several gaps that let deployed MCP servers rely on static API keys — a systemic risk called out in the 2026 MCP security surveys.

5. Roots, Sampling, and Logging are deprecated

The formal deprecation policy — new in this spec — means these three keep working for now but won’t get new features. Plan a migration for Q3-Q4 2026.

6. Extensions framework (MCP Apps, MCP Tasks)

MCP Apps: server returns server-rendered UI for the client to render
MCP Tasks: cacheable, traceable, routable long-running work

Both are opt-in.

What This Fixes in Practice

Pain point	Before	After 2026-07-28
Autoscaling MCP servers	Killed sessions on replica shutdown	Any replica serves any request
Multi-region routing	Requests pinned to init region	Route by latency/policy freely
Response caching	Session state blocked caching	Requests are cacheable
Load balancer complexity	Required sticky routing	Any LB config works
Auth confusion	Mixed static-key deployments	OAuth 2.1 / OIDC discipline

If you run an MCP server as a hosted product, this is a genuine platform upgrade.

Migration Checklist

For MCP server operators:

Audit session-scoped state — anything keyed by Mcp-Session-Id?
Move state to durable storage — key by user/tenant/task id
Drop initialize handshake handling — accept requests without it
Remove sticky-routing config from your load balancer
Adopt OAuth 2.1 / OIDC — validate iss on authorization responses
Plan Roots/Sampling/Logging migration — deprecated, not deleted (yet)
Decide on Apps/Tasks — opt in only if you need them

For MCP client authors:

Drop initialize/initialized send-and-wait sequence
Discover capabilities per-request via extensions
Stop sending Mcp-Session-Id
Validate authorization iss on OAuth responses
Handle Apps/Tasks extensions if your UX benefits from server-rendered UI or long-running tasks

Deprecation Policy — the Quiet Big Deal

Before this release, MCP had no formal deprecation policy. Anything could break at any spec bump. The 2026-07-28 spec introduces a proper policy: deprecated features keep working for a defined period, get migration notes, and won’t receive new capabilities. That’s what makes Roots/Sampling/Logging deprecation tolerable instead of a fire drill.

For teams building MCP servers as a product, this is arguably as important as the statelessness change — it means you can commit to MCP as a stable target instead of a moving one.

SDK & Ecosystem Status (July 2026)

Anthropic reference SDKs — tracking the release candidate, expect major-version bumps through July-August 2026
Microsoft App Service MCP hosting — updated guidance published for stateless deployments
Cursor / Claude Code / other MCP hosts — release-candidate compatibility rolling in through Q3 2026
Community MCP registry — 3,000+ servers as of March 2026; migration status varies per author

Assume any MCP server / client you didn’t write yourself needs a check for 2026-07-28 compatibility before your July 28 rollout.

The Bottom Line

MCP 2026-07-28 makes MCP finally scalable as a protocol. The initialize handshake, Mcp-Session-Id, and sticky routing were all baked-in assumptions from the 2024 desktop-first design that got in the way once MCP became remote-first. Removing them unlocks autoscaling, multi-region routing, and response caching — with an extensions framework to add back Apps/Tasks only when you need them.

If you operate an MCP server, plan your stateless migration before July 28, 2026.