Dynamic Client Registration in MCP: Deprecated, and What to Use Instead

Dynamic Client Registration (DCR) is an OAuth standard, RFC 7591, that lets an app register itself with an authorization server automatically and get a client ID back. MCP used it so AI apps could connect to new servers without manual setup. The 2026-07-28 MCP spec deprecated it in favor of Client ID Metadata Documents (CIMD).

Status in the 2026-07-28 spec: deprecated

Deprecated does not mean removed. DCR still works and stays in the spec "for backwards compatibility with authorization servers that do not support Client ID Metadata Documents." This page explains how DCR works, why MCP moved away from it, and what to do now. It follows the 2026-07-28 client registration page, checked on 28 October 2026.

What DCR is

RFC 7591, published in July 2015, "describes how an OAuth 2.0 client can be dynamically registered with an authorization server." The client sends "an HTTP POST to the client registration endpoint with a content type of 'application/json'." The authorization server assigns "a unique client identifier," and may also assign a client secret.

In MCP, the spec says DCR lets "MCP clients obtain OAuth client IDs without user interaction." The client finds the endpoint through the registration_endpoint field in the authorization server's metadata.

How it works in MCP

A registration request from a desktop MCP client might look like this. It is adapted from RFC 7591's request format and the MCP spec's application_type rule; the values are illustrative:

{
  "client_name": "Example MCP Client",
  "application_type": "native",
  "redirect_uris": ["http://127.0.0.1:3000/callback"],
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

The authorization server replies with a client_id, and the client continues with the normal OAuth flow.

The application_type rule

When the authorization server also speaks OpenID Connect, the redirect URIs it allows can depend on application_type. The 2026-07-28 spec says "MCP clients MUST specify an appropriate application_type," because omitting it "defaults to 'web' under OIDC, which can conflict with native-style redirect URIs."

• Desktop apps, mobile apps, CLI tools and localhost web apps "SHOULD use application_type: \"native\"."
• Remote browser-based apps "SHOULD use application_type: \"web\"."

Binding credentials to the issuer

Clients that save DCR credentials "MUST associate those credentials with the specific authorization server that issued them, keyed by the authorization server's issuer identifier." If the MCP server switches to a different authorization server, clients "MUST NOT reuse client credentials" and "MUST re-register."

Why MCP moved away from it

The changelog does not give a written rationale, and the linked pull request is a reorganization of the authorization pages. These are the practical differences the spec's own rules point to.

• One registration per server. A client using DCR registers separately with each authorization server and must store and track every result. CIMD IDs "are portable across authorization servers," so "No re-registration is needed."
• Self-asserted identity. A DCR request is whatever the client says it is. With CIMD, the identity is a URL on the maker's domain, and authorization servers "MAY implement domain-based trust policies."
• Open registration endpoints. The security considerations page says MCP proxy servers using static client IDs "MUST obtain user consent for each dynamically registered client" before forwarding to third-party authorization servers. See the confused deputy problem in MCP.

The 2026-07-28 changelog states the change plainly: "Deprecate the OAuth 2.0 Dynamic Client Registration Protocol (RFC7591) as a client registration mechanism in favor of Client ID Metadata Documents."

What changed across spec versions

The deprecated features registry lists DCR with migration path "Client ID Metadata Documents" and earliest removal "First revision released on or after 2027-07-28." The registry adds that actual removal "is a Core Maintainer decision" and "may happen later." Our MCP versioning and deprecation guide explains the twelve-month policy.

What to do now

If you build an MCP client:

1. Implement CIMD and host your metadata document at a stable HTTPS URL.
2. Check client_id_metadata_document_supported in authorization server metadata.
3. Keep DCR only as a fallback when CIMD is not advertised and registration_endpoint is.
4. When you use DCR, always send application_type, and key saved credentials by issuer.

If you run an authorization server for an MCP server:

1. Add CIMD support and advertise it.
2. Put SSRF protections in front of metadata fetching.
3. Keep the registration endpoint during the deprecation window if existing clients depend on it.

The full CIMD rules are in Client ID Metadata Documents in MCP.

Common mistakes

• Starting a new client on DCR only. New implementations should use CIMD.
• Omitting application_type. OIDC servers may then reject localhost redirect URIs.
• Reusing a client ID after the authorization server changes. The spec forbids it.
• Removing DCR from an authorization server overnight. Older clients may break.
• Treating "deprecated" as "broken." DCR still works and is still in the spec during the deprecation window.

Next step

Large companies often want neither per-user registration nor per-user consent. Read Enterprise-Managed Authorization for MCP next, or see how our MCP development team handles auth migrations.

Frequently asked questions