Key Takeaways
- MCP’s 2026-07-28 specification is final (published July 28, 2026), replacing the 2025-11-25 version and marking the largest revision to the protocol since its 2024 launch — most notably by removing the original handshake-and-session model in favor of stateless, self-contained requests.
- Scale has moved well past hobbyist tooling. Anthropic reports MCP’s Tier 1 SDKs (Python, TypeScript, Go, C#) are approaching roughly half a billion downloads a month combined, with the TypeScript and Python SDKs each individually surpassing one billion total downloads.
- FastMCP, the most widely used developer framework for building MCP servers, has moved to version 4.0, adding native support for background tasks, stateless session handling, and enterprise authentication patterns aligned with the new spec.
- Authorization has been rewritten to track real-world OAuth 2.0 and OpenID Connect deployments rather than MCP’s earlier, more loosely worded auth model — closing gaps that one enterprise MCP operator said had already caused production incidents.
- Backward compatibility is not automatic. Servers built on the new stateless transport may not interoperate with older clients, and vice versa; deprecated features remain functional for at least 12 months under a newly formalized deprecation policy.
Why This Matters Now
For most of its short life, the Model Context Protocol (MCP) has been described the same way: an open standard, built on JSON-RPC 2.0, that lets AI applications talk to external tools, databases, and files without every team writing its own bespoke integration layer. That description is still accurate. What’s changed is the scale at which it’s now being asked to operate — and the protocol’s architecture just caught up to that reality.
On July 28, 2026, the maintainers of MCP finalized the 2026-07-28 specification, which they and outside reporting have both characterized as the most substantial rewrite of the protocol since it launched. The headline change is structural rather than cosmetic: MCP is moving from a stateful, connection-oriented protocol — one built around an initial handshake and a persistent session — to a stateless, request/response model where each call carries everything a server needs to answer it. For platform teams running MCP behind load balancers at real scale, that is the difference between routing traffic through ordinary HTTP infrastructure and needing sticky sessions or deep packet inspection just to keep a conversation alive.
What Actually Changed in the Spec
The Stateless Core
The previous versions of MCP opened every connection with an initialize/initialized handshake, after which a server could issue a session identifier that the client would send with every subsequent call. That design made sense when MCP’s dominant use case was a single desktop AI application talking to a local tool process over stdio. It becomes a liability once MCP servers are deployed behind pools of replicas serving many clients at once, because the session ties a conversation to one specific server instance.
The 2026-07-28 revision removes that handshake and the accompanying session header entirely. Every request is now self-contained, so any server instance behind a plain round-robin load balancer can answer it — no session affinity, no special routing logic required. Reporting on the change has been direct about the trade-off: the wire format is more complex than before, even as the operational story gets simpler.
Multi-Round-Trip Requests and the Tasks Extension
Removing sessions raises an obvious question: what happens to interactive tools, or ones that take a long time to finish? The spec answers this two ways. Multi-Round-Trip Requests (MRTR) let a single logical operation span more than one request without needing a persistent connection. Separately, the Tasks feature — which had shipped as an experimental part of the core spec in the prior 2025-11-25 release — has been pulled out into a formal extension after production use surfaced enough redesign needs that the maintainers judged it didn’t belong in the core protocol anymore. Under the new model, a server can respond to a tool call with a task handle, and the client drives progress using separate tasks/get, tasks/update, and tasks/cancel calls. Notably, tasks/list was removed outright, because the maintainers concluded it can’t be scoped safely without the session state the protocol no longer has.
Authorization Gets Stricter — and More Enterprise-Ready
MCP’s authorization model has been revised in nearly every release since it was first introduced, and 2026-07-28 continues that trend rather than starting a new one. The spec now aligns more closely with how OAuth 2.0 and OpenID Connect are actually deployed in production, including mandatory issuer validation on authorization responses and a move away from dynamic client registration toward Client ID Metadata Documents. A separate Enterprise-Managed Authorization extension lets organizations govern MCP access through an existing identity provider — Okta or Microsoft Entra ID, for example — so that onboarding, role changes, and offboarding follow a company’s normal identity lifecycle rather than a bespoke MCP-specific process.
One vendor operating a large-scale MCP deployment put the motivation for this bluntly in industry press: earlier ambiguity in the spec’s auth guidance had already produced real production bugs, because some clients didn’t follow OAuth and OpenID Connect edge cases as strictly as the spec assumed they would.
MCP Apps: Interactive Interfaces, Not Just Text
The new spec also formalizes MCP Apps, which let a server deliver an interactive HTML interface that the host application renders inside a sandboxed iframe rather than returning plain text or JSON. Critically, the rendered interface talks back to the host over the same JSON-RPC channel used everywhere else in MCP — meaning a UI-initiated action goes through the same audit and consent path as any other tool call, rather than opening a separate, less-governed communication channel.
A Formal Deprecation Policy
Perhaps the least flashy but most operationally important change is governance, not architecture: MCP now has a documented Active/Deprecated/Removed lifecycle for features, with deprecated capabilities guaranteed to keep working for at least twelve months. Several previously core capabilities — Roots, Sampling, and Logging among them — have been moved into that deprecated bucket, with new implementations steered instead toward tool parameters, direct provider APIs, or standard observability tooling like OpenTelemetry.
What This Means for the Ecosystem
FastMCP 4.0 Ships in Lockstep
FastMCP — the developer framework that turns MCP’s specification into an ergonomic decorator-based API for building servers and clients, maintained by Prefect and widely used across the ecosystem — released version 4.0 alongside the new spec. The release adds first-class support for background tasks, stateless session handling, and enterprise authentication, with the explicit goal of letting existing FastMCP 3.x servers upgrade largely unchanged even as the underlying transport shifts under them. In FastMCP’s own framing, the library “makes stateful MCP applications work on the sessionless protocol without stateless application code” — one server can negotiate either the old handshake-based protocol or the new sessionless one, depending on what the connecting client supports.
That backward-compatibility posture matters because the SDK ecosystem isn’t moving in unison. Python’s SDK is renaming FastMCP internally to MCPServer in its v2 beta while keeping the decorator API; the TypeScript SDK is splitting into focused, ESM-only packages; Go and C# are each shipping their own preview releases on their existing module paths. Teams running mixed-language MCP deployments will need to track version compatibility deliberately rather than assuming everything upgrades at the same pace.
Growth Has Outpaced the Protocol’s Original Design Assumptions
The scale figures help explain why a stateless rewrite became necessary rather than optional. Anthropic has reported that, combined, MCP’s Tier 1 SDKs are approaching half a billion downloads a month, with the TypeScript and Python SDKs each having individually crossed one billion total downloads. The protocol’s own GitHub organization reflects the same growth in a different way: the community servers repository alone has drawn tens of thousands of stars and thousands of forks, and the broader GitHub ecosystem now includes dozens of independent proxy, gateway, and tooling projects — including several Rust-based MCP proxies built specifically to reduce the latency and connection overhead of routing tool calls between agents at scale. That kind of infrastructure tooling is itself a signal: when a protocol designed for one desktop app talking to one local process starts needing purpose-built high-throughput proxies, it has clearly outgrown its original design envelope — which is exactly the gap the 2026-07-28 spec is trying to close at the protocol level instead.
Migration Is Not Optional Busywork
Coverage of the release has been consistent on one point: this is not a drop-in update for teams running MCP in production. Anyone who built against the experimental Tasks API in the prior 2025-11-25 release will need to migrate to the new lifecycle. Client error-handling code that checks for specific JSON-RPC error codes needs updating. Organizations running MCP behind a gateway or load balancer are being advised to explicitly test the stateless request path rather than assume existing routing logic still applies. And because servers built on the new transport may not interoperate cleanly with older clients — and vice versa — mixed-version deployments need real compatibility testing, not just a version bump.
FAQ
Is there an official “MCP 2.0”? Not under that name. MCP versions are date-stamped rather than numbered — the current specification is 2026-07-28, replacing 2025-11-25. Individual SDKs and frameworks (like FastMCP) do use conventional version numbers, and several have reached “2.0” or “4.0” milestones tied to this spec release, which is likely the source of informal “MCP 2.0” references.
Do I have to rewrite my existing MCP servers? Not immediately. Deprecated features are guaranteed to keep working for at least twelve months under the new policy, and frameworks like FastMCP 4.0 are designed to let most existing servers run unchanged while negotiating the correct protocol version per connection. New deployments, and anyone using the experimental Tasks feature from the prior release, will need to update sooner.
What’s the actual benefit of a stateless protocol? The main gain is deployment simplicity at scale. Because every request is self-contained, any server replica behind a standard load balancer can answer it — no sticky sessions, no specialized routing infrastructure just to keep a client tied to the right server instance.
Does this change how MCP handles security? Yes, meaningfully. The spec now aligns more tightly with production OAuth 2.0 and OpenID Connect practices, adds stricter validation steps, and introduces an Enterprise-Managed Authorization extension for governing access through existing corporate identity providers.
Closing Analysis
The open questions now are about adoption speed rather than protocol design. The maintainers gave implementers a ten-week validation window between the release candidate and the final spec, and formal deprecation guarantees soften the migration curve — but the ecosystem’s SDKs are moving at different speeds, from beta renames in Python to full package restructuring in TypeScript, which means version-compatibility testing will matter more over the next year than it has at any prior point in MCP’s history. Worth watching: how quickly major AI platforms require the new stateless transport by default, and whether the Enterprise-Managed Authorization extension becomes the de facto way large organizations govern MCP access, the way SSO became the default for SaaS a decade earlier.
