An MCP client supports every client registration mechanism. When it connects to a server's authorization server, which priority order should it follow?
Select an answer to reveal the explanation.
Short Explanation
Use what you already have first, then the modern self-describing option, then the old fallback, and only then bother the user. If you put Dynamic Client Registration up top, you've fallen for the legacy habit, because it's deprecated now.
Full Explanation
The client registration page defines three mechanisms and a priority order for clients that support them all. First, use pre-registered client information for the server if the client has it. Second, use Client ID Metadata Documents if the authorization server indicates support through client_id_metadata_document_supported in its metadata. Third, use Dynamic Client Registration as a fallback if the authorization server supports it, signalled by a registration_endpoint. Fourth, prompt the user to enter client information if nothing else works. Revision 2026-07-28 deprecates Dynamic Client Registration, retaining it for authorization servers that do not support metadata documents, with Client ID Metadata Documents as the migration path. Starting with Dynamic Client Registration fails because it is the deprecated fallback, not the first choice, and putting pre-registration last ignores an existing relationship. Starting with metadata documents and placing pre-registration after Dynamic Client Registration fails because pre-registered information, when available, comes first. Asking the user first fails by concept: manual entry is the last resort, when no automated mechanism applies. Exam caveat: metadata documents suit the common case of no prior relationship, while pre-registration suits an existing relationship. Operational check: against a server advertising both mechanisms, confirm the client uses a metadata document URL as its client_id.