Skip to main content
MCP Manager connects to any standards-compliant MCP server. Most connect in under a minute: paste the server’s URL, approve an OAuth screen, and you’re done. Some products ask for more before they’ll accept a connection — creating an application, generating a scoped key, or having an administrator enable MCP access for your organization. That work is required by the product itself: each vendor decides how much of its API to open up and how MCP fits the permission model it already has, and many take a deliberately conservative approach. The guides here gather what we’ve learned connecting those servers into one place, so you don’t have to assemble it from scratch. Each product’s own documentation is authoritative. It sits closer to the source and may be more current than ours, which we keep up to date as best we can. When a specific server is hard to connect because of how that product works, that product’s own support team is the fastest path to an answer.
Adding a server is gated by the Basic server management capability. If you don’t see the Servers section or an option to add a server, ask a workspace administrator to grant it. See the capabilities reference.

What “works with MCP Manager” means

MCP Manager connects to remote MCP servers — servers that are already running at an https:// URL. If you can paste a URL, MCP Manager can reach it. The whole directory is built around that one requirement. Not every server you’ll find online is remote. Many are local servers that run on your machine through a command (npx ..., uvx ..., a Docker image) and speak over stdio rather than a URL. Those don’t have a public URL to paste — but you can still govern them through MCP Manager:
  • A local/stdio server can run on your machine through an encrypted tunnel as a Workstation server.
  • A server you want MCP Manager to launch and host for you (dedicated or shared) is a Managed server.
So when you’re browsing for servers, the question to ask is always: does this server publish a URL? If yes, it’s a remote server and the rest of this section applies.

Finding a server’s URL

Vendors don’t always advertise their MCP endpoint on the product’s marketing page, and a non-Claude/Cursor client often won’t auto-discover it. Public listings are the fastest way to find a working URL. Two good ones:

PulseMCP — remote servers

A large, frequently updated index. The link is pre-filtered to remote servers — the ones that expose a URL.

mcpservers.org — remote

A curated list focused specifically on remote MCP servers and their endpoints.
When you open a listing:
1

Filter for remote / hosted servers

Use the listing’s remote (sometimes called hosted or URL-based) filter. This drops the local/stdio entries that have no URL to paste. The PulseMCP link above is already filtered this way.
2

Copy the server's URL

Open the server you want and copy its MCP endpoint — it usually ends in /mcp or /sse (for example, https://mcp.example.com/mcp). That URL is the only thing MCP Manager needs to begin.
3

Add it in MCP Manager

On the Servers page, add a server, paste the URL, and click Continue. That’s what triggers MCP Manager to work out how the server authenticates.
A vendor’s docs may list several URLs for different regions or data centers (Datadog is a good example). Make sure you copy the one for your account’s region — a region mismatch is the single most common reason a paste-and-connect fails. The per-server guides below call this out where it matters.

How MCP Manager detects the authentication type

You don’t have to know in advance whether a server uses OAuth, a token, or no auth at all. When you enter a URL and click Continue, MCP Manager runs a discovery call against the server and decides how to connect — only asking you for something when the server genuinely requires it. Under the hood, discovery looks at two things: whether the server publishes OAuth metadata (the standard “well-known” authorization documents), and how the server responds to an initialize request. From those signals it lands on one of four outcomes. The four outcomes map exactly to the three authentication methods (plus open servers that need nothing):
  • Standard OAuth with dynamic client registration — the most seamless case. MCP Manager registers itself as a client, redirects you to authorize, and manages token refresh. You bring nothing but your approval. Example: Atlassian.
  • OAuth with client pre-registration — the server speaks OAuth but won’t register clients on the fly (or only allows an allowlist of well-known clients). You create an app in the provider’s portal and give MCP Manager its Client ID and Client Secret. Examples: Asana, HubSpot, Slack.
  • Token in custom headers — the server uses an API key or bearer token instead of OAuth. You paste the header name and value (for example, Authorization: Bearer …). Example: Datadog, via API + application keys.
  • Open serverinitialize succeeds with no credentials. MCP Manager connects directly; you only give it a name.
Running your own MCP server and the OAuth step fails even though the connection itself works — often a “Client Not Registered” error that comes and goes? That’s almost always a server-side dynamic-client-registration issue, not MCP Manager. See Debugging Your Self-Hosted Server’s OAuth.
When a server’s intent is ambiguous — discovery can’t tell whether it wants pre-registration or a token, for instance — MCP Manager shows you a short choice rather than guessing. Picking the right option is what the per-server guides help with.
Whatever the method, the result is the same: MCP Manager holds the credential, encrypted with AES-256-GCM, and attaches it to each request on your behalf — nothing lands in a config file on a laptop. See How your credentials are secured.

Connection guides

Most remote servers connect with nothing more than a pasted URL and an OAuth approval. The guides here cover the ones with extra prerequisites — keys to generate, regions to match, or scopes to choose. Each follows the same shape: what to bring, the steps, and the gotchas to watch for.

Atlassian Rovo

Connect Atlassian’s Rovo MCP server (Jira, Confluence, Compass) with a single OAuth approval — no keys to generate.

Datadog

Connect Datadog’s MCP server with a service account, application key, and the region-specific URL.

HubSpot

Connect HubSpot’s MCP server with an MCP auth app’s Client ID and Client Secret.

Salesforce

Connect Salesforce’s Hosted MCP Servers with an External Client App’s Consumer Key and Secret.

Slack

Connect Slack’s MCP server with a Slack app’s Client ID and Client Secret.

Further reading

Remote MCP Servers

The concept page — what remote servers are and the three authentication methods in depth.

Authentication & Identity

How discovery maps to each method, and how credentials are stored and refreshed.

Workstation MCP Servers

For local/stdio servers that have no URL — govern them through an encrypted tunnel.

Connect your AI client

Once a server is on a gateway, point Claude, Cursor, or VS Code at it.