MCP 2026-07-28 Ships: Revisiting Apps, Tasks, and Gateway Governance Under the Largest Protocol Revision Since Launch

In late July we published our analysis of governing MCP Apps and Tasks at the gateway — and the protocol promptly gave the post a sequel deadline. On July 28, 2026, the Model Context Protocol’s final 2026-07-28 specification shipped on schedule, after the maintainers’ release-candidate description — the eight words we quote once — called it "the largest revision of the protocol since launch" (the official RC announcement). The scope earns the label. The core goes stateless: protocol sessions and the Mcp-Session-Id header are gone, the initialization handshake is dropped, requests route on Mcp-Method and Mcp-Name headers, list and resource-read results carry cache hints, and applications that need state across calls can mint explicit handles — a basket_id, a ticket_id — returned by tools and passed back as ordinary arguments, a pattern the maintainers recommend over transport-hidden state because the model can see the handle and thread it between tools (the release notes). A formal extensions framework arrives, with reverse-DNS identifiers and independently versioned repositories — and the two features our July post analyzed are among its first official citizens: MCP Apps (server-rendered interactive UI, sandboxed at the host, whose app-initiated tool invocations traverse the ordinary tools/call path) and Tasks, which move out of the experimental core into io.modelcontextprotocol/tasks with a redesigned poll-based lifecycle — tasks/get, tasks/update, cooperative tasks/cancel — that is an explicit breaking change for anyone who shipped against the 2025-11-25 experimental API (WorkOS’s migration analysis; BOVO’s breaking-change notes). Authorization is hardened toward deployed OAuth/OIDC practice across six SEPs, Dynamic Client Registration is deprecated in favor of CIMD, and the protocol gains a formal deprecation lifecycle: Roots, Sampling, Logging, and DCR become eligible for removal no earlier than a revision released on or after July 28, 2027, while the legacy HTTP+SSE transport — deprecated since 2025 — tracks the lifecycle policy’s separately published transition schedule (the deprecated-features registry). Adoption was day-one: all four Tier 1 SDKs speak the new spec at release, AWS, Google Cloud, Microsoft, and Cloudflare were among the launch endorsements, and Claude and Claude Desktop are among the hosts already rendering MCP Apps (the release post; the Apps documentation). Our July post’s thesis — that Apps and Tasks each open a governance surface the gateway must close — survives the revision intact. But the final spec adds nuances we didn’t have then, three of which change how an enterprise should read its own MCP estate this quarter. This post is the promised revisit: what changed between the spec our post was written against and the one that just shipped, the before/after in one diagram, and the new governance work each delta creates.

1. Before and After: What Actually Changed

Our July post was written against the 2025-11-25 world: a stateful protocol (sticky sessions, an initialization handshake, session-ID headers that gateways had to track), Tasks as an experimental core feature, MCP Apps evolving separately as an extension under a still-informal extensions process, notifications over a legacy HTTP GET stream, and an authorization story still centered on Dynamic Client Registration. The 2026-07-28 final replaces each of those pillars, and the practical effect on production topology is immediate: a remote MCP server that needed sticky sessions and a shared session store can now run behind a plain round-robin load balancer with cacheable tool listings — the protocol has been re-shaped for ordinary HTTP infrastructure, which is precisely what “enterprise-grade” means at the transport layer (the RC announcement). The diagram and table below give the delta at a glance; three rows deserve the flag we put on them. Tasks’ move to the extension is breaking — the experimental 2025-11-25 API our post described does not carry forward, and internal servers built against it need auditing now. The deprecations are gentle but dated, with per-feature clocks — under the new Active→Deprecated→Removed lifecycle, Roots, Sampling, Logging, and DCR keep working for at least twelve months and become eligible for removal no earlier than a revision released on or after July 28, 2027, while the legacy HTTP+SSE transport, deprecated since 2025, follows the lifecycle policy’s transition rule and should be tracked on its separately published removal schedule (the normative deprecated-features registry). And the auth hardening lands partly on the client side — the mix-up-attack defense the security analyses prioritize (SEP-2468) is client work, which matters for who in an enterprise actually implements it, a point section 3 returns to.

‍