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 <name>`.
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 <name>`.
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 <name>` 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 <name>` 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 <name>` 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 <name>` 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.
How to fix it
- 01Register an OAuth client with the MCP server provider yourself and note the client id (and secret if required).
- 02Set `oauth: { clientId: "..." }` on that server entry in your Atlas config, alongside optional clientSecret, scope, callbackPort, and redirectUri.
- 03Restart Atlas so McpOAuthProvider is constructed with the supplied clientId.
- 04Re-run `atlas mcp auth <name>` and confirm the status becomes connected.
Frequently asked questions
- 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 <name>`.
- 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 <name>` 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 <name>`, complete the browser consent step, and the status should reach connected.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas for TensorFlow: Terminal-Native AI Coding for Keras 3 and tf.data in 2026
Atlas is a terminal-native AI coding agent for TensorFlow and Keras 3 in 2026, where tf.function graph tracing and tf.data pipelines are what make training fast.
Atlas vs Magic.dev: Terminal AI Coding Agents in 2026
Compare Atlas, the terminal-native AI coding agent with permission-gated tools and diff review, against Magic.dev's research claims of 100 million token context models in 2026.
Atlas with GPT-5.4 Pro: One Shot Hard Problems in 2026
GPT-5.4 Pro is the max reasoning tier at $30 per Mtok input, $180 per Mtok output on a 1,050,000 token window. Why Atlas users switch to it instead of pinning it.
Atlas for Fiber in 2026
Atlas is a terminal-native AI coding agent for Fiber in 2026. It knows fasthttp reuses buffers, tests handlers with app.Test(), and diffs every edit first.
Atlas with Ollama Cloud in 2026: Hosted Ollama Tags for a Terminal Coding Agent
How to run Atlas on Ollama Cloud in 2026: same local tags like qwen3-coder:480b on hosted GPUs, up to 1,048,576 tokens of context, no published per-token price.
Atlas for Rust in 2026
Adopt Atlas, the terminal-native AI coding agent, for Rust development in 2026. Tackle borrow checker errors and clippy lints with Atlas's secure, approval-gated assistance.
Atlas for Godot: Terminal-Native AI Coding for GDScript and the Node Tree in 2026
Atlas is a terminal-native AI coding agent for Godot in 2026, working across GDScript, the node tree, and signals, where scene structure is half the program.
Atlas with Amazon Nova 2 Lite: Cost, Context, and Setup in 2026
Amazon Nova 2 Lite drives Atlas from inside your AWS account at $0.33 / $2.75 per Mtok with a 128K context. Setup, real tradeoffs, and when to pick another model.