MCP Stateless Spec 2026: What Actually Changes

MCP just made its biggest architectural change since launch

If you’ve built or integrated Model Context Protocol servers – and this blog has covered plenty of them, from the WordPress Org MCP server to Kali’s native MCP pentesting workflow – the MCP stateless spec published as “2026-07-28” is worth reading properly rather than skimming the changelog. This isn’t an additive feature release. It’s a genuine architectural shift: MCP is moving from a bidirectional, stateful protocol to a stateless request/response core.

What’s actually being removed

The headline change is stark: the initialize/initialized handshake and the logical Mcp-Session-Id header have been removed entirely from the core spec. If your server or client implementation leans on either of those to track connection state across requests, that assumption no longer holds under the new MCP stateless spec.

• No more handshake-based session establishment as a core requirement
• No more session-ID header threading requests together server-side
• Servers move toward treating each request as self-contained rather than part of a tracked session

What’s being added to make that workable

Removing statefulness isn’t just subtraction – the spec adds several things specifically to compensate:

• Multi Round-Trip Requests – a way to model interactions that genuinely need several exchanges, without requiring a persistent session to do it
• Header-based routing – request routing information moves into headers rather than depending on established session context
• Cacheable list results – list-type responses (tools, resources) become explicitly cacheable, which a stateless model makes much more straightforward to reason about
• Authorization hardening – auth checks get tightened alongside the statelessness change, since you can no longer lean on “this request is part of an already-authenticated session”

The new Extensions framework matters more than any single feature

Perhaps the more consequential long-term change is structural: a formal Extensions framework now exists, so new MCP capabilities can ship as opt-in extensions and stabilise there – possibly for a long time, possibly forever – before (if ever) being folded into the core spec. That’s a deliberate slowdown of core-spec churn, pushed onto an extension layer instead. If you’re building MCP tooling, watch the extensions namespace as closely as the core spec going forward; that’s increasingly where the interesting new capability will land first.

What’s deprecated, and the actual grace period

Tasks moves out of the experimental core into an io.modelcontextprotocol/tasks extension, switching to a poll-based tasks/get plus a new tasks/update. Roots, Sampling, and Logging are all marked deprecated in the core spec – but they’re guaranteed to keep working for at least twelve months, so this isn’t an immediate break for anything currently relying on them. Treat that twelve months as a real deadline to plan around, not an indefinite grace period.

What to actually do about it

1. Check whether your MCP server implementation (or the SDK it’s built on) has published Tier 1 support for the 2026-07-28 spec before assuming compatibility
2. Audit any custom code that reads or sets Mcp-Session-Id directly – that’s the single most likely thing to silently break
3. If you’re using Roots, Sampling, or Logging today, start planning a migration path within the twelve-month window rather than waiting for it to become urgent
4. If you maintain an MCP server used by others, update your documentation now – this is exactly the kind of change that generates confused integration bug reports for months if it isn’t flagged clearly

Why this direction makes sense

A stateless core is a well-understood trade: it scales more predictably behind load balancers, it’s easier to reason about for caching and authorization, and it removes an entire class of “which server instance holds this session” operational headaches. The cost is that anything built assuming persistent session state needs a genuine look, not just a version bump. Given how much of this blog’s recent AI-ML coverage sits on top of MCP servers, the MCP stateless spec is worth treating as required reading rather than background protocol news.