Why Every Developer Building on MCP Should Read This Spec

The Model Context Protocol hit 97 million monthly SDK downloads this year. It runs in Claude, Cursor, Copilot, Gemini, and VS Code. More than 9,600 public servers are registered in the official MCP registry. At this adoption scale, a spec update is not an academic footnote—it’s a migration planning document for thousands of teams.

The 2026-07-28 specification, which shipped on July 28, is the most significant change to MCP since its November 2024 launch. It removes features, breaks existing session-based implementations, introduces OAuth 2.1 compliance that was previously voluntary, and adds three new capabilities under a versioned extensions framework. If you run an MCP server or build an MCP client, you have a migration window that starts now.

The Core Shift: Sessions Are Gone

The headline breaking change is the removal of both the Mcp-Session-Id header and the initialize/initialized handshake that opened every MCP session. These two constructs were what made the original protocol stateful: a session was pinned to whichever server instance handled the initial handshake, which forced horizontal deployments to use sticky routing or a shared session store to scale.

With both gone, any MCP request can land on any server instance. The protocol is now request/response, not session-oriented. This lets MCP servers deploy on serverless infrastructure and edge networks where sticky sessions are either expensive or impossible.

The tradeoff is that servers which need to carry state across calls must now do so explicitly. The pattern recommended in the spec: mint an explicit handle—a basket_id, a browser_id, whatever suits your domain—from a tool, and have the model pass it back as an ordinary argument on later calls. That’s the same pattern HTTP APIs have used for twenty years. It works.

One practical change for gateway operators: MCP clients now send Mcp-Method and Mcp-Name headers on every Streamable HTTP POST request. If your gateway routes traffic based on session affinity, update it to route on these headers instead before the spec becomes the default.

Authentication Finally Works at Scale

The previous MCP auth story was polite but informal. The 2026-07-28 spec replaces it with a set of concrete RFC-level requirements that make MCP servers proper OAuth 2.1 resource servers. This matters most for enterprise teams running MCP servers that need to work across organizational boundaries.

Four requirements now apply. First, MCP servers must implement OAuth 2.0 Protected Resource Metadata (RFC 9728). This lets clients discover the correct authorization server automatically from the resource server’s metadata endpoint, rather than relying on out-of-band configuration. Second, MCP clients must implement Resource Indicators (RFC 8707), which explicitly binds a token to the specific server it was issued for. This closes a real attack vector: without resource indicators, a malicious server could present a token meant for a different, legitimate server.

Third, authorization servers should return the iss parameter per RFC 9207, and clients must validate it before redeeming a code. This prevents authorization server mix-up attacks, where an attacker substitutes their authorization server in the flow. Fourth, clients set application_type during Dynamic Client Registration so that authorization servers stop rejecting localhost redirects for desktop and CLI apps—a friction point that affected every developer-facing MCP client.

The spec also recommends OAuth Client ID Metadata Documents as the preferred method for client registration, replacing ad-hoc approaches that varied across implementations. These aren’t suggestions—Protected Resource Metadata and Resource Indicators carry MUST-level language. Teams running enterprise MCP servers that skip these will find clients failing to connect once updated clients enforce the requirements.

Three New Capabilities: Embedded UI, Observability, and Private Tunnels

The spec ships three additions under a versioned extensions framework that gives developers a formal path to add capabilities without changing the stateless core.

MCP Apps let a connector render interactive UI inline inside the conversation. The interface is a server-rendered HTML page running in a sandboxed iframe. Tools declare their UI templates upfront so the client can prefetch them and apply security review before display. This closes the loop on a common complaint: MCP servers that need the user to take an action (confirm a booking, review a form, approve a payment) previously had to redirect to an external tab. MCP Apps keep the interaction inside the agent surface.

Observability gives developers a structured dashboard for published connectors in the official MCP registry. The dashboard shows adoption rates, error rates, latency distributions, and usage broken down by Claude product surface (Claude.ai, Claude Code, Claude in Chrome, and so on). For teams running production MCP servers, this is the first time they’ve had first-party visibility into how their connector actually performs across different clients.

MCP Tunnels (still a research preview) connect Claude to MCP servers inside a private network without exposing them to the public internet. No inbound firewall rules, no public endpoints, no IP allowlisting on the origin. For enterprise teams with internal tools that can’t be publicly routed, this removes the main deployment barrier for bringing internal databases, knowledge bases, and APIs into Claude workflows. See also: why the governance model behind who manages these registries and tunnels is becoming a live question.

Three Features Are Now Deprecated

The 2026-07-28 spec deprecates Roots, Sampling, and Logging. Each deprecation comes with a recommended migration path and a formal lifecycle: Active → Deprecated → Removed, with a minimum 12-month window before anything is actually removed.

Roots—the mechanism for a server to declare which file paths it cares about—is replaced by tool parameters or configuration. Sampling—which let an MCP server ask the client to run an LLM inference—is replaced by calling the LLM provider API directly; the spec authors concluded that sampling created an awkward dependency between server and client that didn’t age well. Logging—structured log messages from server to client—is replaced by writing to stderr or publishing via OpenTelemetry, which integrates with existing observability stacks rather than inventing a parallel channel.

The 12-month window means nothing breaks immediately. But if your server uses any of these three features, the time to plan the migration is now, not when the removal window approaches.

What to Do Before the Migration Window Closes

The practical checklist for teams running MCP servers: audit any use of Mcp-Session-Id and implicit session state, and move to explicit handle patterns. Implement Protected Resource Metadata and Resource Indicators—these are required, not optional. Update any gateway that routes on session affinity to route on Mcp-Method and Mcp-Name headers. Begin removing Roots, Sampling, and Logging from server implementations even though the removal deadline is 12 months out.

For teams building MCP clients, the auth hardening means your client needs to handle Protected Resource Metadata discovery, validate iss parameters before code redemption, and send resource indicators on every token request. Clients that skip these steps will fail to connect to hardened servers once they become common.

The 2026-07-28 spec is the MCP protocol growing up. The stateless core makes it deployable on infrastructure where it previously couldn’t run. The auth alignment makes it credible in enterprise security reviews. The extensions framework makes it extensible without breaking the stable core. The combination is what makes MCP defensible as the infrastructure layer for the next wave of agentic deployments—97 million downloads a month is a lot of surface area to get right.

Further Reading

• The 2026-07-28 Specification — Model Context Protocol Blog — the official release post with the full changelog and rationale behind each decision.
• What Changes for AI Agent Authentication — WorkOS — detailed breakdown of the OAuth 2.1 and OIDC requirements, including RFC citations and what clients must implement.
• A Stateless, Extensible Future — MCP Servers Blog — covers the extensions framework and what MCP Apps and MCP Tunnels mean in practice.