MCP Just Went Stateless: What the July 2026 Spec Rewrite Means for Your Integrations

On July 28, 2026, MCP maintainers David Soria Parra and Den Delimarsky shipped the largest revision to the Model Context Protocol since it launched - a rewrite that tears out the stateful core the protocol was originally built on. It's now had five weeks to settle into real codebases, and the picture that's emerged is more useful than the launch-day headlines: this update fixes a genuine architectural problem, bundles in some quietly important extras, and does nothing at all about the security problem MCP actually has right now. Here's what changed, what it means if you run or consume MCP servers, and what we'd actually prioritize.

What "stateless" actually means - and why the old design was a real cost

The original MCP spec worked like a phone call: a client opened a connection, ran an initialize handshake, got handed a session ID, and every subsequent request had to reference that session. SEP-2575 removes that entirely. The initialize and initialized handshake is gone. The session-ID header the server used to mint is gone. Protocol version, client info, and capabilities - previously exchanged once at connection time - now travel in a _meta object on every individual request. Any request can now hit any server instance, because no instance needs to remember who you are from the last one.

That sounds like a technical footnote until you've actually run a session-based MCP server at scale. The old design meant a piece of infrastructure to deploy, manage, and pay for just to hold session state, plus a network hop on every single request to validate that session before any real work could start. Both of those existed purely to compensate for the protocol being stateful in the first place - not because the underlying task needed it. Turning an MCP server into an ordinary, horizontally-scalable HTTP workload, with no sticky sessions and no shared state across instances, removes a whole category of infrastructure that was never buying you anything.

Four more changes bundled into the same release

• Multi Round-Trip Requests (MRTR) - tools can now ask for confirmation or additional input mid-task without holding a stream open the whole time.

• Header-based routing - gateways can route traffic using Mcp-Method and Mcp-Name headers without parsing the request body first, which matters once you’re running MCP traffic through a load balancer or API gateway at any real volume.

• Cacheable tool catalogs - clients no longer have to refetch the full list of available tools on every reconnect.

• A formal Extensions framework - MCP Apps and Tasks are promoted to the first official extensions, giving developers a supported way to keep interface and logic in one connected flow instead of bolting UI on separately.

What the migration actually looks like in code

Concretely, here's the shape of the change. Before 2026-07-28, a client connected once, completed a handshake, and referenced a session ID on every call after that:

// Old (2025-11-25 spec) - stateful
1. POST /mcp  {"method": "initialize", ...}
   <- server returns Mcp-Session-Id: sess_8f2a...
2. POST /mcp  Mcp-Session-Id: sess_8f2a...
   {"method": "tools/call", "params": {...}}
3. POST /mcp  Mcp-Session-Id: sess_8f2a...
   {"method": "tools/call", "params": {...}}
// Every call after step 1 depends on the server
// still holding sess_8f2a... in memory or a session store.

// New (2026-07-28 spec) - stateless
1. POST /mcp
   {"method": "tools/call", "_meta": {"protocolVersion": "2026-07-28", "clientInfo": {...}}, "params": {...}}
2. POST /mcp   // can hit a completely different server instance
   {"method": "tools/call", "_meta": {...}, "params": {...}}
// If a tool needs to remember something between calls, it returns
// an explicit handle in its result, and the client passes that
// handle back as a normal argument on the next call - state lives
// in the conversation, not in server memory.

That second pattern - an explicit handle instead of implicit session memory - is the one migration concept worth actually understanding before you touch a session-dependent tool. Everything else in the rewrite is mechanical; this is the part that changes how you design a multi-step tool.

Authorization finally catches up to how enterprises actually run auth

Six separate proposals (SEPs) went into hardening authorization specifically to align MCP with how OAuth 2.1 and OpenID Connect already work everywhere else. Issuer verification per RFC 9207 requires public clients to validate the iss parameter on authorization responses - closing a class of token-confusion attack. Resource Indicators per RFC 8707 let a client state explicitly which MCP server a given token is meant for, rather than a token being usable anywhere it happens to be accepted. Enterprise-Managed Auth, previously experimental, was promoted to stable - giving organizations a centralized way to gate MCP server access through the identity provider they already run, rather than each server inventing its own auth story.

That last change is the one with the clearest business impact: it's been credited with unblocking Fortune 500 deployments that had stalled specifically because security teams wouldn't sign off on per-server, ad hoc authentication. If your MCP rollout has been stuck in a security review for exactly that reason, this is the update that's meant to unstick it.

A deprecation policy, finally

Every MCP feature now carries a formal Active, Deprecated, or Removed status, with a guaranteed minimum of twelve months between a feature being marked deprecated and the earliest point it can actually be removed. Deprecated features are tracked in a public registry with explicit timelines. Practically, that means the old 2025-11-25 spec keeps working during the transition, and a stateless migration is something you plan on a roadmap - not something you scramble to patch before a hard cutoff. For a protocol that's now embedded in production systems at hundreds of companies, that predictability matters as much as any individual feature in the release.

What this update doesn't fix: MCP's actual security problem

Here's the part that gets lost in architecture-diagram enthusiasm: none of this touches the vulnerability class that's actually hurting MCP deployments today. As of mid-2026, security researchers had confirmed at least seven high- or critical-severity CVEs across major MCP-integrated platforms - including a CVSS 9.6 OS command injection in mcp-remote, a CVSS 9.1 missing-authentication flaw in Microsoft's Azure DevOps MCP server, and a pair of CVEs in the Amazon Q VS Code extension that let a malicious repository achieve arbitrary code execution and steal cloud credentials just by including a crafted workspace config file.

The bigger number is tool poisoning - malicious instructions hidden inside a tool's own metadata, invisible to the human approving the tool call. The MCPTox academic benchmark tested 45 live MCP servers against 20 large language models and measured an average attack success rate of 36.5%, climbing to 72.8% against the weakest model tested. In fairness, vulnerability scanning itself has a reliability problem here too - one independent audit found YARA-based MCP scanners returning a roughly 78% false-positive rate, so treat any single tool's severity count with some skepticism. But the underlying pattern across multiple independent research groups is consistent: the transport layer just got meaningfully more solid, and the application layer - what a tool's metadata is allowed to say, and what an agent is allowed to do without a human actually reading it - remains exactly as exposed as it was before July 28.

The protocol is now stateless: no handshake, no session id, any request can hit any server instance. Plus extensions as first-class (MCP Apps, Tasks), auth hardening, and a proper deprecation policy so we don’t have to do this again.

David Soria Parra, MCP maintainer

If you don't build MCP servers yourself, here's why this still matters

Most businesses reading this aren't writing MCP server code - they're consuming MCP servers built by their CRM vendor, their data warehouse, their support platform, or an internal team that stood one up eighteen months ago. That doesn't put you outside this update's blast radius. Every MCP server your agents connect to is either migrating to the stateless spec on someone else's timeline, or it's staying on the old spec and quietly becoming the thing your security review flags in twelve months when the deprecation clock runs out.

The practical move if you're a consumer rather than a builder: ask each MCP-server vendor you depend on two questions. First, what's their migration timeline to 2026-07-28, and does it land inside your own compliance renewal cycle. Second - and this is the one that actually protects you - have they had their tool metadata independently reviewed for the tool-poisoning class of attack, given that spec version has no bearing on that risk at all. A vendor with a confident answer to the first question and a vague one to the second has fixed the easy problem and left the hard one for you to discover.

The adoption numbers behind why this update landed now

MCP has grown past the point where a spec rewrite is a niche developer concern. SDK downloads have passed 97 million a month, the official registry counts over 9,650 latest server records, and somewhere between 28% and 30% of Fortune 500 companies have deployed or are actively piloting MCP-based orchestration. Separately, Stacklok's 2026 software survey found 41% of surveyed software organizations already in limited or broad production with MCP servers. A protocol at that scale can't stay a stateful, session-per-connection design forever - the stateless rewrite is less a nice-to-have and more a prerequisite for the scale MCP has already reached.

What we'd actually recommend

1. Audit every MCP server you depend on for tool-poisoning exposure now, regardless of which spec version it runs - this update doesn't touch that risk, and the 36.5% average attack success rate in independent testing is not a number to sit on.

2. Plan the stateless migration on the 12-month deprecation window rather than rushing it. If any of your tools rely on session state, the replacement pattern is an explicit handle returned from a tool call and passed back in as an argument on the next one.

3. If your MCP rollout has been stuck in a security review, revisit it now - Enterprise-Managed Auth going stable specifically targets the objection that's been blocking it.

4. Treat every third-party MCP server you didn't build - including ones from major vendors - as untrusted input until you've reviewed its tool metadata yourself. Vendor size has not been a reliable predictor of CVE exposure here.

This is exactly the layer we work in when we build MCP servers for clients - not just wiring up the protocol correctly, but treating tool metadata and agent permissions as a real attack surface from day one, not an afterthought bolted on after the first incident.

The stateless rewrite is a genuinely good piece of infrastructure engineering, and the deprecation policy means you can adopt it on your own schedule. Just don't let a cleaner architecture diagram read as "MCP is now secure" - that's a separate, unfinished project, and it's the one that actually determines whether an agent with tool access is safe to point at your production systems.