Running `atlas mcp auth <name>` errors with "MCP server <name> has OAuth explicitly disabled" or "MCP server <name> is not a remote server" because the Atlas auth command only works for remote servers with OAuth enabled: it rejects local (stdio) servers outright and rejects remote servers configured with oauth: false. Fix it by setting `type` to "remote" on that entry, removing `oauth: false` if the server really needs an OAuth login, or dropping the OAuth flow and setting `headers` for a static token.
Why atlas mcp auth says OAuth is explicitly disabled
The Atlas auth command rejects a server with "MCP server <name> has OAuth explicitly disabled" when that entry carries oauth: false. `atlas mcp auth` works for exactly 1 kind of server, a remote one with OAuth enabled, so an explicit oauth: false is read as your instruction not to run an OAuth flow.
The error is a config assertion, not a bug. Setting `oauth: false` on an Atlas MCP server entry is a deliberate statement that the server does not use OAuth, and the auth command honours it rather than trying anyway. Two situations produce the error. Either the flag is stale, left behind from an earlier setup when the server genuinely did not need a login, or the server never needed OAuth in the first place and you are reaching for the wrong command. Decide which before editing anything, because the two situations have different fixes.
Why atlas mcp auth says the server is not a remote server
Atlas errors with "MCP server <name> is not a remote server" when the entry's `type` is "local" rather than "remote". The `atlas mcp auth` command rejects local stdio servers outright, because a stdio process launched from a `command` array has 0 OAuth authorization endpoints to redirect a browser to.
Local MCP servers in Atlas run as a child process and speak stdio. There is no HTTP origin, no authorization server, and nothing for an OAuth consent screen to point at, which is exactly why the Atlas auth command refuses to start a flow. If the server you are trying to authenticate really is remote, then `type` is simply set wrong, and correcting it to "remote" alongside a valid `url` clears the error. If the server really is local, then a local server that needs credentials should receive them through its own environment, not through `atlas mcp auth`.
How to fix atlas mcp auth rejecting the server
Fix the Atlas auth rejection in 4 steps: check that `type` on the server entry is "remote" and not "local", remove `oauth: false` if the server genuinely needs an OAuth login, use `headers` instead if the server takes a static token, then restart Atlas and re-run `atlas mcp auth <name>`.
Work through the entry top to bottom. `type` first: only a remote server can run the Atlas OAuth flow at all. Then the oauth flag: `oauth: false` is an explicit opt out, and removing it is what lets `atlas mcp auth <name>` proceed. Then ask whether OAuth is even the right mechanism, because many remote MCP servers authenticate with a bearer token rather than an OAuth handshake, and for those the correct Atlas config is `headers` on the entry. The restart matters. Atlas reads these config decisions when it builds the server, so re-running the auth command without restarting reuses the old shape.
When to use headers instead of OAuth for an Atlas MCP server
Use `headers` on an Atlas MCP server entry when the remote server authenticates with a static token, and drop the OAuth flow entirely. A static token needs 0 browser steps and 0 callbacks, so running `atlas mcp auth <name>` against a token-authenticated server is simply the wrong command.
A static token is the simpler and more common authentication shape for a remote MCP server, and Atlas supports it directly through `headers` on the server entry. No browser, no callback, no PKCE, no pending flow. Configure the header the server expects, restart Atlas, and check `atlas mcp` for a connected status row. This is also the honest answer for many users who arrive at the OAuth-disabled error: they do not need OAuth, they need a header. Every tool call the connected server exposes is still permission-gated against allow, ask, and deny rules before it runs.
How to verify the MCP auth fix worked in Atlas
Verify the Atlas fix in 2 steps: restart Atlas, then re-run `atlas mcp auth <name>`. A correctly configured remote server with OAuth enabled now starts the browser flow instead of erroring, and a server using `headers` for a static token should reach connected without any auth command at all.
The restart is not optional in Atlas, because the server entry is read when the MCP layer builds the server, and a running process is still holding the old `type` and the old oauth flag. After the restart, `atlas mcp` gives you the status row. connected means you are done. needs_auth means the OAuth path is now available and the login itself is the remaining step, which is real progress from an outright rejection. A repeat of "has OAuth explicitly disabled" means `oauth: false` is still on the entry somewhere in your config.
How to fix it
- 01Check the server entry: `type` must be "remote", not "local".
- 02Remove `oauth: false` from that entry if the server actually needs an OAuth login.
- 03For a remote server that authenticates with a static token, drop the OAuth flow and set `headers` on the entry instead.
- 04Restart Atlas and re-run `atlas mcp auth <name>`.
Frequently asked questions
- Why does atlas mcp auth say OAuth is explicitly disabled?
- Because that server entry carries `oauth: false`. The Atlas auth command only works for remote servers with OAuth enabled, so it treats the flag as an instruction not to run an OAuth flow. Remove `oauth: false` if the server actually needs a login.
- Why does Atlas say my MCP server is not a remote server?
- Because the entry's `type` is "local". `atlas mcp auth` rejects local stdio servers outright, since a process launched from a `command` array has no OAuth authorization endpoint. Set `type` to "remote" if the server really is remote.
- Can I authenticate a local stdio MCP server in Atlas?
- Not with `atlas mcp auth`. The Atlas auth command rejects local servers. A local MCP server that needs credentials should receive them through its own environment rather than through an OAuth flow.
- How do I use a static token with an MCP server in Atlas?
- Drop the OAuth flow and set `headers` on that remote server entry in your Atlas config. No browser step is involved. Restart Atlas and confirm the server reaches connected in `atlas mcp`.
- Do I need to restart Atlas after changing type or oauth on an MCP entry?
- Yes. Atlas reads the server entry when it builds the MCP server, so re-running `atlas mcp auth <name>` without restarting reuses the old `type` and the old oauth flag.
- What does oauth: false do in an Atlas MCP config?
- `oauth: false` explicitly disables the OAuth flow for that MCP server. The `atlas mcp auth` command then rejects the server rather than starting a login, since the flag states the server does not use OAuth.
- My Atlas MCP server moved from rejected to needs_auth, what now?
- That is progress. The OAuth path is now available and only the login remains. Run `atlas mcp auth <name>`, complete the browser consent step, then check `atlas mcp` for a connected status row.
Try SeaShell in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install SeaShellRelated guides
Atlas with Qwen3 14B in 2026: A Developer's Guide
Evaluate Atlas with Qwen3 14B for your coding agent in 2026. This 14B model offers reasoning capabilities, a 128K token context, and reliable tool use at $0.35/Mtok input.
Atlas with GPT-5 Mini in 2026
In 2026, Atlas developers can leverage GPT-5 Mini for efficient coding tasks. This model offers a 400K token context window and reasoning at $0.25/Mtok input, making it a cost-effective choice for many Atlas workflows.
Atlas with OpenAI o4-mini in 2026
In 2026, drive Atlas with OpenAI o4-mini for cost-effective reasoning. Get a 200K context window at $1.10/Mtok input, ideal for subagents needing to think.
Atlas with Qwen3.7 Max in 2026
Explore Atlas with Qwen3.7 Max, Alibaba's 2026 flagship model. Leverage its 1M token context window and competitive pricing for advanced terminal-native AI coding tasks, offering a powerful and cost-effective solution.
Atlas vs Qodo: Choosing Your AI Coding Agent in 2026
Compare Atlas, the terminal-native AI coding agent, with Qodo 2.0, the multi-agent PR reviewer, for developers in 2026. Evaluate features, pricing, and workflow.
Atlas with Vercel AI Gateway in 2026
Explore Atlas with Vercel AI Gateway in 2026. Access over 310 models, including Grok 4.20 Reasoning with a 2,000,000 token context window, and cost-effective Nemotron 3 Super 120B A12B, all managed via a single API key.
Atlas with Llama 3.1 405B in 2026
Explore Atlas with Llama 3.1 405B, Meta's 405 billion parameter open-weights model. Discover its 128,000 token context window and self-hosting benefits for developers in 2026.
Atlas with GPT-OSS 20B (local via Ollama) in 2026
Evaluate Atlas with GPT-OSS 20B (local via Ollama) for your coding agent in 2026. This 20B open-weight model offers genuine reasoning and a 131,072 token context window, running on a 16GB GPU.