MCP Just Shipped Its Biggest Spec Rewrite Since Launch — Sessions Are Gone, and Every Agent Built on the Old Spec Has Homework

On July 28, 2026, the Model Context Protocol project shipped 2026-07-28 — the largest revision to the MCP specification since the protocol launched in November 2024. The release candidate was locked on May 21, 2026, giving SDK maintainers and client implementers a ten-week validation window before today's final publication. The headline change removes the initialize handshake and Mcp-Session-Id header that pinned every client to one server instance, alongside two new opt-in extensions — Tasks and MCP Apps — a six-SEP overhaul of the authorization model, and the protocol's first formal deprecation policy. For anyone who has shipped an MCP server or client against the prior spec, this is not a changelog to skim; three of today's changes require migration work before Tier 1 SDKs finish rolling out support.

Why Sessions Had to Go

Every request in the 2026-07-28 spec is now self-contained, carrying its protocol version and client info in a _meta field instead of relying on a persistent Mcp-Session-Id tied to one server process. That single change means a remote MCP server that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway can now sit behind a plain round-robin load balancer. Server-initiated requests — the prompts a tool sends back mid-call — now only happen while the client's own request is still open, and come back as InputRequiredResult objects the client echoes on retry, so any server instance can pick up where another left off. It's a small API surface change with a large infrastructure consequence: MCP servers can finally scale the way ordinary stateless HTTP services do.

Tasks Grows Up: From Core Feature to Extension

Tasks shipped as an experimental core feature in the 2025-11-25 spec, but production use surfaced enough design problems that the working group pulled it out, redesigned it, and shipped it back as an opt-in extension. In the new model, a tools/call response can return a task handle instead of a result, and the client drives the work forward with tasks/get, tasks/update, and tasks/cancel — with the server, not the client, deciding which calls run long enough to need one. The tasks/list method didn't survive the redesign; the working group concluded it can't be scoped safely without sessions to anchor it. Anyone with a server built against the 2025-11-25 experimental Tasks API needs to migrate before the ten-week validation window closes.

MCP Apps Brings UI Into the Protocol

MCP Apps, formalized as SEP-1865, lets a server ship an interactive HTML interface that the host renders inside a sandboxed iframe instead of returning plain text or JSON. Tools declare their UI templates upfront, so hosts can prefetch them and security-review the markup before a user ever sees it, and every action a user takes inside that rendered UI travels back over the same JSON-RPC channel as a direct tool call — meaning it hits the same audit and consent path, rather than opening a side door around it. Support is negotiated, not assumed: client and server each advertise MCP Apps in a reverse-DNS-namespaced extensions capability map, and if only one side speaks it, the connection still works — it just falls back to plain results.

Auth Gets an OAuth 2.1 Overhaul

Six separate SEPs tighten MCP's authorization model to look like a real OAuth 2.1 deployment rather than an ad hoc bearer-token scheme. MCP servers are now formally OAuth 2.1 resource servers and must implement OAuth 2.0 Protected Resource Metadata under RFC 9728, so a client can discover the correct authorization server automatically instead of hardcoding it. Clients must validate the iss parameter on every token per RFC 9207, closing a mix-up attack where a token issued for one authorization server gets replayed against another. OpenID Connect clients now declare their application_type during Dynamic Client Registration, and credentials bind to the authorization server that issued them, forcing re-registration if a resource migrates elsewhere. None of this is optional cleanup — coverage from WorkOS and SecurityWeek both flag it as the change that turns MCP from a convenient integration convention into something enterprise identity and security teams have to formally govern.

A Deprecation Policy, and Three Features on the Clock

The spec also introduces MCP's first formal lifecycle: Active, Deprecated, and Removed, with a mandatory minimum of twelve months between deprecating a feature and actually removing it. Three features enter deprecation today. Roots is being replaced by tool parameters, resource URIs, or plain configuration. Sampling is being replaced by direct LLM API integration, now that calling a model directly no longer requires routing through the host. Logging is being replaced by stderr output or OpenTelemetry. None of the three disappears immediately, but teams building on any of them now have a clock running, not an open-ended grace period.

What This Means for Developers and AI Teams Right Now

For most developers calling MCP servers through Claude, LangGraph, or another client, nothing breaks today — the extensions model means a server and client that don't both speak Tasks or MCP Apps simply fall back to plain tool calls, and LangGraph 1.0 already treats MCP tools as first-class graph nodes without any of this. The real work lands on the people running MCP servers: anyone using the 2025-11-25 experimental Tasks API has a hard migration ahead of Tier 1 SDK support landing within the ten-week window, and anyone fronting a remote MCP server behind an identity provider now has an OAuth 2.1 configuration to audit — iss validation, Protected Resource Metadata, and re-registration semantics — before a spec-compliant client starts rejecting the old flow. Coming weeks after Anthropic's own push to bring MCP tunnels and self-hosted sandboxes inside the enterprise perimeter, this spec puts the protocol's plumbing on the same enterprise-readiness track as its deployment model.

Bottom Line

The 2026-07-28 spec is the moment MCP stops behaving like a convenient developer convention and starts behaving like infrastructure that has to survive load balancers, security audits, and twelve-month deprecation windows. Removing sessions makes MCP servers boring to operate at scale, which is exactly what enterprise platform teams want; the Tasks and MCP Apps extensions add real capability without forcing every implementation to carry it; and the OAuth 2.1 hardening closes gaps that were always going to get exploited once MCP servers started guarding real production data. If you maintain an MCP server, the ten-week SDK validation window is the actual deadline that matters — not today's publication date.