MCP's Biggest Spec Update Ever Ships July 28: Sessions Gone, Extensions In

The Model Context Protocol is getting its largest revision since launch. The 2026-07-28 spec finalizes today, and the core change is architectural: MCP is going stateless.

If you’ve built anything on MCP, you have decisions to make. The new spec contains breaking changes, though the MCP team has committed to a more stable path forward once this particular rework lands.

Sessions are gone

The clearest change: the initialize/initialized handshake is removed, and so is the Mcp-Session-Id header.

Under the current (2025-11-25) spec, every MCP client starts a session, receives a session ID from the server, and carries that ID on every subsequent request. That design pins clients to the server instance that issued the session, which means load balancers need sticky routing and horizontal deployments need shared session stores.

Under 2026-07-28, there is no session. Every request is self-contained. Client info, protocol version, and capabilities travel in a _meta field on each call. Any server instance can handle any request.

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.

The tradeoff is explicit: the protocol no longer manages state for you. Servers that need continuity across calls can mint an opaque handle from a tool and have the model pass it back as an argument on later calls. The MCP maintainers say this pattern is more flexible than session state anyway, because the model can reason about and compose handles across tools in ways that hidden transport-layer state never allowed.

New routing headers, caching hints, and tracing

Three smaller changes make the resulting traffic easier to operate in production.

The Streamable HTTP transport now requires Mcp-Method and Mcp-Name headers, so load balancers and rate limiters can route on the operation without parsing JSON-RPC bodies. Servers reject requests where the headers disagree with the body.

List and resource read responses now carry ttlMs and cacheScope parameters. Clients know exactly how long a tools/list response is fresh and whether it’s safe to share across users. This replaces the older pattern of holding a long-lived Server-Sent Events stream open just to detect list changes.

W3C Trace Context propagation is now formally documented, with fixed key names for traceparent, tracestate, and baggage. A trace starting in a host application can now follow a tool call through the client SDK, the MCP server, and whatever downstream services that server calls, ending up as a single coherent span tree in any OpenTelemetry-compatible backend.

Server-initiated requests, rebuilt

The stateless design creates an obvious problem: how does a server ask the client for something mid-call, like an elicitation prompt?

The new Multi Round-Trip Requests mechanism handles this. Instead of holding a Server-Sent Events stream open, the server returns an InputRequiredResult with the question and an opaque requestState. The client gathers the user’s answer and re-issues the original call with that state echoed back. Any server instance can pick up the retry, because everything needed is in the payload.

Extensions become formal

The old spec had extensions, but no formal process behind them. The new spec adds one: extensions get reverse-DNS identifiers, are negotiated through an extensions map during capability exchange, live in their own ext-* repositories with delegated maintainers, and version independently from the protocol.

Two official extensions ship with this release.

MCP Apps lets servers package interactive HTML interfaces that hosts render in a sandboxed iframe. The UI templates are declared by the server in advance so hosts can prefetch and review them before anything runs. All UI-initiated actions go through the same JSON-RPC and consent path as a direct tool call.

Tasks graduates from an experimental core feature into an official extension. The lifecycle changed significantly compared to the 2025-11-25 experimental version: a server answers a tools/call with a task handle, and the client drives it from there with tasks/get, tasks/update, and tasks/cancel. Developers who shipped against the 2025-11-25 Tasks API will need to migrate.

Deprecated: Roots, Sampling, and Logging

Three original MCP features are deprecated. They’ll continue to work for at least 12 months, but they’re on the path to removal.

Roots (clients specifying relevant filesystem paths) is being replaced by tool parameters, resource URIs, or server configuration. Sampling (servers requesting model completions) is being replaced by direct LLM provider integration. Logging is being replaced by stderr for stdio transports and OpenTelemetry for structured observability.

These are annotation-only deprecations for now. Removal requires a separate proposal under the new feature lifecycle policy.

Tooling support

The GitHub MCP Server already supports the 2026-07-28 spec ahead of the official release. Beta SDK releases are available for Python, TypeScript, Go, and C#.

Python v2 renames FastMCP to MCPServer but keeps the decorator API. TypeScript v2 splits the monolithic SDK into focused packages (@modelcontextprotocol/server, @modelcontextprotocol/client) and is ESM-only. Go ships support in v1.7.0-pre.1.

What to do now

If you’re using an official SDK and not relying on session state, an SDK upgrade should get you through with minimal friction. If you built a custom MCP implementation or depend on Roots, Sampling, or Logging, plan for real work.

The MCP team’s position is that this stateless rework was the one foundational change that needed a clean break, and that future revisions will be significantly less disruptive now that the architecture is set.

Sources: MCP Blog — The Register — GitHub Changelog — WorkOS Blog