Fix Dynamic Client Registration errors

This check verifies that, when MCP Tower registers itself with Dynamic Client Registration, your authorization server accepts the request and returns a client id.

Check id registration (registration). Results:

pass fail skipped

Why it matters

Before an agent can send a user to sign in, it needs a client id at your authorization server. When the server offers no Client ID Metadata Document support, agents get one by posting their details to the registration_endpoint (RFC 7591). If that request fails, sign-in stops before the user sees a login page.

• Claude uses a Client ID Metadata Document only when your metadata advertises both client_id_metadata_document_supported and the none token endpoint auth method. Otherwise it falls back to Dynamic Client Registration, and it registers a new client on every fresh connection (Claude: Authentication for connectors).
• ChatGPT prefers a Client ID Metadata Document and uses registration_endpoint when the builder chooses it or the document is not supported. It registers once per connection and reuses the client (OpenAI: Authentication).
• The MCP authorization specification 2026-07-28 keeps Dynamic Client Registration for backwards compatibility and deprecates it in favor of Client ID Metadata Documents.

A rejected registration usually affects every agent that registers, so it is worth fixing even if you plan to move to Client ID Metadata Documents; see client identity.

What MCP Tower checks

This check runs only while someone signs in with Sign in to scan. In a scan it shows “Checked when someone signs in.”, and the latest sign-in attempt’s result appears on the server’s page.

1. MCP Tower picks a client identity in this order: client credentials an Admin entered, then a Client ID Metadata Document when your metadata supports it, then Dynamic Client Registration. The first two skip this check. With neither a document nor a registration_endpoint, the check is skipped and the app asks for a client id and secret.
2. MCP Tower sends a POST with a JSON body to registration_endpoint, with a 10-second timeout: client_name “MCP Tower”, its one redirect URI, the grant types authorization_code and refresh_token, the response type code and application_type web. The token_endpoint_auth_method is client_secret_basic or client_secret_post when your metadata lists one of them, and none otherwise.
3. A 2xx response with a client_id is a pass. Anything else is a fail, and the message quotes the HTTP status and the OAuth error and error_description, if the body has them.

MCP Tower’s redirect URI is https://app.mcptower.com/api/mcp-servers/oauth/callback.

Results

Status	Message	Meaning	Fix
pass	Registered a client with Dynamic Client Registration.	The authorization server issued a client id.
fail	Dynamic Client Registration failed with HTTP <status>: invalid_redirect_uri (<description>).	The redirect URI is not allowed. Next step: “Register MCP Tower’s redirect URI with the provider exactly as shown.”	Allow the redirect URI
fail	Dynamic Client Registration failed with HTTP <status>: redirect_uri_mismatch (<description>).	Same as invalid_redirect_uri, with the same next step.	Allow the redirect URI
fail	Dynamic Client Registration failed with HTTP <status>: invalid_client_metadata (<description>).	A field of the request was refused. Next step: “The provider rejected the registration metadata. Allow web clients with the authorization_code and refresh_token grants.”	Accept the client metadata
fail	Dynamic Client Registration failed with HTTP <status>: <error> (<description>).	Any other error code. Next step: “Check the provider’s logs for this error and the client’s configuration.”	Return a client id
fail	Dynamic Client Registration failed with HTTP <status>.	No OAuth error in the body, or a 2xx without client_id. Same next step as above.	Return a client id
fail	The registration endpoint could not be reached (<error class>).	dns_error, connect_error, tls_error, timeout or address_blocked. Next step: “Check that registration_endpoint is reachable over https.”	Make the endpoint reachable
skipped	Checked when someone signs in.	A scan, not a sign-in.	Select Sign in to scan
skipped	Manually entered client credentials are used.	An Admin entered a client id, so nothing is registered.
skipped	Client ID Metadata Document used; no registration needed.	Your server supports CIMD with public clients.
skipped	The provider offers no Dynamic Client Registration.	No registration_endpoint and no CIMD: the app asks for a client id and secret.	Client identity

The description is cut after 200 characters.

How to fix

Allow the redirect URI

1. Find the redirect URI policy for dynamically registered clients on your authorization server. Many servers allow only redirect URIs on approved hosts.
2. Allow MCP Tower’s redirect URI exactly: https://app.mcptower.com/api/mcp-servers/oauth/callback.
3. Allow the agents’ redirect URIs too: https://claude.ai/api/mcp/auth_callback for Claude, a loopback redirect on any port such as http://localhost/callback and http://127.0.0.1/callback for Claude Code (callback URLs), and the ChatGPT redirect URI shown on its management page, such as https://chatgpt.com/connector_platform_oauth_redirect (redirect URL).

Accept the client metadata

MCP Tower registers as a web application that uses the authorization code flow with refresh tokens. A server that accepts only native clients, rejects refresh_token, or does not support the requested token_endpoint_auth_method answers invalid_client_metadata. Allow:

• application_type web;
• grant_types authorization_code and refresh_token, and response_types code;
• every method you list in token_endpoint_auth_methods_supported, including none if you list it.

Return a client id

A successful registration answers 201 Created with a JSON body that holds at least client_id (RFC 7591 §3.2.1). A 200 or 201 without client_id fails, as does an HTML error page. If your server returns another error, its logs say why.

Registration response

HTTP/1.1 201 Created
Content-Type: application/json

{
  "client_id": "<client-id>",
  "client_secret": "<client-secret>",
  "redirect_uris": ["<redirect-uri>"],
  "token_endpoint_auth_method": "client_secret_basic"
}

Make the endpoint reachable

The registration_endpoint in your metadata must be an https URL that answers from the public internet within 10 seconds. An endpoint on a private address is blocked (address_blocked), and a certificate the scanner does not trust is a tls_error.

Tip

If you can enable Client ID Metadata Documents, agents skip registration entirely. See client identity.

Check it yourself

Send the registration request MCP Tower sends. Replace <redirect-uri> with MCP Tower’s redirect URI above:

curl -si https://auth.example.com/register \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  -d '{"client_name":"MCP Tower","redirect_uris":["<redirect-uri>"],"grant_types":["authorization_code","refresh_token"],"response_types":["code"],"token_endpoint_auth_method":"none","application_type":"web"}'

The problem is fixed when the response is 201 Created with a client_id:

HTTP/1.1 201 Created
Content-Type: application/json

{"client_id":"<client-id>","redirect_uris":["<redirect-uri>"]}

A rejected request looks like this, and the error tells you which section above applies:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{"error":"invalid_redirect_uri","error_description":"redirect URI not allowed"}

Each test registers a client, so delete the ones you create if your server keeps them. Then select Sign in to scan again on the server’s page.

References

• MCP authorization 2026-07-28: Dynamic Client Registration and application type and redirect URI constraints
• RFC 7591 §3: the registration request, response and errors
• Claude: Authentication for connectors, “DCR and CIMD details” and callback URLs
• OpenAI: Authentication, “Client registration” and redirect URL