MCP Deprecated Dynamic Client Registration: The CIMD Migration

The 2026-07-28 MCP spec deprecates Dynamic Client Registration in favour of Client ID Metadata Documents, moves Tasks into an extension, and puts Roots, Sampling and Logging on a 12-month clock. What breaks, what to change, and what you can safely ignore.

Short version: The 2026-07-28 MCP specification deprecates Dynamic Client Registration in favour of Client ID Metadata Documents, moves Tasks out of the experimental core into an extension, and puts Roots, Sampling and Logging on a twelve-month deprecation clock. Nothing breaks today. DCR-based auth is the one thing worth planning a migration for.

The Model Context Protocol blog announcing the 2026-07-28 specification

What actually changed

The official release post from lead maintainers David Soria Parra and Den Delimarsky frames the headline as the stateless protocol core. MCP is moving from a bidirectional stateful protocol to request/response. Underneath that headline sit four changes that matter more to anyone already running a server:

Change	Status	Your move
Dynamic Client Registration	Deprecated, prefer CIMD	Plan a migration if you use DCR for auth
Tasks	Moved core to extension	Update the import path
Roots, Sampling, Logging	Deprecated, 12-month support	Audit usage, no rush
Stateless core	New default	Delete session affinity infrastructure

Why DCR is going away

Dynamic Client Registration let a client register itself with an authorization server at runtime and receive a client ID back. That is a stateful step: the server has to store the registration and the client has to hold the result.

Client ID Metadata Documents invert it. The client's ID *is* a URL, and that URL resolves to a document describing the client. The authorization server fetches it when needed. There is nothing to store and nothing to synchronise, which is the same reasoning that drove the stateless core.

If your MCP server does not implement its own authorization, this does not affect you.

The scale context

Two numbers from the maintainers, worth citing because they are first-party rather than analyst estimates: Tier 1 SDKs are pulling close to **half a billion downloads a month**, and the TypeScript and Python SDKs have each crossed **one billion total downloads**. The MCP Registry, launched in September 2025, indexes roughly two thousand servers.

That scale is precisely why the stateless rewrite happened. Sticky sessions are tolerable at a hundred servers and painful at two thousand.

The Model Context Protocol roadmap, listing DPoP and Agent Identity as next milestones

The roadmap points where this is heading: Demonstrating Proof of Possession (DPoP) is being finalised, and Agent Identity work aims to give servers an opinionated way to be reached by an agent acting under its own identity or a user-delegated one. CIMD is the first step on that path, not a one-off change.

What to do this week

Search your codebase for Dynamic Client Registration. If it is absent, you are largely done.
If you import Tasks from the core, repoint it at the extension.
Grep for Roots, Sampling and Logging usage and note it. You have twelve months.
If you built session affinity purely to keep MCP working, schedule its removal.

Our take

The deprecation policy is the underrated part of this release. MCP previously changed without a formal commitment about how long the old way keeps working. A stated twelve-month window turns "we might break your integration" into a plannable date, which is what a protocol needs before serious infrastructure is built on it.

The stateless core will get the attention, but the policy is what makes the next change survivable.

Where to go next

The full 2026-07-28 spec breakdown covers MCP Apps and Tasks in depth
MCP server security checklist for the auth side
Browse the 106 MCP servers we track, with install commands and security classification

Sources

The 2026-07-28 Specification, Model Context Protocol blog, 28 July 2026
MCP roadmap, modelcontextprotocol.io

Frequently asked questions

Is Dynamic Client Registration removed in MCP 2026-07-28?+

Deprecated, not removed. The spec now prefers Client ID Metadata Documents (CIMD), where a client is identified by a URL that resolves to its metadata rather than by registering itself with each server at runtime. Existing DCR flows continue to work, but the formal deprecation policy introduced in this release means you should treat DCR as legacy and plan the CIMD move rather than starting new work on it.

What is CIMD in MCP?+

Client ID Metadata Documents replace runtime registration with a hosted document. The client presents a URL as its client ID; the authorization server fetches that URL to read the client metadata. It removes a stateful registration step, which is the same motivation behind the rest of this release: fewer things a server has to remember between requests.

Do Roots, Sampling and Logging still work?+

Yes. All three are deprecated in the 2026-07-28 spec but the maintainers committed to at least twelve months of continued operation. That is a planning window, not an emergency. Audit where you use them, then move as the replacement paths stabilise.

What does the stateless core actually change for my server?+

A server that previously needed sticky sessions, a shared session store and gateway-level packet inspection can now run behind an ordinary round-robin load balancer. If you built session affinity to make MCP work at scale, that infrastructure becomes removable. This is the headline change of the release and the reason the rest of it exists.

How big is MCP adoption in 2026?+

Per the maintainers on the 2026-07-28 release post, Tier 1 SDKs are seeing close to half a billion downloads a month, with the TypeScript and Python SDKs each crossing one billion total downloads. The MCP Registry, launched September 2025, indexes roughly two thousand servers.

Do I need to migrate right now?+

No. Nothing in this release breaks a working integration on day one. The order that makes sense: check whether you depend on DCR for auth, then whether you use Tasks from the core rather than the extension, then Roots, Sampling and Logging. If none apply, you can adopt the stateless core at your own pace and delete session infrastructure as a bonus.