The 2026-07-28 MCP Specification: A Stateless, Extensible Future

A New Era for MCP

On May 21, 2026, the Model Context Protocol team locked the release candidate for the 2026-07-28 specification — the largest revision to the protocol since it launched. The final release ships on July 28, 2026, after a 10-week validation window for SDK maintainers and implementers, with lead maintainers David Soria Parra and Den Delimarsky steering the effort.

If you've been running MCP servers in production, this release is worth paying close attention to. It rethinks how state is managed, how servers scale behind load balancers, how long-running or interactive requests work without persistent connections, and how the ecosystem can add new capabilities without breaking the core spec. Let's walk through what's changing and why.

1. A Stateless Protocol Core

The headline change is the removal of the initialize/initialized handshake and the Mcp-Session-Id header. Previously, an MCP session was pinned to whichever server instance handled the initial handshake, which meant deployments needed sticky sessions or a shared session store to scale horizontally.

Before (2025-11-25):

POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json

{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"}}}

After (2026-07-28):

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
           "_meta":{"io.modelcontextprotocol/clientInfo":...}}}

Every request is now self-contained, so it can be routed to any server instance by a plain round-robin load balancer — no deep packet inspection, no session affinity, no shared state at the gateway layer.

For servers that genuinely need state, the spec formalizes what it calls the explicit-handle pattern: a tool returns an identifier (say, basket_id), and the model threads that identifier back as an argument on subsequent calls. State becomes visible to the model rather than hidden in server-side session storage — which, as a side effect, tends to make the model's reasoning about multi-step operations more reliable.

2. Multi Round-Trip Requests Without Persistent Connections

Server-initiated requests — like elicitations or sampling callbacks — used to depend on holding a Server-Sent Events stream open. That's incompatible with a stateless core, so the new spec introduces InputRequiredResult:

{
  "resultType": "inputRequired",
  "inputRequests": {
    "confirm": {
      "type": "elicitation",
      "message": "Delete 3 files?",
      "schema": { "type": "boolean" }
    }
  },
  "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}

The client collects the requested input and re-issues the call with inputResponses plus the echoed requestState. Because requestState carries everything needed to resume, the retry can land on a completely different server instance and still pick up where it left off.

3. Operational Improvements: Routability, Cacheability, Traceability

Three infrastructure-focused upgrades fall out of the stateless redesign:

• Routability — new required Mcp-Method and Mcp-Name headers let load balancers and gateways route requests without inspecting the JSON-RPC body. Servers reject requests where the headers and body disagree, closing off a class of routing/security mismatches.
• Cacheability — list and resource responses now carry ttlMs and cacheScope fields, modeled directly on HTTP's Cache-Control semantics, so clients know how long a response is fresh and whether it's safe to share across users.
• Traceability — W3C Trace Context is now propagated through fixed key names in _meta, giving you OpenTelemetry-compatible distributed tracing across SDKs and gateways out of the box.

If you operate MCP servers behind API gateways today, these three changes alone should meaningfully simplify your infrastructure.

4. A Formal Extensions Framework

Extensions graduate from an informal convention to a governed system: reverse-DNS identifiers, capability negotiation through extensions maps, dedicated ext-* repositories with delegated maintainers, and versioning independent of the core spec.

Two extensions are worth calling out specifically:

• MCP Apps — server-rendered, interactive HTML interfaces that run in sandboxed iframes. Tools declare their UI templates up front, which allows clients to prefetch them and security-review them before anything renders. UI actions flow back through the same JSON-RPC channel as ordinary tool calls.
• Tasks — promoted from an experimental feature to an official extension after real-world production use drove a redesign. The new lifecycle is stateless by design: tools/call returns a task handle, and the client drives progress via tasks/get, tasks/update, and tasks/cancel. Notably, tasks/list is gone — without sessions, listing all tasks isn't a safe operation to expose. If you built against the experimental Tasks API, you'll need to migrate to this lifecycle.

5. Authorization Hardening

Six Specification Enhancement Proposals (SEPs) bring MCP's auth story closer in line with real-world OAuth 2.0 and OpenID Connect deployments:

• Clients must validate the iss parameter on responses per RFC 9207, mitigating mix-up attacks.
• Clients declare an OpenID Connect application_type during Dynamic Client Registration.
• Credentials are bound to the issuing authorization server's issuer.
• Clearer guidance on requesting refresh tokens from OpenID Connect servers.
• Documented behavior for scope accumulation during step-up authentication.
• Clarified .well-known discovery suffix requirements.

None of these are exotic — they're the kind of hardening that shows up after a protocol has seen enough production traffic to expose the edge cases.

6. Deprecations

Three features enter formal deprecation, with at least a 12-month window before removal:

Feature	Replacement
Roots	Tool parameters, resource URIs, or server configuration
Sampling	Direct integration with your LLM provider's API
Logging	stderr for stdio transports, or OpenTelemetry for structured observability

These deprecations are annotation-only for now — the methods keep working throughout the window — but it's a good time to start planning your migration off them.

7. Full JSON Schema 2020-12 Support

Tool inputSchema and outputSchema now support the full JSON Schema 2020-12 vocabulary. Input schemas can use composition (oneOf, anyOf, allOf) and conditionals, and reference other schemas; output schemas are effectively unrestricted, and structuredContent can hold any JSON value.

One breaking change to flag here: "resource not found" errors move from the custom -32002 code to the standard JSON-RPC -32602 ("Invalid Params"). If your server or client hardcodes -32002, this is a required update.

8. Governance to Prevent Future Breaking Changes

The release also introduces three structural changes meant to keep the protocol stable going forward:

1. A Feature Lifecycle Policy — Active → Deprecated → Removed, with a minimum 12-month window at each stage.
2. The Extensions Framework described above, so new capabilities ship opt-in before (if ever) being folded into the core.
3. Conformance Requirements — Standards Track SEPs now need matching scenarios in the conformance suite before they can reach Final status.

Timeline

• Release candidate locked: May 21, 2026
• Final release: July 28, 2026
• SDK validation window: 10 weeks
• Tier 1 SDKs are expected to ship support within that window.

What This Means If You Run MCP Servers

The throughline across all of these changes is the same: make state explicit, make routing possible without inspecting payloads, and make extensibility a first-class, governed mechanism instead of an afterthought. If you're maintaining an MCP server today, the practical checklist looks like this:

• Audit any reliance on Mcp-Session-Id or implicit session state, and move toward the explicit-handle pattern.
• If you use server-initiated elicitation or sampling, plan a migration to InputRequiredResult.
• If you adopted the experimental Tasks API, budget time to move to the new stateless lifecycle.
• Check for hardcoded -32002 error handling and update it to -32602.
• Start planning migrations off Roots, Sampling, and Logging before the 12-month deprecation windows close.

The validation window runs through the July 28 final release, so now is the time to start testing against the release candidate rather than waiting for launch day.

References

[1] Model Context Protocol. (2026, May 21). The 2026-07-28 MCP Specification Release Candidate. Retrieved from https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/