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 Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas with Qwen3 14B: The Middle Dense Tier Worth Pinning in 2026
Qwen3 14B in Atlas for 2026: reasoning-enabled dense 14B at $0.35 per Mtok input and $1.40 per Mtok output, 128K tokens (131,072), roughly 9 GB quantized.
Atlas with GPT-5 Mini: Full 400K Context at One Fifth the Price in 2026
GPT-5 Mini in Atlas: $0.25 per Mtok input and $2 per Mtok output, 5x cheaper than GPT-5 on both sides, with no reduction to the 400K context window.
Atlas with OpenAI o4-mini (2026): Cheap Reasoning for Parallel Subagents
OpenAI o4-mini drives Atlas at $1.10 per Mtok input and $4.40 per Mtok output on a 200K context. A strict upgrade over o3-mini at identical price, with real tradeoffs.
Atlas with Qwen3.7 Max: Alibaba's May 2026 Frontier Tier at $2.50 / $7.50
Qwen3.7 Max in Atlas: Alibaba's May 2026 flagship, a 1M context model at $2.50 / $7.50 per Mtok, or $1.25 / $3.75 through Together. Setup with DASHSCOPE_API_KEY.
Atlas vs Qodo: Choosing Your AI Coding Agent in 2026
Comparing 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: 310 Models Behind One AI_GATEWAY_API_KEY
Atlas with Vercel AI Gateway in 2026: roughly 310 models, Grok 4.20 Reasoning at a 2,000,000 token context for $1.25/$2.50 per Mtok, one AI_GATEWAY_API_KEY.
Atlas with Llama 3.1 405B: The 243GB Landmark in 2026
Llama 3.1 405B in Atlas for 2026: 405 billion openly released parameters, a 128,000 token window, Free (self-hosted), and a 243GB download that decides everything.
Atlas with GPT-OSS 20B (local via Ollama): Local Reasoning on a 16GB Card in 2026
GPT-OSS 20B is OpenAI's open-weight reasoning model: 131,072 token context, runs on a single 16GB GPU, free self-hosted, or $0.075 / $0.30 per Mtok via Groq.