How should an MCP client obtain a client_id, in priority order?

## Why there is an order at all A client connecting to a remote MCP server has to present a `client_id` to the authorization server that protects it. Several mechanisms can produce one, and they differ sharply in how much the authorization server knows about the client and how much operational burden each imposes. MCP revision 2026-07-28 spells out the preference order so implementations do not each invent their own. ## 1. Pre-registration If a `client_id` was already arranged out of band — a partnership, a first-party client, a configured deployment — use it. The authorization server has a real record it vetted, so it can grant broader scopes, longer-lived tokens or skip warning language it would show an unknown client. Nothing dynamic can match that level of assurance, so an existing registration always takes precedence. ## 2. Client ID Metadata Documents When there is no prior relationship, the preferred mechanism is CIMD: the client publishes a JSON metadata document at an HTTPS URL that includes a path and uses that URL itself as the `client_id`. The authorization server dereferences the URL and reads `client_name` for display and `redirect_uris` for callback validation. Support is advertised as `client_id_metadata_document_supported`, and a client must check for it before trying. This is the mechanism MCP wants the ecosystem to converge on for open, registration-free onboarding. ## 3. RFC 7591 dynamic client registration — deprecated DCR lets a client POST its metadata to a registration endpoint and receive an issued `client_id` back. It was the original answer to the no-prior-relationship problem in earlier MCP revisions, and it is **deprecated as of revision 2026-07-28** in favour of CIMD. Deprecated does not mean gone: MCP's deprecation policy keeps a deprecated feature in the specification for at least twelve months, with the earliest possible removal in the first revision released on or after 2027-07-28. So a client may still use DCR when talking to an authorization server that offers nothing else, but new implementations should not adopt it as their primary path. When a client does fall back to DCR under MCP's profile, `application_type` is a mandatory field in the registration request. Getting that wrong is a common interoperability failure, because plain RFC 7591 treats it as optional with a default. The reasons for the deprecation are practical. A public registration endpoint mints a new client record on demand, so it accumulates junk and is an obvious abuse target; each registration produces credentials the client must persist and re-register if it loses them; and many authorization servers simply refuse to expose such an endpoint at all, which made DCR unreliable in practice. CIMD produces none of that state: nothing is issued and nothing is stored, so the same client identity works across every authorization server that supports it. ## 4. Prompt the user If the authorization server supports neither CIMD nor DCR, the last resort is to ask the user to obtain a `client_id` themselves — typically by creating an application record in the provider's console — and paste it into the client. It works, but it is a manual step that pushes configuration onto a person, so it belongs at the bottom of the ladder. ## How a client walks the ladder in practice The decision is made per authorization server, not once globally, and it is driven by what that server's metadata advertises. A client checks whether it already holds a `client_id` for this issuer; if not, it looks for `client_id_metadata_document_supported` and uses its metadata URL; if that is absent it looks for a registration endpoint and falls back to DCR with `application_type` set; if that too is absent it surfaces a prompt. Whatever it ends up with should be cached per issuer so the ladder is not re-walked on every authorization. ## The interview angle Because the deployed fleet straddles revisions, the strongest answer names the current preference and the migration story together: CIMD is the answer for new work, DCR is a deprecated compatibility path with a known removal window, and pre-registration still beats both when it exists. A candidate who describes DCR as the recommended MCP registration mechanism is describing MCP as it was before revision 2026-07-28.