# Atlas: MCP server has OAuth explicitly disabled > Set `type` to "remote" on that server entry, remove `oauth: false`, or use `headers` for a static token, then restart Atlas and re-run `atlas mcp auth `. Running `atlas mcp auth ` errors with "MCP server has OAuth explicitly disabled" or "MCP server 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. ## Symptom Running `atlas mcp auth ` errors with: MCP server has OAuth explicitly disabled, or MCP server is not a remote server. ## Cause The 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 1. Check the server entry: `type` must be "remote", not "local". 2. Remove `oauth: false` from that entry if the server actually needs an OAuth login. 3. For a remote server that authenticates with a static token, drop the OAuth flow and set `headers` on the entry instead. 4. Restart Atlas and re-run `atlas mcp auth `. ## Why atlas mcp auth says OAuth is explicitly disabled The Atlas auth command rejects a server with "MCP server 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 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 `. 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 ` 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 ` 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 `. 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. ## FAQ ### 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 ` 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 `, complete the browser consent step, then check `atlas mcp` for a connected status row. --- Canonical HTML: https://runatlas.sh/resources/troubleshooting/mcp-oauth-explicitly-disabled Source of truth: aeo_pages row `/resources/troubleshooting/mcp-oauth-explicitly-disabled` (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.