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). That works when automatic OAuth fails for one of these 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.

In either 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

Some vendors accept only the clients they have approved, such as Claude and Cursor, and refuse everyone else. Pre-registration does not help here. An app you create in the vendor’s developer portal is still not an approved client, so it cannot get the scope the MCP server requires. Figma works this way: its remote server rejects gateways with Invalid scope: mcp:connect. These vendors often still ship a local server, for example inside their desktop app. You can connect it to MCP Manager as a workstation server, which reaches it over an encrypted tunnel instead of a public URL. Connect Figma walks through this with the Figma desktop app.

​

Further reading