MCP Protocol Updates: DCR, OAuth CIMD, Streamable HTTP & MCP Apps

The Model Context Protocol moved faster in 2026 than most teams could track. The 2026-07-28 specification — the first major revision after the November 2025 release — did not add a feature; it re-plumbed the protocol. Authorization, transport, routing and interaction all changed, and several widely-used building blocks were deprecated with a fixed removal clock attached.

If you have a handful of MCP servers wired directly into one agent, you can read the changelog and migrate at your own pace. If you run MCP across many teams, many servers and many agents, these changes are not a changelog entry — they are a migration project, and the ones that touch transport and routing will reach every client you operate. This post walks through what actually changed, why each change was made, and what it means for anyone running MCP at scale. For the foundational concepts, our explainer on what an MCP gateway is is the right starting point; this piece assumes you already know the shape of the protocol and focuses on what the new revision breaks and fixes.

Want the new MCP transport, auth, and routing handled at one control point instead of across every client? Book a demo.

The 2026-07-28 release, in one view

Five changes carry almost all of the operational weight. Everything else in the release is downstream of these.

The pattern is consistent: the protocol is shedding stateful, stream-held, implicit behaviour and replacing it with explicit, per-request, header-visible behaviour. That shift is what makes the new revision friendlier to gateways, proxies and rate limiters — and harder on clients that assumed a long-lived session.

Authorization: DCR is out, CIMD is in

Dynamic Client Registration let a client register itself with an authorization server on the fly, minting a client_id at runtime. It was convenient and it was a problem: every client that walked up got a registration, which meant an unbounded, hard-to-govern population of identities, and a registration endpoint that was a standing target.

The 2026-07-28 revision deprecates DCR in favour of Client ID Metadata Documents (CIMD). Instead of registering to obtain an identifier, a client is identified by a URL that resolves to a signed metadata document describing it. The authorization server fetches and validates that document rather than storing a registration. The client's identity is now something the server can verify on demand, from a source the client controls, instead of a row the server has to provision and keep.

Three related hardening changes ship alongside it:

• Issuer validation (RFC 9207). Authorization servers return the iss parameter and clients must validate it before redeeming an authorization code, closing a long-standing authorization-server mix-up gap.
• Issuer-bound credentials. Client credentials are bound to the issuer that minted them, so a token obtained from one authorization server cannot be replayed against another.
• Application type. Clients declare an application_type so servers stop rejecting localhost redirects for legitimate desktop and CLI tools.

There is a sharp edge worth naming: fetching a client-controlled URL server-side is, by definition, a server-side request to an attacker-influenceable address. CIMD trades a registration endpoint for an SSRF consideration, and anyone implementing it needs to treat that metadata fetch with the same care as any other outbound request from inside the trust boundary. Our deeper treatment of these failure modes lives in MCP security risks and best practices, and the mechanics of agent-to-server auth are covered in MCP authentication explained.

The practical takeaway: do not build new integrations on DCR. It is deprecated, it will be removed, and the replacement is better governed. If you already rely on it, you have until at least July 2027 — but the migration is a question of when, not whether.

Transport: Streamable HTTP replaces HTTP+SSE

The old HTTP+SSE transport is officially deprecated with a year-long migration window. Its replacement, Streamable HTTP, is stateless by design, and that single word has large consequences.

Under the new transport there is no initialize / initialized handshake and no Mcp-Session-Id. Each request is self-describing: the protocol version, the client's identity and its capabilities travel in a per-request _meta block, and an optional server/discover call lets a server advertise its capabilities up front. Because every request stands alone, any server instance can serve any request, so servers sit behind an ordinary round-robin load balancer and scale horizontally without sticky sessions.

The cost of statelessness is that lost in-flight requests are not resumed. There is no stream to reconnect to. A client that loses a request must re-issue it with a new ID, which means long-running tools must be idempotent or must hand back a durable handle the client can poll. Cross-call state does not disappear — it just has to be made explicit, typically as a server-issued handle passed as a tool argument and backed by shared storage with an expiry. Dropping protocol-level sessions does not make your application stateless; it moves the responsibility for state from the transport to you.

This is the change most likely to reach every client you run, because it is the wire itself. If your agents each open their own MCP connections, every one of them needs the new transport. If they go through a gateway, the gateway terminates the transport once and your agents keep speaking to a single stable endpoint — which is the entire argument for not letting agents hit servers directly, covered in our piece on hosting remote MCP servers.

Routing: header-based control is the real story

The change with the most leverage for anyone operating infrastructure is the quietest one in the changelog. Streamable HTTP now requires Mcp-Methodon every request and Mcp-Nameontools/call,resources/readandprompts/get. A tool parameter can additionally be marked with x-mcp-header, and conforming clients mirror that argument into an Mcp-Param-{Name} header — the canonical example being a region parameter promoted to a routing header.

Before this, an intermediary that wanted to route or rate-limit by tool had to crack open and parse the JSON-RPC body of every request. Now the routing-relevant facts are in headers, where a gateway, a load balancer or a WAF can read them cheaply and act on them without understanding the payload. You can send tools/call for an expensive tool to a dedicated pool, rate-limit a specific tool by name, or route a tenant's traffic by a region header — all at the edge.

There is one rule that must not be skipped: headers and body must agree. A server that processes the body must verify the headers match it and reject mismatches with a 400 and error code -32020. Any intermediary that rewrites a body must rewrite the headers too, or neither — and a gateway should only trust a header after it has validated the header against the body. Header-based routing is powerful precisely because it is trusted early in the request path, which is exactly why it has to be validated there.

See how the TrueFoundry MCP Gateway absorbs spec changes so your agents never have to. Book a demo.

Interaction: elicitation becomes Multi-Round-Trip

Previously, a server that needed input mid-call — an elicitation, a sampling request, a roots listing — did so over a held-open stream. In a stateless world there is no held-open stream, so the 2026-07-28 revision replaces those server-initiated calls with Multi-Round-Trip Requests (MRTR). The server returns a result of type input_required describing what it needs; the client answers by retrying the original call with the answers in inputResponses and a requestState blob that lets the server resume.

Because the retry can land on a different server instance, the resume path has to be tested that way, and any side effects performed before the input was gathered need reconciliation — MCP offers no exactly-once guarantee. Separately, Roots, Sampling and Logging are deprecated (functional for at least twelve months, removal no earlier than July 2027), Tasks moved into an extension with a poll-based model, and list/read responses now carryttlMsandcacheScopehints so intermediaries can cache safely. That caching hint has a trap in it, addressed below.

MCP Apps: servers can now ship UI

The release also formalises an extensions framework, and the one most likely to matter to product teams is MCP Apps (io.modelcontextprotocol/ui) — interactive UI surfaces rendered by capable hosts. Until now an MCP server returned text and structured data; with MCP Apps it can return an interactive surface that a supporting host renders inline, turning a tool call into something closer to an embedded mini-application.

That is a genuinely new capability and a genuinely new governance surface. A server that can ship UI can ship UI that asks for credentials, that frames a confirmation misleadingly, or that renders content the host did not anticipate — so the same scrutiny you apply to a server's tools now has to extend to anything it can render. MCP Apps is an extension, its maturity is tracked separately from the core spec, and host support is uneven, so treat it as emerging rather than settled. The point for a platform team is simpler: the attack and policy surface of "an MCP server" just grew, and whatever reviews and allowlists you apply to tools should be ready to apply to apps.

What this means if you run MCP in production

Read together, the 2026-07-28 changes push in one direction: the protocol is becoming something an intermediary can govern cleanly. Stateless requests, header-visible routing facts, explicit cache hints and verifiable client identity are all easier to enforce at a control point than they were a year ago. That is the case for putting a gateway between your agents and your MCP servers rather than wiring them together directly.

A gateway is where the new transport is terminated once, where CIMD-based auth is validated once, where Mcp-Name routing and per-tool rate limits are enforced, and where the registry of which servers exist and who may reach them actually lives. When the spec revises again — and it will — the clients pointed at the gateway do not change; the gateway does. TrueFoundry's MCP gateway is built around exactly this control point, and the governance model is detailed in enterprise MCP governance and in the product docs.

If you are weighing a central MCP gateway against letting each team manage its own servers, the trade-offs are laid out in our best MCP gateways comparison, and the protocol-vs-protocol question of where MCP ends and agent-to-agent messaging begins is covered in MCP vs A2A.

Where teams get this wrong

They adopt deprecated primitives in new code. DCR, Roots, Sampling and Logging all still work, so they look safe to build on. They are on a removal clock. New integrations should treat them as off-limits.

They trust headers they never validated. Header-based routing only works because headers are read before the body. A gateway that routes on Mcp-Name without checking it against the body — and rejecting mismatches with 400 / -32020 — has built a routing bypass, not a routing layer.

They mark tenant data cacheable aspublic. The new cacheScope hint is useful and dangerous. A principal- or tenant-specific result marked public can be served by an intermediary to the wrong authorization context. Tenant-scoped responses must never be public.

They assume stateless means no state. Statelessness moved up the stack, it did not vanish. If a tool had cross-call state, that state now needs an explicit handle and durable storage — or it silently breaks when a retry lands on a different instance.

They migrate per-client instead of at the edge. Rolling the new transport out to every agent, SDK and script by hand is the slow, error-prone path. Terminating it once at a gateway is the fast one.

A migration checklist

The order that minimises breakage is roughly: stop the bleeding on deprecations, move the wire, then exploit the new routing.

Conclusion

The 2026-07-28 specification is not a feature drop; it is a re-plumbing. DCR gives way to CIMD, HTTP+SSE gives way to a stateless Streamable HTTP, routing moves into headers, elicitation becomes multi-round-trip, and servers gain the ability to ship UI. Each change is sensible on its own, and together they push MCP toward something an intermediary can govern cleanly — provided someone is operating that intermediary.

That is the quiet conclusion of the whole release. The spec is converging on a world where a control point in front of your MCP servers is not an optional nicety but the natural place for transport, auth, routing and caching policy to live. Put that control point in place once, and the next revision is a configuration change instead of a fleet-wide migration.

Put a control point in front of your MCP servers before the next spec revision lands. Book a demo.