patchbay audit
·4 min read

MCP server without a registration_endpoint: why clients cannot connect and how to fix it

You point an MCP client at a remote server that uses OAuth. Instead of a login page you get an error along the lines of "server does not support dynamic client registration", or a prompt asking for a client ID you were never given. The server is up, its OAuth metadata loads and still no client can connect on its own.

The cause is one missing field in the authorization server metadata: registration_endpoint.

What the field does

Before an OAuth client can send a user to the login page, it needs a client_id that the authorization server recognises. On the classic web, a developer gets one by filling in a form in a dashboard. That does not work for MCP. The client is whatever the user happens to run, the server has never heard of it and nobody is going to file a ticket with every server operator.

RFC 7591 (Dynamic Client Registration) was the first answer to this. The client sends a POST with its name and redirect URIs to the registration endpoint and receives a client_id in the response. The client discovers where to register from the metadata document:

GET /.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"
}

If the last line is absent, a client that relies on dynamic registration has nowhere to go.

What the current spec says

The MCP authorization spec has moved on here. Revision 2026-07-28 lists three ways for a client to get a client_id: Client ID Metadata Documents, pre-registration and Dynamic Client Registration. Metadata documents are now the recommended route. The client uses an HTTPS URL as its client_id and the authorization server fetches the client's details from that URL. A server signals support with client_id_metadata_document_supported in its metadata. Dynamic Client Registration is still allowed but marked as deprecated and kept for backwards compatibility.

So a missing registration_endpoint is only a problem when the server offers no other automatic route. If your metadata has neither registration_endpoint nor client_id_metadata_document_supported, a third party client is left with asking the user to type in client details by hand. Clients built against earlier revisions only know dynamic registration, so they are locked out even if you support metadata documents.

How common it is

In a sweep of 277 public MCP server URLs on 2026-11-06, 264 were reachable and 5 of them served OAuth metadata without a registration endpoint. That is a small number and it only counts servers whose metadata could be read without credentials. It is also the kind of gap that is invisible to the operator: their own first-party client has a hard-coded client_id and works fine.

Check your server

npx -y @patchbay-nebius/agent audit https://mcp.example.com/mcp

A server that advertises OAuth with neither a registration endpoint nor metadata document support gets finding AUTH-005 at high severity. A server that only offers dynamic registration gets a note at info level that does not affect the grade. No flags are needed and the browser scanner runs the same check.

The fix

  1. Add support for Client ID Metadata Documents and advertise client_id_metadata_document_supported: true in /.well-known/oauth-authorization-server. This is what the current spec recommends for new implementations.
  2. Keep or add a registration endpoint for clients that only speak dynamic registration. It accepts client metadata (at least client_name and redirect_uris) and returns a client_id. Public clients such as CLIs and desktop apps do not get a secret. They protect the flow with PKCE. Advertise the endpoint as registration_endpoint.
  3. Accept loopback redirect URIs in both cases or the next step fails for every native client. That is its own finding, covered here.

Many hosted identity providers support dynamic registration but ship with it switched off. Look for that setting before writing an endpoint yourself.

Open registration is not open access

A common objection is that letting anyone register a client weakens security. Registration only hands out an identifier. The user still has to sign in and approve the request and the server still decides what each token may do. What you should add is abuse control on the endpoint itself: rate limiting, a cap on redirect URIs per client and expiry for clients that never complete a login.

If you cannot offer open registration, document how a client obtains a client_id and say so where users will see it. A server that advertises OAuth and gives third-party clients no way in is the case this check exists for.