# Atlas: Server does not support dynamic client registration > Register an OAuth client with the provider, set `oauth: { clientId: "..." }` on the server entry, restart Atlas, then run `atlas mcp auth `. Atlas sets status needs_client_registration and prints "Server does not support dynamic client registration. Please provide clientId in config." because the OAuth error from the transport contained "registration" or "client_id", so connectRemote classified it as a registration failure and stopped trying further transports. Fix it by registering an OAuth client with the MCP server provider yourself, setting `oauth: { clientId: "..." }` on that server entry, restarting Atlas, and re-running `atlas mcp auth `. ## Symptom Status needs_client_registration with the error "Server does not support dynamic client registration. Please provide clientId in config." plus a toast telling you to add a clientId. ## Cause The OAuth error message from the transport contains "registration" or "client_id", so connectRemote classifies it as a registration failure rather than a plain auth prompt, and stops trying further transports. ## Fix 1. Register an OAuth client with the MCP server provider yourself and note the client id (and secret if required). 2. Set `oauth: { clientId: "..." }` on that server entry in your Atlas config, alongside optional clientSecret, scope, callbackPort, and redirectUri. 3. Restart Atlas so McpOAuthProvider is constructed with the supplied clientId. 4. Re-run `atlas mcp auth ` and confirm the status becomes connected. ## Why Atlas reports needs_client_registration for an MCP server Atlas reports needs_client_registration when the OAuth error message coming back from the transport contains 1 of 2 markers, "registration" or "client_id". connectRemote reads those markers, classifies the failure as a registration problem rather than a plain auth prompt, and stops trying any further transports for that server. The distinction Atlas draws here is deliberate. A plain auth prompt leads to status needs_auth, which you clear by running the OAuth flow. A registration failure leads to status needs_client_registration, which no amount of re-running the login will clear, because the MCP server never issued Atlas a client id to log in with. The error text is explicit: "Server does not support dynamic client registration. Please provide clientId in config." Atlas connects to Model Context Protocol servers and exposes their tools to the agent, but it cannot invent an OAuth client for a provider that refuses to mint one dynamically. You have to supply the client id yourself. ## How to fix dynamic client registration errors in Atlas Fix the Atlas needs_client_registration error in 4 steps: register an OAuth client with the MCP server provider yourself, set `oauth: { clientId: "..." }` on that server entry, restart Atlas so McpOAuthProvider is constructed with the clientId, then re-run `atlas mcp auth `. Registration happens outside Atlas, in the MCP server provider's own console or admin flow. Create the OAuth client there and note the client id, plus the secret if the provider requires one. Then edit that server entry in your Atlas config and add `oauth: { clientId: "..." }`. The oauth block also accepts clientSecret, scope, callbackPort, and redirectUri, all optional, so a provider that requires a confidential client or a specific scope list can be configured from the same place. Restart Atlas afterwards. The restart is what causes McpOAuthProvider to be constructed with the clientId you supplied rather than attempting dynamic registration again. ## How to verify the clientId fix worked in Atlas Verify the Atlas clientId fix in 2 steps, in order: restart Atlas, then re-run `atlas mcp auth ` and confirm the status becomes connected. A row still reading needs_client_registration means McpOAuthProvider was not constructed with your clientId, usually because Atlas was not restarted or the oauth block sits on the wrong entry. Order matters when verifying this Atlas fix. The restart must come before the re-auth, because McpOAuthProvider is constructed at startup with whatever the config supplies. Re-running `atlas mcp auth ` against a still-running Atlas process will reuse the old provider and reproduce the same registration failure. Once the status reaches connected, the server's tools are exposed to the agent again, and every one of those tool calls is permission-gated against allow, ask, and deny rules before it runs. If the status moves from needs_client_registration to needs_auth, that is progress: registration is solved and only the login remains. ## What goes in the Atlas oauth config block for an MCP server The Atlas oauth block on an MCP server entry accepts 5 fields: clientId, clientSecret, scope, callbackPort, and redirectUri. Only clientId is required to clear the needs_client_registration error. The remaining four exist for providers that demand a confidential client, a specific scope, or a fixed callback. clientId is the value the MCP server provider gave you when you registered the OAuth client by hand. clientSecret goes alongside it when the provider issued one. scope pins the permission list the authorization server should grant. callbackPort and redirectUri matter when the provider only accepts a pre-registered redirect, which is common: the redirect you registered with the provider and the redirectUri in your Atlas config have to agree exactly, or consent will be rejected. Set only what the provider actually requires. Adding fields the provider does not expect can fail the login just as surely as leaving out the clientId. ## needs_client_registration versus needs_auth in Atlas Atlas distinguishes needs_client_registration from needs_auth by inspecting the OAuth error message for 2 markers, "registration" and "client_id". When either appears, connectRemote classifies the failure as a registration problem. Otherwise an UnauthorizedError becomes a plain needs_auth prompt that `atlas mcp auth ` resolves on its own. Running `atlas mcp` and reading the status row is the fastest way to know which fix applies. A server sitting in needs_auth needs nothing more than the OAuth flow: run `atlas mcp auth ` and complete the browser consent. A server sitting in needs_client_registration cannot start that flow at all, because the MCP server provider refused to register a client dynamically. Re-running the auth command against it will keep failing until `oauth: { clientId: "..." }` is present in config and Atlas has been restarted. Two different states, two different fixes, one command to tell them apart. ## FAQ ### How do I fix "Server does not support dynamic client registration" in Atlas? Register an OAuth client with the MCP server provider yourself, set `oauth: { clientId: "..." }` on that server entry in your Atlas config, restart Atlas so McpOAuthProvider is constructed with the clientId, then re-run `atlas mcp auth `. ### What does needs_client_registration mean in Atlas? needs_client_registration means the OAuth error from the MCP server contained "registration" or "client_id", so connectRemote classified it as a registration failure rather than a plain auth prompt and stopped trying further transports. ### Where do I set clientId for an MCP server in Atlas? On the server entry in your Atlas config, inside an oauth block: `oauth: { clientId: "..." }`. The same block accepts optional clientSecret, scope, callbackPort, and redirectUri. ### Do I need to restart Atlas after adding an MCP clientId? Yes. The restart is what makes Atlas construct McpOAuthProvider with the clientId you supplied. Re-running `atlas mcp auth ` without restarting reuses the old provider and reproduces the registration failure. ### Does Atlas need an OAuth clientSecret for MCP servers? Only when the MCP server provider issued one. The Atlas oauth block accepts clientSecret alongside clientId, plus optional scope, callbackPort, and redirectUri. Set only what the provider actually requires. ### Why can't Atlas register the OAuth client automatically? Because the MCP server itself does not support dynamic client registration. The error message says so directly: "Server does not support dynamic client registration. Please provide clientId in config." Registration has to happen in the provider's own console. ### My Atlas MCP server moved from needs_client_registration to needs_auth, is that broken? No, that is progress. Registration is solved and only the login remains. Run `atlas mcp auth `, complete the browser consent step, and the status should reach connected. --- Canonical HTML: https://runatlas.sh/resources/troubleshooting/mcp-dynamic-client-registration-unsupported Source of truth: aeo_pages row `/resources/troubleshooting/mcp-dynamic-client-registration-unsupported` (segment: Troubleshooting) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.