Let agents register themselves

This check verifies how an agent can identify itself to your authorization server: with a Client ID Metadata Document, with Dynamic Client Registration, or only with credentials someone enters by hand.

Check id client_identity (client identity). Results:

pass warn skipped

Why it matters

Before an agent can send a user to sign in, the authorization server must know which client is asking. Agents connect to servers they have never seen, so they need a way to identify themselves without anyone setting up a client first. The MCP authorization specification defines three:

• Client ID Metadata Documents (CIMD). The agent’s client id is an https URL that serves a JSON document describing it, and your authorization server fetches it during sign-in. Nothing is registered or stored. MCP recommends this method.
• Dynamic Client Registration (DCR). The agent registers itself at your registration_endpoint and gets a client id back. MCP 2026-07-28 deprecates it and keeps it only for authorization servers that do not support CIMD (changelog).
• Pre-registration. Someone creates a client by hand and enters its id and secret in the agent.

How the agents choose:

• Claude selects CIMD only when your metadata advertises both "client_id_metadata_document_supported": true and "none" in token_endpoint_auth_methods_supported, because its CIMD client is a public client with no secret. If either is missing, it falls back to DCR. Claude also notes that DCR registers a new client on every fresh connection, which can leave very large numbers of clients on your authorization server (Claude: Authentication for connectors).
• ChatGPT prioritizes CIMD when it is available and uses DCR otherwise (OpenAI: Authentication).
• With neither method, users cannot connect on their own. Each agent then needs a client created for it in advance, through whatever process that agent offers for predefined clients.

What MCP Tower checks

1. MCP Tower reads the authorization server metadata that the authorization server metadata check found and validated.
2. CIMD counts as offered only when client_id_metadata_document_supported is true and token_endpoint_auth_methods_supported contains none, the same rule Claude applies. Then the check passes.
3. Otherwise, if the metadata has a registration_endpoint, DCR is offered and the check warns that it is the only method.
4. Otherwise the check warns that only manually entered credentials work.
5. If discovery stopped earlier, the check is skipped with the reason of the step that stopped it.

This check never fails: sign-in can still work. It only tells you which agents can connect without help. MCP Tower itself then signs in the same way: with CIMD when it is offered, with DCR when not (or when its own client document is not reachable, as in local development), and with the client id and secret you enter when neither is available. Whether that registration succeeds is the client registration check.

Results

Status	Message	Meaning	Fix
pass	Client ID Metadata Documents are supported with public clients.	CIMD and the none auth method are both advertised.
warn	Only Dynamic Client Registration is offered. It is deprecated in MCP 2026-07-28, and Claude prefers Client ID Metadata Documents.	registration_endpoint is present, but CIMD or none is missing.	Add CIMD
warn	Neither Client ID Metadata Documents nor Dynamic Client Registration is offered, so only manually entered client credentials work.	Agents cannot register themselves.	Offer a self-service method
skipped	Needs the protected resource metadata.	Discovery stopped at protected resource metadata.	Fix that check first
skipped	Needs an authorization server.	Discovery stopped at authorization servers.	Fix that check first
skipped	Needs the authorization server metadata.	Discovery stopped at server metadata.	Fix that check first
skipped	Needs valid authorization server metadata.	The metadata’s issuer did not match; see server metadata.	Fix that check first

The next step for the DCR warning is: “Enable Client ID Metadata Documents (client_id_metadata_document_supported) and the none token endpoint auth method.” For the manual-only warning it is: “Agents register themselves. Enable Client ID Metadata Documents, or at least Dynamic Client Registration, or agents cannot connect.”

How to fix

Only DCR is offered

1. Enable Client ID Metadata Documents in your authorization server. It must fetch a client id that is an https URL, check that the document’s own client_id equals that URL, and check the requested redirect_uri against the document’s redirect_uris.
2. Allow public clients at the token endpoint: add none to token_endpoint_auth_methods_supported. These clients authenticate with PKCE instead of a secret.
3. Publish "client_id_metadata_document_supported": true in the metadata. Keep registration_endpoint for agents that do not support CIMD yet.

If you already publish client_id_metadata_document_supported but still get this warning, the none method is missing: without it, Claude, and MCP Tower, fall back to DCR.

Metadata that passes:

https://auth.example.com/.well-known/oauth-authorization-server

{
  "issuer": "https://auth.example.com",
  "authorization_endpoint": "https://auth.example.com/authorize",
  "token_endpoint": "https://auth.example.com/token",
  "registration_endpoint": "https://auth.example.com/register",
  "client_id_metadata_document_supported": true,
  "token_endpoint_auth_methods_supported": ["none", "client_secret_basic"],
  "code_challenge_methods_supported": ["S256"]
}

Neither method is offered

1. Prefer CIMD, as in the previous section: it needs no registration endpoint and no client storage.
2. If your authorization server cannot support CIMD, enable Dynamic Client Registration (RFC 7591) and publish its URL as registration_endpoint. Allow the authorization_code and refresh_token grants for clients registered this way.
3. Until then, create a client for each agent by hand and give users its id and secret. In MCP Tower, enter them when Sign in to scan asks for a client id, and register the redirect URI it shows.

Note

CIMD lets your consent screen name the app reliably: show the host of the client_id URL, since the document’s client_name is chosen by the client itself.

Check it yourself

Print the three fields this check reads:

curl -s https://auth.example.com/.well-known/oauth-authorization-server \
  | jq '{client_id_metadata_document_supported, token_endpoint_auth_methods_supported, registration_endpoint}'

The check passes when CIMD is true and the methods include none:

{
  "client_id_metadata_document_supported": true,
  "token_endpoint_auth_methods_supported": ["none", "client_secret_basic"],
  "registration_endpoint": "https://auth.example.com/register"
}

A null CIMD field with a registration_endpoint gives the DCR warning, and null in both gives the manual-only warning. Then select Scan again on the server’s page.

References

• MCP authorization 2026-07-28: Client registration and the deprecation of Dynamic Client Registration
• OAuth Client ID Metadata Document (IETF draft)
• RFC 7591 §3: Dynamic Client Registration
• RFC 8414 §2: the registration_endpoint and token_endpoint_auth_methods_supported fields
• Claude: Authentication for connectors, “DCR and CIMD details”
• OpenAI: Authentication, “Client registration”