Researched guidance: How do MCP Client ID Metadata Documents differ from dynamic client registration?

Summary

MCP distinguishes a client-hosted Client ID Metadata Document (CIMD) from OAuth Dynamic Client Registration (DCR): CIMD uses the HTTPS URL of a JSON metadata document as the client_id and lets an authorization server fetch and validate it on demand, while DCR sends metadata to an authorization-server registration endpoint and receives a server-issued client_id (and possibly a client secret). MCP 2026-07-28 prefers CIMD for new implementations and retains DCR as a compatibility fallback.

Candidate action

1. Read the authorization server metadata. If pre-registration is available, use it; otherwise, when `client_id_metadata_document_supported` is true, use CIMD: publish valid JSON at a stable HTTPS URL, set the document's `client_id` to that URL by exact string match, and send the URL as `client_id`; no POST to a registration endpoint is needed because the authorization server fetches the document. Use `none` or a public/private-key method such as `private_key_jwt`; do not use shared-secret client authentication for CIMD (S1, S3). 2. If CIMD is unavailable and `registration_endpoint` is advertised, use DCR: POST the desired metadata as JSON to that endpoint, then persist the metadata and the server-issued `client_id` and any issued secret returned by the registration response; satisfy MCP's required `application_type` handling for native versus web redirect URIs (S1, S2). 3. Treat DCR credentials as bound to the issuing authorization-server issuer: do not reuse them after the issuer changes; register again. Prefer CIMD for new MCP implementations and use DCR mainly for authorization servers that lack CIMD support (S1).

Applicability

• MCP clients using the HTTP authorization flow with an OAuth authorization server that publishes RFC 8414-style authorization-server metadata.
• Open or previously uncoordinated client/server relationships where the client must obtain an identifier without manual pre-registration, plus legacy deployments that expose RFC 7591 Dynamic Client Registration.
• Implementations choosing between a self-hosted URL-valued client_id and an authorization-server registration endpoint.

Key findings

• CIMD makes the client identifier the URL of a client-hosted JSON metadata document; the authorization server fetches and validates that document rather than receiving a registration POST. (S1, S3)
• DCR requires an HTTP POST with JSON metadata to an authorization-server registration endpoint and returns the registered metadata plus a server-assigned client_id and optionally a client_secret. (S2)
• MCP discovery and selection use client_id_metadata_document_supported for CIMD and registration_endpoint for DCR; the 2026-07-28 MCP page prefers CIMD and marks DCR deprecated for new implementations while retaining it for compatibility. (S1)
• CIMD requires an HTTPS client-id URL with a path and exact client_id matching; the current draft says servers must not automatically follow HTTP redirects and must not cache invalid or malformed documents. (S3)
• Because CIMD has no pre-coordinated shared secret, the current draft prohibits shared-secret token-endpoint methods and client_secret, while allowing public-key-based authentication such as private_key_jwt. (S3)
• RFC 7591 makes DCR credentials and identifiers authorization-server-specific: the server assigns the client_id, may issue a secret, and may maintain registration state or apply initial-access-token and metadata policies. (S2)

Known limitations

• The MCP 2026-07-28 page still names draft-ietf-oauth-client-id-metadata-document-00, while the IETF source consulted here is draft-02 (July 2026); the draft is an Internet-Draft, not a final RFC, and can change.
• These sources define protocol behavior but do not establish that a particular authorization server supports CIMD, permits arbitrary client-id domains, allows the requested redirect URIs, or accepts a given key and policy.
• DCR server policy may gate registration with an initial access token, reject or replace requested metadata, rate-limit requests, or issue no client secret; these are deployment decisions described by RFC 7591.

Evidence boundary

• basis=researched_guidance; executed=false; independent_reproduction=false
• The official MCP and OAuth documents support a protocol comparison only; they do not close a live authorization-server support or execution gap.

What remains unknown

• For a concrete MCP deployment, whether the authorization server advertises `client_id_metadata_document_supported`, whether it advertises `registration_endpoint`, and which fallback order it actually enforces.
• Whether that deployment implements the MCP page's cited -00 behavior or a later OAuth client-metadata draft, including any differences in redirect, fetch, cache, and key-policy handling.
• The deployment-specific trust policy for CIMD domains, metadata refresh and revocation, and DCR registration lifetime or management endpoint.

Evidence status

• basis: researched_guidance
• executed: false
• independent reproduction: false

Sources

• S1 MCP Client Registration (2026-07-28) · official_documentation · accessed 2026-09-22
• S2 RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol · standard · accessed 2026-09-22
• S3 OAuth Client ID Metadata Document, draft-ietf-oauth-client-id-metadata-document-02 · standard · accessed 2026-09-22