Dynamic Client Registration (DCR)
Also written DCR, RFC 7591, MCP dynamic client registration
Dynamic Client Registration (DCR) is the OAuth mechanism, defined in RFC 7591, that lets an MCP client register itself with an authorization server at runtime: it POSTs its name and redirect URIs to a registration endpoint and gets a client_id back. The MCP spec now prefers Client ID Metadata Documents and keeps DCR as a fallback.
What is Dynamic Client Registration in MCP?
Before an OAuth client can sign a user in, the authorization server has to know it: a client_id, and the redirect URIs it may send a user back to. For a website that is a one-off step in a developer dashboard. For an MCP client it cannot be, because a client like Claude, Cursor or an agent meets a new server it has never seen every time a user adds one.
Dynamic Client Registration (RFC 7591) solves that at runtime [3]. The client reads the server's authorization metadata, finds a registration_endpoint, and POSTs its details:
{"client_name":"My MCP Client","redirect_uris":["https://client.example.com/callback"],
"grant_types":["authorization_code"],"token_endpoint_auth_method":"none"}
The authorization server answers with a fresh client_id, and the normal authorization code flow with PKCE follows.
Is DCR still in the MCP spec?
Yes, as the fallback. The 2025-11-25 revision made Client ID Metadata Documents the preferred way to register: the client hosts a JSON document at an HTTPS URL and uses that URL as its client_id, so there is nothing to register at all. Authorization servers and clients "SHOULD" support metadata documents and "MAY" support DCR [1].
The 2026-07-28 revision went a step further and deprecated DCR, keeping it "for backwards compatibility with authorization servers that do not support Client ID Metadata Documents" [2]. Deprecated means still in the spec, with removal no sooner than twelve months later under its lifecycle policy.
A client that supports all of them is told to try, in order: a client it was pre-registered as, then a metadata document if the server's metadata says client_id_metadata_document_supported: true, then DCR if the server publishes a registration_endpoint [1].
Which one do real MCP servers offer?
Mostly DCR, still. In our registry census on 20 August 2026, 263 remote MCP servers answered by asking for credentials, and 186 of their 401s named a protected resource metadata URL (185 distinct). On 9 October 2026 we followed each of those and read the authorization server metadata behind it. 169 published a readable document:
| What the authorization server offered | Servers |
|---|---|
| DCR only | 130 |
| DCR and Client ID Metadata Documents | 32 |
| Client ID Metadata Documents only | 1 |
| Neither | 6 |
So 162 of 169 (96%) offered DCR, and 33 (20%) accepted metadata documents. Every one of the 169 supported PKCE with S256. The 6 offering neither can only be used by a client that was registered with them in advance. These are aggregates of public documents each server named about itself, and no server is listed here.
What should an MCP server support?
Both, if your authorization server can. Clients that follow the 2025-11-25 order will use a metadata document when you advertise one, and the many clients and servers built before it still expect DCR. Supporting only metadata documents today would lock out older clients; supporting only DCR keeps you on the path the spec has deprecated.
If you run DCR, the usual cautions apply: an open registration endpoint accepts anyone, so rate-limit it and validate redirect URIs. And make sure your 401 names your metadata in the WWW-Authenticate header, because that pointer is how a client finds the registration endpoint in the first place. MCP authorization covers the rest of the flow.