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.

2. Three Nuances We'd Add to Our July Analysis

Where applications need continuity, explicit handles replace hidden transport state — and they live in the transcript. The stateless design’s elegant move is that context a server chooses to retain now travels as an explicit handle the model passes back as an ordinary argument, a pattern the maintainers recommend over transport-hidden state because the model can see the handle, reason about it, and thread it between tools (the official release notes). The governance nuance our July post couldn’t have written: a handle in model context is a capability-like artifact in plaintext — a basket_id or ticket_id that names live server-side state, visible to everything that can read the transcript, and durable across compaction or not depending on the harness. Whether a captured handle is replayable depends on the server: a handle becomes security-sensitive when possession alone is sufficient to recover or mutate server-side state, so servers should treat it as opaque, authorize every use against the current principal, avoid embedding secrets in it, and log or redact it according to policy. Handles therefore join credentials on the list of things request-level tracing should bind to principals: who minted this handle, under whose authority, and is the caller presenting it inside the workflow it was minted for. Tasks turn temporal validity from a paper problem into a designed behavior. Our authorization-propagation work argued that long workflows outlive their grants; the formalized Tasks extension makes that the expected shape — work continues server-side while the client polls tasks/get — so the question “is the authorization that started this task still valid at completion?” now has a standard place to be asked and, in the extension itself, no mandated answer. The async pattern’s hygiene is therefore application work: implementations should persist an association between each task and the principal and authorization context under which it was created, attribute spend to the task, and propagate revocation to running work — remembering that tasks/cancel is cooperative, so a server acknowledges the intent but is not obligated to stop it (the Tasks extension). Apps are a phishing surface with a saving grace. The security analyses are right that server-rendered UI inside trusted client chrome creates a user-targeted phishing avenue — the trusted-interface problem (Akamai’s assessment) — and right that the rendered content must be treated as untrusted and sandboxed. The grace is architectural, with a boundary worth drawing precisely: an app and its host speak a JSON-RPC dialect of MCP over postMessage in which some messages are ordinary MCP operations like tools/call and most are app-specific ui/* messages (the Apps documentation). Tool invocations an app requests are forwarded by the host as ordinary tools/call requests — so the click that triggers server-side action is not a side channel; it reaches the same governed layer as a direct call, where consent, policy, and audit already live. The ui/* traffic, by contrast, never leaves the rendering client, which keeps its own sandbox and allow-list obligations. The tool-call surface funnels to the choke point; the UI surface stays at the edge — and both need governing, in their places.

3. The Migration Quarter: Where the Gateway Earns Its Keep

Here is where TrueFoundry fits, and the final spec sharpens rather than changes the role our July post assigned the MCP Gateway: when the protocol itself is migrating, the layer every routed MCP call crosses becomes three things at once. The inventory. The first question of any migration — who is running what — is unanswerable by survey and tractable from traffic, because modern MCP requests carry their protocol version, client identity, capabilities, and method metadata on every call. Turning that into a migration inventory is logging and reporting work, not a checkbox that already exists: TrueFoundry’s current public metrics documentation covers MCP servers, tools, methods, callers, latency, failures, and traffic mix — the attribution substrate — and retaining and exposing protocol-version, client, and session-header fields from request records on top of it is the quarter’s first configuration deliverable. The once-for-everyone implementation point. The spec’s client-side hardening — issuer validation (SEP-2468), credential-to-issuer binding, the CIMD transition off DCR — is work each MCP consumer would otherwise implement separately and unevenly. Where the gateway operates as the estate’s downstream MCP client and implements the 2026-07-28 requirements, it can centralize that posture once so every agent behind it inherits it — the same consolidation logic our OAuth-at-the-MCP-layer analysis built for token handling, and a natural fit with the Okta and Azure AD integrations and centralized credential management TrueFoundry documents today; support for each new spec requirement should be verified against the deployed gateway version. The place the new surfaces get policy. Here the documented/recommended line matters, so we draw it. TrueFoundry currently documents centralized MCP authentication, server- and tool-level access control, tool approvals, pre- and post-tool-call guardrails, request tracing, and MCP metrics — controls that apply to every tools/call crossing the gateway, including calls an MCP App initiates through its host. Apps sandboxing and rendering allow-lists live at the rendering client; Task-lifecycle identity, per-task budget attribution, revocation that reaches running work, and handle-to-principal binding are the governance controls this revision recommends — reference architecture to build on that documented substrate, not shipped single features. None of this required the spec to change — which is the quiet vindication worth stating plainly: the 2026-07-28 revision moved the protocol’s security boundaries around substantially (sessions gone, auth relocated, new extension surfaces), and an estate whose governance lived at the gateway layer meets much of the churn as configuration, while an estate whose governance lived in per-server session logic and per-client auth code is now migrating its controls along with its protocol. Choke-point governance’s whole value proposition is that the choke point outlives the spec versions that flow through it — and this is the first MCP revision big enough to test it.

4. Boundaries, Stated Plainly

Sources and limits. The specification changes — the stateless core, extensions framework, Tasks redesign and its breaking status, Apps mechanics, authorization SEPs, deprecations, timelines, and adoption facts — are as documented in the official MCP release posts, specification pages, and the deprecated-features registry, with the cited analyses (WorkOS, Stacktree, Akamai, AAIF, BOVO) used for interpretation, migration experience, and security commentary; everything is paraphrased throughout with one sub-fifteen-word quotation attributed to the maintainers. The spec is just over a week old as we write, implementation details will settle over the coming months, and readers should treat the official specification and changelog as authoritative over any summary, ours included. Our July post is revisited, not retracted — its governance framing carries forward; where this post differs, this post is current. Our interest is the disclosed one: we sell the MCP-gateway layer this post argues the migration favors, and the claim is bounded accordingly — the gateway governs the traffic that actually crosses it, consolidates client-side obligations where it operates as the estate’s MCP client, and observes what it routes; it does not upgrade servers for you, does not make the Tasks migration optional for estates that adopted the experimental API, does not see app-host ui/* traffic, and does not substitute for the sandboxing work Apps require at the rendering client. Two candid limits. First, the spec’s security improvements are real and protocol-level — the protocol-level session-ID fixation and hijacking surface is removed outright, and server-initiated requests may now be issued only while the server is processing a client request, so every elicitation traces back to something the user or their agent started — meaning some of what gateways compensated for is now simply fixed; fair accounting says the plane’s job list shifted, it did not only grow. Second, extension governance is young: which extensions an enterprise permits, per team, is a policy surface the framework creates and nobody yet has mature practice for — we expect to revisit that, too. What the week licenses saying plainly: the protocol just made its bid to be infrastructure — stateless, extensible, dated deprecations, enterprise-aligned auth — and infrastructure-grade protocols deserve infrastructure-grade governance, which is the thesis our July post argued and the July spec, obligingly, just made bigger.

References

• Primary sources — MCP maintainers, “The 2026-07-28 Specification” (stateless core; header routing; cache hints; authorization changes; Tasks and SEP-2663; subscriptions/listen; deprecations; day-one SDK status and launch endorsements); the release-candidate post (the quoted characterization; the six authorization SEPs; MRTR and SEP-2260; the handle pattern; stateless topology); the normative deprecated-features registry (per-feature removal eligibility, including HTTP+SSE’s separate schedule); MCP Apps documentation (the JSON-RPC dialect, ui/* messages, sandbox model, client support); the Tasks extension (lifecycle, tasks/update, cooperative cancellation). Analyses — WorkOS (migration analysis); Stacktree (changelog detail; adoption and connector counts); Akamai security research (new abuse avenues); AAIF migration guide; BOVO (enterprise migration experience).
• TrueFoundry documentation — MCP Gateway (official architecture diagram); MCP authentication & security; guardrails, including tool-call flow (official diagram); budgets; analytics.
• This blog — the July analysis this post revisits; OAuth and token management at the MCP layer; MCP gateway vs proxy vs router; MCP transports in the enterprise; tool poisoning and gateway defense; the centralized MCP registry.

One direct quotation under fifteen words is used, attributed inline to the protocol’s maintainers via the cited release-candidate announcement; all specification details are paraphrased from the official posts, specification pages, and cited analyses, and the week-old final specification and its changelog are authoritative over this summary. This post revisits and updates our July analysis rather than retracting it. Our commercial interest in the MCP-gateway layer is disclosed in the text, and the spec’s protocol-level security improvements are credited as such. TrueFoundry capabilities are stated from public documentation current at the time of writing, with documented features distinguished from recommended governance patterns; the product images are TrueFoundry’s own documentation assets, reproduced with attribution.

‍