MCP 2.0 Is Here: Everything Developers Need to Know

In the previous spec, every MCP connection required an initialize handshake that returned an Mcp-Session-Id, pinning clients to a specific server instance. In 2026-07-28, that handshake is gone. Every request is now self-contained — protocol version, client info, and capabilities travel in _meta on every request — meaning any server instance can handle any request. A production MCP server that previously needed sticky sessions and a shared session store can now run behind a plain round-robin load balancer.

Servers that need to carry state across tool calls can return an explicit handle (like a basket_id) from a tool and have the model pass it back as an argument on later calls. In practice this pattern is often more powerful than hidden session state — the model can reason about handles, compose them across tools, and hand them off between agent steps in ways that session metadata never really allowed.

With SSE gone, servers now return an InputRequiredResult when they need to ask the user something mid-task. This response contains the question and an encoded requestState capturing exactly how far the task has progressed. The client gathers the answer and re-issues the original call with the response plus the echoed state. Any server instance can handle the retry because everything it needs is in the payload — no persistent connection required.

Servers may only ask the client for input while actively processing a client request. This is now a hard requirement, not a recommendation. Users are never prompted out of nowhere. Every elicitation traces back to something the user or their agent explicitly started. This also enables parallel agents to be dramatically more efficient — an agent that asks a question no longer has to sit idle waiting for the answer.

The Streamable HTTP transport now requires Mcp-Method and Mcp-Name headers on every request. Load balancers, gateways, and rate-limiters can now route on the operation without opening the request body. Servers reject requests where the headers and body disagree. This is a breaking change for any custom gateway or proxy layer sitting in front of your MCP servers.

List and resource read results now carry ttlMs and cacheScope fields modeled on HTTP Cache-Control, so clients know exactly how long a tools/list response is fresh and whether it is safe to share across users. W3C Trace Context propagation is also now documented in _meta with locked-down traceparent, tracestate, and baggage key names — a trace starting in a host app can follow a tool call all the way through the MCP server and downstream services as a single span tree in any OpenTelemetry backend.

MCP Apps lets servers ship interactive HTML interfaces that hosts render in a sandboxed iframe. Tools declare their UI templates ahead of time so hosts can prefetch, cache, and security-review them before anything runs. Every UI-initiated action goes through the same JSON-RPC audit and consent path as a direct tool call. Think hotel booking widgets, multi-step forms, or approval flows — all inside your agent chat with no context switching.

Tasks shipped as an experimental core feature in 2025-11-25. Production use surfaced enough issues that it has been moved out of the core spec and into a proper extension. A server can now answer tools/call with a task handle, and the client drives it with tasks/get, tasks/update, and tasks/cancel. Anyone who shipped against the 2025-11-25 experimental Tasks API must migrate to this new lifecycle — the old API is gone.

Extensions now have a formal process: identified by reverse-DNS IDs (e.g. io.modelcontextprotocol.tasks), negotiated through an extensions map on client and server capabilities, versioned independently of the core spec, and housed in their own ext-* repositories with delegated maintainers. A new Extensions Track in the SEP process gives community extensions a clear path from experimental to official.

Six SEPs harden the authorization specification to align with how OAuth 2.0 and OpenID Connect are actually deployed in practice. Clients must now validate the iss parameter on authorization responses per RFC 9207. Proper refresh token handling, scope accumulation, and client registration flows — all the patterns developers already know from building web app logins — now apply directly to MCP. The practical effect: setting up an MCP server can be as simple as a single Google or GitHub login, no JSON config files or token management required.

Three older patterns are deprecated in this release. Roots (the old way of passing resource URIs with awkward URL formats) is replaced by cleaner resource URI patterns — just pass a URL the way you would when connecting to a database. Sampling now integrates directly with LLM provider APIs, removing the client-side plumbing that was previously required. Logging is being migrated toward OpenTelemetry as the standard observability layer. All three still work in this release but will not be supported going forward.