In March, the MCP maintainers published a 2026 roadmap organized around four priority areas: transport scalability, agent communication, governance maturation, and enterprise readiness. It also marked a shift away from release-based planning toward a working-group-driven process, where SEPs (Specification Enhancement Proposals) aligned with one of the four priorities get expedited review, while everything else faces a longer runway and a higher bar for justification. As the roadmap puts it, “production deployments have different needs than the early experiments that got us here.”
The specification landing at the end of July is the first major release shaped by that roadmap—and the largest revision to MCP since it launched. The release candidate locked on May 21, giving SDK maintainers and client implementers a ten-week window to validate the changes before the final spec publishes on July 28. Here’s what’s actually changing, and why.
Stateless Core
The headline change is a stateless protocol core. The initialize/initialized handshake is gone, along with the Mcp-Session-Id header and the protocol-level sessions that required sticky routing and a shared session store. Protocol metadata—version, client info, capabilities—now travels in _meta on every request instead of being negotiated once at connection time, and a new server/discover method lets clients fetch a server’s capabilities upfront, without a live connection.
The practical effect: any request can land on any server instance. As the release notes put it, “a remote MCP server that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer.”
This doesn’t mean servers lose the ability to maintain state—it means state has to be explicit. Servers mint handles (identifiers returned from tool calls) and the client threads them back as arguments on later calls, which puts state in the model’s hands as an ordinary argument, instead of stashing it somewhere in the transport layer where the model can’t see or reason about it:
Statelessness also cleans up operations beyond load balancing. New Mcp-Method and Mcp-Name headers let gateways route on header values instead of inspecting the request body. List and resource results carry ttlMs and cacheScope fields—borrowed conceptually from HTTP Cache-Control—so clients know how long a result stays fresh. And W3C Trace Context propagates through _meta via traceparent, tracestate, and baggage, so a request can be traced across SDKs and gateways without custom instrumentation.
Server-initiated requests change shape too: unsolicited prompts are gone, and long-running server-to-client exchanges that used to rely on an open SSE stream now use “Multi Round-Trip Requests.” A server returns an InputRequiredResult with a requestState; the client replies with inputResponses and echoes that state back. Because the state is carried in the payload rather than an open connection, any server instance can pick up the next round trip—not just the one that started it.
Extensions
Extensions are now a first-class, formal mechanism rather than an ad hoc pattern: reverse-DNS identifiers, negotiation through an extensions map on capabilities, independent versioning from the core spec, and their own ext-* repositories with delegated maintainers. The intent is to let capabilities evolve without tying their release cadence—or their design mistakes—to the core specification.
The first two official extensions:
MCP Apps — servers can ship interactive, server-rendered HTML interfaces that run in sandboxed iframes. Tools have to declare UI templates before they can be used. This allows prefetching for security-review. The dataflow for the rendered UI still round-trips through JSON-RPC so UI-driven actions are audited and gated by the same consent mechanisms as tool calls.
Tasks — support for long-running work. Tasks actually shipped experimentally in the prior (2025-11-25) spec, but the move to a stateless core forced a redesign, so it re-enters this release as a formal extension rather than a core feature. Under the new model, a tools/call response returns a task handle instead of a result, and the client manages the task’s lifecycle itself by calling tasks/get, tasks/update, and tasks/cancel. Task creation is now server-directed: the client just signals that it supports the extension, and the server chooses which calls turn into background tasks. tasks/list was dropped entirely—without sessions, there’s no safe way to scope “list my tasks” to the right caller. Anyone using the experimental API will need to migrate.
This mirrors the roadmap’s Agent Communication priority almost exactly: Tasks shipped experimental, the maintainers gathered production feedback, and now it’s being reshaped around retry semantics and clearer lifecycle boundaries.
Authorization
Authorization gets hardened to match how OAuth 2.0 and OpenID Connect actually get deployed in practice, via six SEPs:
iss validation — clients must validate the issuer parameter per RFC 9207, closing off mix-up attacks that are especially relevant to MCP’s single-client-many-servers topology. Future spec versions will reject authorization responses that omit iss entirely, so servers should start supplying it now.
application_type declaration — when a client registers itself dynamically, it now has to say up front whether it’s a native app or a web app under OpenID Connect rules, so authorization servers stop silently defaulting desktop and CLI clients to “web” type.
Issuer binding — credentials are bound to the issuing authorization server, and clients must re-register if a resource migrates to a different issuer.
Clarifications on requesting refresh tokens from OpenID Connect-style servers, on scope accumulation for step-up authorization, and on the .well-known discovery suffix.
Lifecycle Governance
Three governance SEPs establish a formal Active → Deprecated → Removed lifecycle, with a minimum twelve-month window between deprecation and removal. Deprecated features keep working during that window; they’re just annotated as on their way out. This release deprecates three pieces of the original protocol:
Roots, superseded by tool parameters, resource URIs, or server configuration
Sampling, superseded by direct integration with LLM provider APIs
Logging, superseded by stderr for stdio transports or OpenTelemetry for structured observability elsewhere
Standards Track SEPs also can’t reach “Final” status anymore without matching test scenarios landing in the conformance suite, which now feeds a tiered scoring system for official SDKs. Combined with the twelve-month deprecation window, it’s a clear signal that MCP is optimizing for predictable evolution over rapid iteration at the core layer—matching the roadmap’s Governance Maturation priority, which flagged full Core Maintainer review of every SEP as a bottleneck regardless of scope.
A smaller but telling cleanup: the custom “missing resource” error code changes from MCP’s own -32002 to the standard JSON-RPC -32602. Small detail, same theme—replace protocol-specific machinery with conventions the rest of the ecosystem already knows.
Conclusion
There are many smaller changes, but the overall direction is more important than any individual feature. MCP is replacing early protocol-specific machinery—sticky sessions, custom error codes, an ungoverned extension surface—with proven infrastructure patterns: stateless HTTP, OAuth/OIDC as actually deployed, semantic versioning-style deprecation windows, and a conformance suite tied to SDK support tiers. It’s becoming easier to deploy, more predictable to integrate with, and better equipped to evolve without repeatedly disrupting the ecosystem around it.
That progress also makes the remaining enterprise boundary easier to see. The roadmap explicitly identifies audit trails, SSO-integrated authorization, gateway behavior, and configuration portability as enterprise-readiness concerns—and, notably, describes that area as still intentionally undefined, an open invitation for enterprise practitioners to help shape it. The expectation is that most of that work will happen through extensions rather than by making the core protocol heavier. MCP is establishing a stronger foundation while deliberately leaving room for the enterprise control plane that has to operate around it. And that’s the gap a gateway like Obot is built for. Obot already brokers OAuth 2.1 server-side, enforces tool-level RBAC, connects to existing identity providers (Okta, Entra, Google, GitHub), and exports audit logs to OpenTelemetry—the exact enterprise controls this roadmap leaves to the ecosystem. And as a gateway sitting in front of MCP servers, it will benefit directly from this release’s stateless core: no more sticky sessions or shared session stores to run around. Try Obot for free today if you’re deploying MCP at enterprise scale.
