An MCP client connects to a server whose protected resource metadata later points to a different authorization server. Which client registration approach avoids re-registering with the new authorization server?
Select an answer to reveal the explanation.
Short Explanation
Your metadata document is like a public business card at a URL: any new front desk can look it up. Pre-registered or DCR credentials are keys cut for one specific lock, so they don't carry over.
Full Explanation
MCP supports three client registration mechanisms. With Client ID Metadata Documents, the client uses an HTTPS URL as its client ID, and the authorization server fetches and validates the JSON metadata at that URL when it sees the identifier. The client registration rules state that such client IDs are portable across authorization servers, because they are self-hosted URLs resolved on demand, so no re-registration is needed when the authorization server changes. Pre-registered credentials are inherently specific to the authorization server that issued them; clients must associate them with that server's issuer identifier and must not reuse them with a different authorization server, surfacing an error if the metadata now names another issuer. The same binding applies to credentials obtained through Dynamic Client Registration, which must be re-registered with the new server; the MCP server's audience staying the same does not change who issued the client credentials. clientInfo is self-reported metadata for display and debugging, not an OAuth client identifier, and authorization servers do not accept it as one. Exam caveat: the priority order is pre-registration if available, then metadata documents if the authorization server supports them, then the deprecated DCR, then asking the user. Operational check: confirm the new authorization server advertises client_id_metadata_document_supported before relying on portability.