Published:
New MCP specification makes the protocol stateless: what it means for your organisation
In short: the MCP specification of 28 July 2026 is the biggest revision since the protocol was created. MCP is no longer a stateful session protocol but a stateless request/response protocol, authorization has been hardened, and features such as Tasks and MCP Apps have moved into a formal extensions framework. Existing integrations keep working: a deprecation window of at least twelve months applies.
The Model Context Protocol now operates at serious scale: the official SDKs are downloaded close to half a billion times per month combined, and the TypeScript and Python SDKs have each crossed one billion total downloads. At exactly that scale, the original architecture started to creak — and this release addresses it head-on.
What exactly has changed?
The core: MCP used to be a session protocol, where client and server performed a handshake (initialize) and then tracked a session via an Mcp-Session-Id header. That is gone. Every request now stands on its own and can land on any server instance behind an ordinary load balancer, without shared session storage. For anyone running remote MCP servers, that is the headline win: cheaper scaling, less complexity, fewer failure modes.
The key changes at a glance:
- Stateless core — no handshake and no session id; standard infrastructure (load balancers, serverless) works without workarounds.
- Multi Round-Trip Requests — servers that need input mid-call (for example a user confirmation) return
resultType: "input_required"instead of holding a connection open. - Header-based routing — HTTP requests now carry
Mcp-MethodandMcp-Nameheaders, so gateways and rate limiters can route traffic without parsing JSON bodies. - Cacheable lists — tool, prompt and resource lists get
ttlMsandcacheScopehints, avoiding unnecessary refetching. - Hardened authorization — issuer validation per RFC 9207 closes a class of authorization-server mix-up attacks, and Dynamic Client Registration gives way to Client ID Metadata Documents.
- Formal extensions framework — Tasks, MCP Apps and Enterprise Managed Authorization are now extensions rather than core features, keeping the core small.
What does this mean for businesses already using MCP?
For most organisations, the answer is reassuring. Local stdio servers — the majority of what teams run today — barely notice the statelessness in practice. If you use off-the-shelf servers through a client such as Claude or Copilot, there is nothing to do: the client vendors handle the migration.
Action is needed for teams that build or host their own remote MCP servers. Code that relies on session identifiers needs updating; the official migration guides cover exactly this scenario. The four Tier 1 SDKs (TypeScript, Python, Go and C#) support the new specification immediately, with Rust in beta. And there is a formal safety net: deprecations — including roots, sampling, logging and the legacy HTTP+SSE transport — get a window of at least twelve months.
Our advice
No panic migration. Put three things on the roadmap: (1) inventory which of your integrations run remotely and on which protocol version, (2) plan the migration of self-built remote servers within the twelve-month window, and (3) take the authorization hardening along while you are migrating anyway — the RFC 9207 validation is not a formality but closes a real attack path. See also our guides on building an MCP server and security & watchouts.
The bigger picture
This release shows MCP maturing the way you hope an open standard does: the protocol gets smaller at the core and stricter at the edges, while governance — housed since late 2025 at the Agentic AI Foundation under the Linux Foundation — adds predictability through a formal deprecation policy. For organisations that doubted whether MCP is here to stay, this is the clearest yes so far.
Sources
- The 2026-07-28 Specification — official MCP blog
- Specification 2026-07-28 — modelcontextprotocol.io
- The next generation of MCP — Cloudflare
Frequently asked questions
Do I need to migrate my existing MCP servers right away?
No. A formal deprecation window of at least twelve months applies, and the previous protocol version remains supported during that period. Do put the migration on your roadmap: new clients will treat the stateless variant as the default.
Will my current MCP connections keep working after this release?
Yes. The Tier 1 SDKs (TypeScript, Python, Go, C#) support the new specification and migration guides cover code that relies on session identifiers. Local stdio servers will barely notice in practice.
What is the main benefit of a stateless MCP?
Scalability and simplicity on the server side: requests can land on any instance behind an ordinary load balancer, without shared session storage. That makes remote MCP servers cheaper and more robust to operate.
Last updated: