Is Dynamic Client Registration deprecated in MCP? Should my MCP server's authorization server keep an open /register endpoint, or switch to Client ID Metadata Documents, and what do I have to secure if I do?

What should I check, step by step?

1. Read your authorization server metadata (/.well-known/oauth-authorization-server or openid-configuration). Add "client_id_metadata_document_supported": true once you accept URL client IDs, and keep registration_endpoint only while you still support DCR.

2. When a client_id is an https URL with a path, fetch it, check it's valid JSON with client_id, client_name and redirect_uris, and require the document's client_id to equal the URL exactly (simple string comparison). Reject anything else with invalid_client.
3. Check the redirect_uri in every authorization request against the document's redirect_uris, exactly as you would for a pre-registered client.
4. Treat the fetch as untrusted input: allow only https, refuse private, loopback and link-local addresses (including cloud metadata at 169.254.169.254) after DNS resolution, set a short timeout, follow no redirects or re-check each hop, and cap the response size; the draft recommends 5 kilobytes.
5. Cache documents according to their HTTP cache headers within bounds you set, and never cache an error or an invalid document.
6. Refuse documents that declare shared-secret client authentication. The draft says token_endpoint_auth_method must not be client_secret_basic, client_secret_post, client_secret_jwt or any other shared-secret method, and client_secret must not appear. Public clients use none with PKCE; clients with a backend can use private_key_jwt with a published JWKS.
7. Show the client's name, the hostname of its client_id URL and the redirect URI hostname on the consent screen. The spec says authorization servers MUST clearly show the redirect URI hostname and SHOULD warn when a client's redirect URIs are localhost only.
8. Decide your trust policy: accept any domain with a warning, or allow-list known client domains for sensitive scopes. The spec lets authorization servers apply domain-based trust policies.
9. If you keep DCR for now, rate-limit /register, require clients to send an application_type (native for desktop, CLI and localhost apps; web for hosted apps), expire unused registrations on a schedule you document, and log registrations so you can see when CIMD has taken over.
10. If you build an MCP client, follow the spec's order: pre-registered credentials first, then CIMD when the server advertises it, then DCR, then ask the user. Key any stored client credentials by the authorization server's issuer and re-register if it changes.

Is Dynamic Client Registration deprecated in the MCP spec?

The 2025-11-25 revision added CIMD as a recommended registration mechanism (SEP-991) and made DCR optional. The 2026-07-28 revision deprecated DCR in favour of CIMD and lists three mechanisms: CIMD when client and server have no prior relationship (described as the most common case), pre-registration when they do, and DCR for backwards compatibility.

• The deprecated-features registry lists DCR's earliest removal as the first spec revision released on or after July 28, 2027. Until then, clients that support all three are told to prefer pre-registered credentials, then CIMD if the authorization server advertises client_id_metadata_document_supported, then DCR if it advertises a registration_endpoint, and finally to prompt the user.
• The MCP spec cites draft-ietf-oauth-client-id-metadata-document-00. The IETF draft has continued to revise; revision -03 was posted on November 2, 2026, so check the current draft for details that have moved.

Why did MCP move from Dynamic Client Registration to Client ID Metadata Documents?

In an August 22, 2025 post on the MCP blog, Paul Carleton set out the problems an open /register endpoint creates in MCP, where users paste any server URL into any client. Every install creates a new registration, so the database grows without bound and an admin sees thousands of records for one app. There's no clean way to tell a client its ID has expired without creating an open redirect. And an unauthenticated endpoint that writes to the database invites denial of service, so admins have to rate-limit it.

• CIMD removes the registration step. The client's ID is the URL of its metadata document, fetched on demand, so there's one ID per application and nothing to expire. The 2026-07-28 spec adds that CIMD client IDs are portable across authorization servers, while pre-registered or dynamically registered credentials are bound to the issuer that created them.

Does a Client ID Metadata Document stop client impersonation?

CIMD proves that whoever controls a domain published a client's metadata. It doesn't prove that the program on the other end is that client. The spec says plainly that CIMD can't prevent localhost redirect URI impersonation: a malicious local app can use a well-known desktop client's client_id and catch the code on the same localhost port, which is why the spec asks for warnings and a visible redirect hostname, and allows extra attestation.

• The MCP blog post describes signed software statements (SEP-1032) and platform-level attestation as the layers aimed at that problem, and says they would work with either DCR or CIMD.
• Your authorization server also takes on the risks of fetching URLs supplied by clients. Both the spec and the IETF draft name SSRF, and the draft adds response size limits and caching rules. Registration only identifies the client; your MCP server still has to validate every access token's audience and refuse tokens issued for other resources.