Research guide · MCP authorization
MCP Client ID Metadata Documents: migrate from DCR
MCP's current authorization model prefers a portable HTTPS client identity over creating a new OAuth registration at every server. Client ID Metadata Documents, usually shortened to CIMD, let the client publish its metadata once and use that document URL as its client_id. Dynamic Client Registration still exists for compatibility, but it is no longer the path new implementations should assume first.
Published 12 September 2026 · sources checked 12 September 2026
CIMD
preferred portable client-registration path
DCR
deprecated, retained as compatibility fallback
2026-07-28
current MCP revision used for this guide
Decision order
Do not replace every client-registration path with CIMD
MCP supports three registration mechanisms because different relationships need different answers. If a client already has preregistered information for the authorization server, use it. Otherwise, use CIMD when authorization-server metadata advertises client_id_metadata_document_supported: true. If CIMD is unavailable but a registration_endpoint exists, DCR remains the compatibility fallback. Only then should the client ask the user for registration information.
The important operational change is that DCR is now deprecated, not deleted. Removing it immediately can reduce interoperability; continuing to make it the default creates a stateful registration dependency that the MCP revision is explicitly moving away from.
Migration sequence
Seven checks for moving from DCR to CIMD
1
Discover the authorization server
Start from the MCP resource's RFC 9728 Protected Resource Metadata and resolve the authorization server. Do not assume the MCP host is also the token issuer.
2
Read authorization-server metadata
Check whether client_id_metadata_document_supported is true. Also record the issuer and whether a legacy registration_endpoint is advertised.
3
Prefer an existing preregistration
If the user or deployment already has credentials for that exact issuer, MCP places those ahead of CIMD. Keep issuer-specific credentials bound to that issuer.
4
Publish one stable CIMD URL
Host the client metadata on HTTPS at a URL with a path. Make client_id exactly equal to the fetched URL and include client_name plus the redirect_uris your client will actually use.
5
Use the URL as client_id
When the authorization server advertises CIMD support, send the metadata URL as client_id and skip the DCR POST. The authorization server fetches and validates the document.
6
Keep DCR only as compatibility fallback
If CIMD is not advertised but registration_endpoint is available, use DCR for compatibility. Do not remove the fallback before measuring the authorization servers you need to support.
7
Test redirect and issuer boundaries
Verify the exact redirect URI, authorization-server issuer, resource indicator and final MCP operation. A successful metadata fetch is not proof that the OAuth flow or MCP call is authorized.
Client artifact
The metadata URL is the client ID
For MCP CIMD, the client hosts JSON at a stable HTTPS URL with a path. The document includes at minimum client_id, client_name and redirect_uris, and the client_id value must match the document URL exactly. Treat redirect URIs as authorization boundaries, not display metadata.
Server signal
Advertise support before clients depend on it
Authorization servers advertise CIMD with client_id_metadata_document_supported: true. A client should not infer support merely because a URL-shaped client_id looks valid. Discovery metadata is what turns CIMD from a guess into a negotiated capability.
Version trap
MCP references CIMD draft-00 while the IETF draft has moved on
The MCP 2026-07-28 authorization specification still names draft-ietf-oauth-client-id-metadata-document-00. Separately, the IETF OAuth working group published revision -02 on 6 July 2026. CIMD remains an Internet-Draft rather than a final RFC.
That means an implementation can be “current” in a general OAuth sense and still disagree with an MCP library that pins an older profile. When debugging interoperability, record the MCP protocol revision, the CIMD draft/profile the SDK implements, the exact metadata fields sent, and the authorization server's advertised capability instead of assuming all CIMD implementations are equivalent.
Security boundary
A self-hosted metadata URL is not automatic trust
CIMD removes the need for an unauthenticated registration write, but the authorization server still has to fetch remote metadata safely, validate the exact client_id match, enforce redirect URIs and apply its own trust policy. The metadata document describes a client; it does not grant that client access to an MCP resource.
Fetching remote client metadata also creates an SSRF boundary. Authorization servers should follow the CIMD security requirements, constrain outbound fetching, respect caching rules and avoid treating names, logos or other remote fields as proof of organizational identity.
Demand signal
Large MCP integrations are still adding CIMD support
Migration is not just specification housekeeping. GitHub's MCP server has an open request for Client ID Metadata Documents so organizations can use OAuth with a wider range of clients without relying on personal access tokens or pre-coordination. Current MCP SDK documentation is also adding explicit CIMD configuration while keeping DCR fallback behavior.
For operators, the practical question is therefore not “CIMD or DCR forever?” but “which authorization servers and clients in my compatibility set advertise and correctly implement CIMD today?” Measure that set before deleting fallback code.
Related implementation guides
MCP OAuth 401/403 troubleshooting
Debug protected-resource discovery, resource indicators, token audiences and insufficient-scope step-up.
Verify an MCP server before connecting
Separate registry presence, endpoint identity, permissions and runtime behavior before granting authority.
Make an MCP server discoverable
Publish stable provider-owned metadata, Registry records and downstream directory signals without duplicate submissions.
Inspect zFinia's machine services
Review the human catalogue, then confirm the current OpenAPI, MCP and payment contracts on api.zfinia.com.