MCP 2026-07-28: The Stateless Release Candidate, Explained

What’s new in one line

MCP 2026-07-28 removes the initialize handshake and the session id, turns extensions into a first-class framework, hardens OAuth against issuer mix-up, and ships a written deprecation policy — without removing any existing feature inside the 12-month window.

That sentence is the post. Every section below unpacks one phrase of it against the actual SEP text published by the MCP maintainers on the release candidate announcement.

Why this release exists

Two failure modes drove the redesign. First, the stateful handshake was incompatible with the way production HTTP is actually deployed: load balancers had to parse JSON-RPC bodies to route, sticky sessions blocked autoscaling, and a single server restart blew up every in-flight session. SEP-1442 — opened September 8, 2025 by Jonathan Hefner, Mark Roth, Shaun Smith, Harvey Tuch, and Kurtis Van Gent — framed this directly: “a simple stateless load balancer cannot be used, as it would route a client’s requests to different backend servers” without proper session state.

Second, the spec had collected a year of operational debt. There was no standard caching metadata, no standard tracing format, no formal deprecation policy, and extensions like Tasks lived “experimentally in the core spec” with no governance about how they would graduate or evolve. In April 2026, MCP co-creator David Soria Parra told ShiftMag that “2026 will be about making sure it’s ready to help people productionize agentic systems”. The release candidate is the technical answer to that statement.

The 2026 roadmap, published March 9, 2026, committed to four work areas: transport scalability, agent communication, governance maturation, and enterprise readiness. The release candidate maps directly onto those four: stateless core for the first, Tasks extension graduation for the second, deprecation policy and the Extensions Track for the third, MCP Apps and operability headers for the fourth.

Mental model: five pillars

The 21-plus SEPs in this release cluster into five load-bearing changes. Hold these in your head and the spec text becomes much shorter than it looks.

┌─────────────────────────────────────────────────────────┐
│              MCP 2026-07-28 — five pillars              │
├─────────────────────────────────────────────────────────┤
│  1. Stateless core      no handshake, no session id     │
│  2. Operability layer   routing headers, ttl, tracing   │
│  3. Extensions          MCP Apps + Tasks + framework    │
│  4. Auth hardening      6 SEPs aligning with OAuth/OIDC │
│  5. Deprecation policy  12-month window, written rules  │
└─────────────────────────────────────────────────────────┘

• Stateless core — SEP-2575 removes the initialize handshake, SEP-2567 removes the Mcp-Session-Id header. Protocol version, client info, and capabilities now travel on _meta in every request.
• Operability layer — required Mcp-Method and Mcp-Name headers (SEP-2243), HTTP-style caching metadata (SEP-2549), and W3C Trace Context propagation (SEP-414).
• Extensions framework — reverse-DNS-identified extensions negotiated via capability maps; MCP Apps (SEP-1865) and Tasks ship as the first two officials.
• Authorization hardening — six SEPs aligning MCP with mainstream OAuth 2.1 and OpenID Connect deployments, including iss-parameter validation per RFC 9207.
• Deprecation policy — SEP-2596 guarantees a minimum 12 months between deprecation and removal; SEP-2484 ties Standards Track SEPs to conformance suite scenarios before Final status.

Stateless core (SEP-2575 + SEP-2567)

Before this release, every MCP session began with initialize from client to server, initialized back, and an Mcp-Session-Id header that all subsequent requests echoed. The server held that session in memory. If the session landed on a different replica later, things broke.

In 2026-07-28, that whole dance is gone. Every request carries its own protocol version, client identity, and negotiated capabilities inside the _meta object on the JSON-RPC envelope. Clients that need server capability discovery call a new server/discover method — stateless, cacheable, no shared state required. The release candidate puts the operational consequence plainly:

A remote MCP server that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer, route traffic on an Mcp-Method header, and let clients cache tools/list responses for as long as the server’s ttlMs permits.

Server-initiated calls (the messages that used to require a long-lived SSE stream) move to a new Multi Round-Trip Requests pattern (SEP-2322). A server answers a tool call with an InputRequiredResult containing an inputRequests array and an opaque requestState. The client gathers the inputs, re-issues the call with inputResponses and echoes the same requestState back. The server reconstructs whatever it needs from requestState on its side — the protocol never holds a connection.

Opinion: this is the right call, even though it breaks SSE-based starter templates. The transport-future post from December 2025 named the principle: “agentic applications are stateful, but the protocol itself doesn’t need to be.” HTTP has worked this way for two decades. Cookies, tokens, opaque handles — application-layer state on a stateless wire is the pattern that scales.

Operability: headers, caching, tracing

Three SEPs in this cluster make MCP traffic indistinguishable, from a routing-and-observability standpoint, from normal HTTP API traffic. None of them are glamorous; all of them remove a class of production pain.

• Required headers (SEP-2243): every Streamable HTTP request must include Mcp-Method (e.g. tools/call) and Mcp-Name (the tool or resource name). Load balancers can route on these without parsing JSON-RPC bodies.
• Caching metadata (SEP-2549): tools/list, resources/list, and resources/read results carry ttlMs and cacheScope fields modeled on HTTP Cache-Control. Clients now have a defined way to cache; servers have a defined way to invalidate.
• Distributed tracing (SEP-414): W3C Trace Context propagation is documented with fixed traceparent, tracestate, and baggage keys. OpenTelemetry collectors see MCP traffic end-to-end with no glue code.

POST /mcp HTTP/1.1
Host: server.example.com
Authorization: Bearer <token>
Mcp-Method: tools/call
Mcp-Name: search_issues
Mcp-Protocol-Version: 2026-07-28
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

{"jsonrpc":"2.0","id":"req-1","method":"tools/call",
 "params":{"name":"search_issues","arguments":{"query":"crash"},
 "_meta":{"clientInfo":{"name":"claude","version":"3.5"}}}}

Opinion: the routing headers are the most underrated change in this release. Every gateway vendor at the AAIF MCP Dev Summit in April 2026 — Kong, Docker, Solo.io, Uber’s internal platform — was reverse-engineering tool names out of request bodies. That goes away on July 28.

Extensions, MCP Apps, Tasks

MCP gains a real extension system in this release. Extensions are identified by reverse-DNS IDs, live in their own ext-* repositories with their own maintainers, and are negotiated through an extensions map on the client and server capability advertisements. They version independently of the core spec. The SEP process now has an explicit Extensions Track.

Two extensions ship official on day one.

MCP Apps (SEP-1865)

Servers can declare an HTML interface that clients render inside a sandboxed iframe. Tools declare which UI templates they use ahead of time so the client can prefetch them and security-review them. The rendered UI talks back to the server via the same JSON-RPC protocol the tool does — no new wire format. This is the spec layer that competes directly with OpenAI’s Apps SDK.

Tasks (migrated from experimental core)

Tasks moved out of the core spec and into an extension, and the design was reshaped around the new stateless model. A server now answers tools/call with a task handle. The client drives the task via tasks/get, tasks/update, and tasks/cancel. Task creation is server-directed (the server decides what to make a task and what to answer inline). The release candidate notes tasks/list was removed because listing tasks across clients without sessions has no well-defined scope.

Opinion: the extensions framework is the second most-important change in this release, after the stateless core. It is the governance answer to the long tail of feature requests — rich UIs, durable jobs, agent handoff — that do not belong in a wire specification. The lesson from the Language Server Protocol that inspired MCP is that the spec stays useful only if its evolution surface is bounded.

Authorization hardening

Six SEPs land in this release, each fixing a sharp edge in MCP’s OAuth 2.1 deployment story.

• SEP-2468: clients must validate the iss parameter on every authorization response per RFC 9207 to mitigate mix-up attacks where one authorization server’s response is replayed against another.
• SEP-837: MCP clients now declare an OpenID Connect application_type during Dynamic Client Registration. Most OIDC providers refuse DCR without it; the spec used to leave the field empty.
• SEP-2352: registered client credentials are bound to the authorization server’s issuer. If the server changes issuers, the client re-registers.
• SEP-2207: refresh-token requests are clarified for OpenID-Connect-style providers (the older spec was ambiguous about scope semantics on refresh).
• SEP-2350: scope accumulation during step-up authentication is now defined — previously every implementation rolled its own.
• SEP-2351: well-known discovery uses a stable suffix so resource and authorization metadata documents always live at predictable paths.

Opinion: SEP-2468 is the one that should ship in every client by August. Mix-up attacks against OAuth-protected APIs have been weaponized in the wild since at least 2016. Treating MCP servers as protected resources means MCP clients inherit the same threat model — and the exploitation cost is low because the surface is small.

JSON Schema 2020-12 support

SEP-2106 upgrades tool inputSchema and outputSchema to JSON Schema draft 2020-12. The headline unlocks:

• Input schemas keep a type: "object" root, but composition (oneOf, anyOf, allOf), conditionals (if/then/else), and $ref/$defs are now allowed. Tools that genuinely have polymorphic parameters can express it.
• Output schemas are unrestricted — no more forcing every tool response into an object wrapper.
• structuredContent can be any JSON value, not just objects.
• Auto-dereferencing external $ref URIs is prohibited, and validators must bound schema depth and time. These are denial-of-service guards.

One smaller error-code change worth knowing: SEP-2164 replaces the MCP-custom -32002 “missing resource” code with JSON-RPC’s standard -32602 Invalid Params. Servers that hard-coded -32002 will continue to be interpreted correctly by clients during the deprecation window, but generic JSON-RPC tooling now works without an MCP-specific code table.

Deprecations, not removals

The release candidate is firm on this point: no feature is removed in 2026-07-28. Three are deprecated with replacements documented. Per the new lifecycle policy (SEP-2577 + SEP-2596), Active → Deprecated → Removed transitions take a minimum of 12 months.

Methods, types, and capability flags keep functioning in this release and in every spec version published inside the 12-month window. SDK code that calls roots/list on July 29 will still get a valid response.

What we got wrong reading the draft

Three things I assumed before reading the SEPs carefully — and was wrong about.

1. I thought stateless meant Streamable HTTP was dead. It is not. Streamable HTTP is still the transport. What changed is that the request lifecycle no longer requires the connection to be the unit of session. A client can open and close connections per request, or multiplex many requests over one connection — either works because no session state is bound to either. Streamable HTTP without the session id is still streamable HTTP.

2. I thought MCP Apps replaced the tool/resource pair. They do not. MCP Apps is an extension that augments a tool with a rendered surface, the way a Stripe webhook UI augments a Stripe API. The tools still exist, still take JSON arguments, still return JSON results. The app is the optional interactive shell on top.

3. I assumed the deprecation policy would slow velocity. The opposite. The lifecycle policy makes it safer to deprecate, because the 12-month guarantee removes the political cost of saying “we no longer recommend X.” The transport-working-group history showed that removing things informally generated months of community thrash. Writing it down turns deprecation into a routine operation.

Migration mistakes to avoid

Community signal

The maintainer summary, posted by David Soria Parra on the day the release candidate was announced:

That is the maintainer’s framing. The contrarian view came earlier in the cycle. At the AAIF MCP Dev Summit in April 2026, Uber’s platform team — running tens of thousands of agent executions a week through their internal MCP gateway — argued that protocol changes alone wouldn’t solve their problems: gateways and registries do most of the real work, and the protocol is the layer that gets in their way least. The stateless redesign is that team’s argument winning.

The harder critique is older but unresolved: David Soria Parra himself, interviewed in April 2026, called out a separate failure mode the protocol does not yet address. “Tools come with metadata: descriptions, parameters, schemas. Across dozens of integrations, a significant portion of the context window is consumed before the model does any actual reasoning,” he told ShiftMag. Stateless transport doesn’t fix context bloat. That fight stays in the client layer.

On Hacker News, the long-standing structural criticism of MCP — that the stateful design fought with load balancers, complicated horizontal scaling, and forced harnesses to manage connection lifecycle — gets answered by this release. The stateless redesign is, almost line for line, the pattern those threads asked for.

What to do before July 28

The release candidate is locked. The spec text can still change if blocking issues surface during the 10-week window, but the architectural shape is final. A practical week-by-week:

• Now: read the draft spec. Identify which of your servers hold session state and where you would externalize it. Audit your auth code against the six auth SEPs.
• June: rebuild against the RC SDKs as they land. Verify the routing headers are sent by your client of choice (Claude Desktop, Cursor, Claude Code, VS Code, ChatGPT). Run your servers against the conformance scenarios SEP-2484 references.
• July: deploy a stateless variant of any remote MCP server you operate, behind a plain HTTP load balancer. Measure: does it autoscale? Does a rolling deploy break in-flight tool calls? Multi Round-Trip is the right answer if you previously held connections open.
• July 28+: when the spec ratifies, flip your servers’ declared protocol version to 2026-07-28. Keep the deprecated features functional; do not remove them for at least 12 months.

The verdict

Frequently asked questions

Glossary

All sources

Primary

• The 2026-07-28 MCP Specification Release Candidate — David Soria Parra and Den Delimarsky, MCP Blog, May 21, 2026.
• The 2026 MCP Roadmap — MCP Blog, March 9, 2026.
• Exploring the Future of MCP Transports — MCP Blog, December 19, 2025.
• SEP-1442: Make MCP Stateless (by default) — original proposal, September 8, 2025.
• Model Context Protocol Specification — Draft — the spec text under review.
• MCP Specification Releases — full revision history (2024-11-05 → 2025-11-25 stable).
• Specification Enhancement Proposals index.
• RFC 9207 — OAuth 2.0 Authorization Server Issuer Identification (referenced by SEP-2468).

Community & press

• David Soria Parra @dsp_ — announcement tweet, May 22, 2026.
• AAIF’s MCP Dev Summit: Gateways, gRPC, and Observability Signal Protocol Hardening — InfoQ, April 9, 2026.
• MCP co-creator David Soria Parra on What Breaks MCP at Scale — ShiftMag, April 16, 2026.

Internal

• What is the Model Context Protocol? A Developer’s Map — the foundational explainer.
• MCP Apps vs OpenAI Apps SDK — the rival UI standard SEP-1865 codifies.
• Browse 3,000+ MCP servers
• Best MCP servers
• Remote (hosted) MCP servers — the deployments most affected by stateless routing.
• Claude Desktop, Cursor, VS Code, Claude Code — client guides.