Register an MCP client with an authorization server using a Client ID Metadata Document instead of Dynamic Client Registration

Documented steps

1. Read https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration. Client ID Metadata Documents (CIMD, draft-ietf-oauth-client-id-metadata-document-00) are the preferred registration mechanism in this revision; DCR is deprecated.
2. Follow the registration priority order: use pre-registered client information if you have it; else CIMD if the authorization server supports it; else DCR if the AS advertises a registration_endpoint; else prompt the user to enter client information.
3. Detect CIMD support by checking for 'client_id_metadata_document_supported': true in the AS's OAuth Authorization Server Metadata.
4. Host your client metadata document at an HTTPS URL. The client_id URL MUST use the 'https' scheme and MUST contain a path component, e.g. https://app.example.com/oauth/client-metadata.json.
5. Make the document's own 'client_id' value match the document URL EXACTLY.
6. Include at minimum client_id, client_name and redirect_uris. Typically also client_uri, logo_uri, grant_types (e.g. ['authorization_code']), response_types (['code']) and token_endpoint_auth_method.
7. Use token_endpoint_auth_method 'none' for a public client, or private_key_jwt with JWKS configuration per CIMD section 6.2 for client authentication.
8. Serve the document with sensible HTTP cache headers — authorization servers SHOULD cache it respecting those headers.
9. Use the document URL as your client_id in authorization and token requests. No registration call is needed and the identity is portable across authorization servers.
10. If the AS does not support CIMD and you fall back to DCR, specify application_type: 'native' for desktop, mobile, CLI or locally-hosted clients using localhost/127.0.0.1 redirect URIs, and 'web' for remote browser-based clients.
11. Handle DCR registration failures caused by redirect-URI constraints: surface a meaningful error, and optionally retry with an adjusted application_type or conforming redirect URIs.
12. Bind DCR or pre-registered credentials to the issuing AS: key persisted credentials by the AS 'issuer' identifier, never reuse them with a different AS, and re-register when the AS changes.
13. Verify: fetch your own metadata document over HTTPS, confirm client_id matches the URL byte-for-byte, then complete an authorization code flow using the URL as client_id.