Three features that exist in every MCP server built before July 2026 - Roots, Sampling, and Logging - entered a formal deprecation window on July 28, and the spec that killed them also deleted the initialize handshake that every client and server has exchanged since MCP launched.
The 2026-07-28 specification removes the initialize handshake, kills the session ID, and deprecates Roots, Sampling, and Logging in a single update.
If you shipped an MCP server in the past 18 months, there is concrete migration work ahead - though the 12-month deprecation window gives you until at least July 2027 to complete it.
The spec arc actually spans two releases. The July 28 version is the structural one. Then on September 28, 2026, the Agentic AI Foundation shipped the biggest release in MCP's history: finalized stateless architecture, hardened OAuth authorization, a formal 12-month deprecation policy, and MCP Apps and MCP Tasks as official extensions. Most coverage conflates them. They are not the same release.
What the stateless core actually changes at the wire
The simplest way to say it: MCP is no longer a stateful, bidirectional session protocol. It is now a stateless request/response protocol, the same shape as every HTTP API you already run.
Concretely,
the spec removes the initialize handshake, the Mcp-Session-Id header, with protocol version and client info moving into a _meta field on every request.
The routing consequence is significant:
that one change lets MCP servers deploy like any stateless service - serverless and Kubernetes autoscaling finally work without sticky sessions.
Here is the before/after at a glance:
| Dimension | 2025-11-25 (stateful) | 2026-07-28 (stateless) |
|---|---|---|
| Connection setup | initialize / initialized handshake |
None - metadata in _meta per request |
| Instance binding | Mcp-Session-Id pins one instance |
Any request, any instance |
| Routing headers | Optional | Mcp-Method + Mcp-Name required |
| Long-running work | Held connection / experimental Tasks | Tasks extension, formal lifecycle |
| Horizontal scaling | Sticky sessions + shared store | Plain autoscaling, no affinity |
| Serverless fit | Poor (persistent connection) | Native (per-request invocation) |
Streamable HTTP gains mandatory Mcp-Method and Mcp-Name headers, so routing happens without body inspection. SSE streaming is replaced by Multi Round-Trip Requests.
For servers that currently hold SSE connections open while a tool does work, the new model is different:
instead of holding connections open with Server-Sent Events for multi-turn operations, servers now return an InputRequiredResult with a requestState payload; the client re-issues the call with inputResponses and the echoed state, allowing stateless retry handling.
The three breaking changes teams are most likely to miss
Three features are deprecated: Roots, Sampling, and Logging, each with a 12-month removal window. They still work today, but the migration paths are concrete:
- Roots → move to tool parameters or resource URIs
- Sampling → call the LLM API directly from your server
- Logging → emit to stderr or OpenTelemetry instead
The cost is a migration that touches your transport, your gateway config, your auth client, and any agent design that relied on the server calling back into the model.
There is also a small error code change that will silently bite integrations:
missing resource is now -32602, not -32002.
Easy to miss in a code review, annoying to debug in production.
MCP Tasks and MCP Apps: what the extension framework actually buys you
The new approach formalizes how additional capabilities can be handled as optional, versioned extensions. If you want MCP to do something extra, it no longer has to become part of the core specification. That is the structural insight most write-ups skip: the extensions framework is not just about Tasks and Apps - it is the mechanism by which the protocol can grow without the core spec becoming a kitchen sink.
MCP Tasks tackles the reality that not every tool call finishes in one round trip. Instead of holding fragile, long-lived connections open while a batch job or heavy computation grinds away, servers now return a durable task handle; clients can disconnect, crash, restart, and resume polling. Video conversion, audio transcription, multi-step agent workflows - anything that runs for more than a few seconds - now has a standard protocol path instead of a bespoke implementation.
MCP Apps is an official extension built on mcp-ui. While the base MCP specification is restricted to text and structured data, MCP Apps standardizes the delivery of interactive user interfaces - such as dashboards, forms, and data visualizations - from MCP servers to host applications.
Clients and servers explicitly declare which extensions they support. This allows a tools-only implementation to remain simple, while another implementation can opt into advanced functionality - such as Tasks or MCP Apps - only when needed.
Beagle in action#platform-eng, 10:02amAuth hardening: the part that matters for anything behind a paywall
The previous MCP spec's approach to auth was, charitably, "bring your own token." The 2026-07-28 spec aligns MCP authorization with OAuth 2.1 and OpenID Connect in ways that make it meaningfully enterprise-ready.
Auth hardening includes mandatory validation of the OAuth iss parameter - which closes an entire class of mix-up attacks. Per Den Delimarsky explicitly: no known exploitation - "preventive engineering, not incident response."
For teams running paid tools behind MCP, scope-based tool loading enforces least privilege and reduces token usage. The server exposes tools to the AI client based strictly on OAuth scopes and authenticated user privileges. That is not a new concept, but it is now formally specified rather than left to each implementer.
The governance picture matters here too. The AAIF went from roughly 40 members in December 2025 to 240 - and Anthropic's contribution share fell below half. When a single vendor's share of contributions drops below 50 percent of a spec they originally wrote, that is a real governance shift, not just a press announcement.
MCP stateless spec: common questions
What is the MCP 2026-07-28 spec change?
The 2026-07-28 spec - now the current official version, released July 28, 2026 and superseding 2025-11-25 - makes MCP fully stateless. It is the biggest structural change MCP has made since it launched, and if you run a server, it will break things.
Do existing MCP servers break immediately?
No.
Existing servers keep working during a 12-month window, but transport, auth, and deprecated features all need attention.
New SDK clients will not send the initialize message, so servers that require it as the first message will fail against updated clients before the window closes.
What is the MCP Tasks extension?
The Tasks extension in the MCP 2026-07-28 specification provides a clean, standard way to handle long-running tasks at the protocol level. A server returns a durable task handle rather than holding a connection open; clients can disconnect and resume polling later.
What are MCP Apps?
MCP Apps allows servers to ship rich, interactive, server-rendered user interfaces directly into AI clients - moving agent output beyond walls of text toward dashboards, forms, and visualizations. It is an optional extension, not core spec, so clients that do not support it see normal text responses.
Is there a formal deprecation policy now?
Yes. The spec added a formal deprecation lifecycle: Active → Deprecated → Removed, with a minimum 12-month window before anything disappears. Roots, Sampling, and Logging are the first three features to enter the Deprecated state under that policy.