MCP's final 2026-07-28 spec lands Tuesday and removes sessions, the handshake and three core features

The final 2026-07-28 revision of the Model Context Protocol publishes Tuesday, closing a 10-week release candidate validation window that opened on May 21. GaaS News has covered this revision three times already, from the early countdown through the nine-days-out preview to the release candidate itself, so this story skips the recap. The question for Tuesday is narrower: for the teams already running MCP servers in production, what actually breaks, and when.

Sessions and the handshake go away

The two removals with the widest blast radius are protocol-level session IDs and the initialize/initialized handshake. According to the project's release candidate post, the Mcp-Session-Id header disappears, client identity and capabilities move into per-request _meta fields, and the result is "a stateless core that scales on ordinary HTTP infrastructure." Any server that keys per-client state off the session header, and any client that assumes connection setup happens once, is running on removed behavior. New Mcp-Method and Mcp-Name headers let load balancers route requests without inspecting JSON-RPC bodies, which also means sticky-session configurations become unnecessary rather than merely awkward. Server-initiated interactions move from persistent SSE streams to Multi Round-Trip Requests, so infrastructure built around long-lived streams needs rework too. Anthropic's David Soria Parra called the revision the most substantial set of changes to the specification "probably since adding authorization," in remarks from a livestream reported by The Register.

Tasks leaves the core

Tasks, the experimental primitive for long-running work, is demoted from the core protocol to a formal extension, redesigned around stateless operation. Teams that adopted experimental Tasks do not lose the capability, but they do inherit a migration: the extension follows its own release schedule, and depending on it now means tracking a second versioned artifact alongside the core spec.

MCP Apps arrives as the extension model's showcase

Going the other direction, MCP Apps (SEP-1865) ships as a first-class extension that lets servers deliver interactive HTML interfaces rendered in sandboxed iframes. It is the clearest signal of how the project intends to grow after Tuesday: domain-specific surface area lives in independently versioned extensions, and the core stays small. Roughly a dozen lines of the changelog matter less than that structural decision.

Authorization tightens to OAuth and OIDC practice

Six SEPs align MCP authorization with established OAuth and OpenID Connect practice, including issuer validation per RFC 9207 and application_type declaration at client registration, per the release candidate post. Servers with hand-rolled authorization shims will find the final spec considerably more opinionated about what a compliant flow looks like. This lands the same week Okta's Cross App Access reaches its rollout window, which we cover separately today.

The deprecation clock starts Tuesday

Roots, Sampling and Logging are formally deprecated with a minimum 12-month window before removal. The Register reports the project's reasoning: Sampling was rarely used with confusing semantics, Roots proved niche, and logging is better served by stderr, stdio or OpenTelemetry. Nothing breaks Tuesday for users of those features, but the clock is now running, and a July 2027 revision can remove them.

The scale of what this touches is why the details matter. Ecosystem tracking figures cited by The Register put the protocol at more than 10,000 public MCP servers in production and over 97 million monthly SDK downloads as of its donation to the AAIF in 2025. For most of those deployments the practical checklist for Tuesday is short: stop reading the session header, stop expecting the handshake, plan the Tasks migration if it applies, and diff your authorization flow against the six SEPs. The teams that did that during the 10-week window will notice nothing at all, which is precisely the outcome a release candidate process is for.