Choosing a Remote Server's Authentication Method

When you add a remote MCP server by URL, MCP Manager first tries standard OAuth automatically. If that succeeds you’re done — there’s no decision to make. You only choose a method when automatic OAuth doesn’t connect, or when a server offers more than one way in and you want to pick deliberately. This page is that decision: which of the three methods to use, and what to do when the automatic path fails. For the mechanics of each method — what MCP Manager does on the wire, where credentials are stored, and how token refresh works — see Authentication & Identity. This page is about choosing; that page is the reference.

​

The three methods at a glance

All three end the same way: MCP Manager holds the credentials and attaches them to every request it makes on your behalf, encrypted with AES-256-GCM.

​

Token versus OAuth, when you have the choice

Some servers accept more than one method — GitHub, for instance, takes both OAuth and header tokens — and some don’t make it obvious how a non-Claude/Cursor client should connect. When the choice is yours:

• Token authentication is often more customizable — scope definition is usually part of creating the token — and tends to be more stable over time.
• OAuth is usually easier for non-technical users: you approve a consent screen in a pop-up instead of generating a token deep in a developer-settings menu.

​

When automatic OAuth doesn’t work

If MCP Manager can’t connect a server with standard OAuth, fall back to client pre-registration (Client ID and Secret). Automatic OAuth fails for one of three reasons:

• The server requires clients to be registered ahead of time. Slack is a good example — it only accepts a confidential OAuth client you registered yourself.
• The server doesn’t support dynamic client registration at all, so there is no way for MCP Manager to register itself on the fly.
• The server allows only an allowlist of well-known clients (Claude, Cursor, Goose), and you must register MCP Manager as a client app to be on that list.

In each case, create an app in the provider’s developer portal, then give MCP Manager the resulting Client ID and Client Secret and add its callback URL to the provider — see OAuth with client pre-registration. The per-vendor server guides walk through this for specific providers.

​

When a server allows no custom clients at all

If a server permits no custom clients of any kind, it typically still allows localhost. In that case you can run it locally through MCP Manager as a workstation server, which connects over an encrypted tunnel instead of a public URL.

​

Further reading