The portal offers five authentication modes. We answered OAuth 2.0 + Dynamic Client Registration.
The other four, and why each is wrong for a remote server like ours:
| Mode | Why not |
|---|---|
| Client ID Metadata Document | Our authorization server does not advertise client_id_metadata_document_supported. Selecting it routes a flow the server cannot complete |
| Anthropic-held client credentials | Asks Anthropic to store a static client_id we never issued. Clients mint their own |
| Custom URL or credentials at connection time | The URL is identical for every user, and there are no credentials for a user to supply |
| Authless | The endpoint returns 401 with a bearer challenge to any unauthenticated call |
Do not answer this from memory — the authorization server's own discovery document settles it in one request. Fetch /.well-known/oauth-authorization-server and read it:
registration_endpointpresent → DCR is supported. This is the deciding field.client_id_metadata_document_supportedabsent → CIMD is not available, whatever you may assume.
Worth checking at the same time, because a reviewer may ask: code_challenge_methods_supported. Ours advertises both S256 and plain. A client negotiating plain is weaker, but that is the authorization server's advertisement rather than something the MCP server chooses.