> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Find & Connect MCP Servers

> How to find remote MCP servers that work with MCP Manager — using public listings like PulseMCP and mcpservers.org — and how MCP Manager detects a server's authentication type when you submit its URL, so you know what (if anything) you'll need to bring.

**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.

<Note>
  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](/deployment/rbac-and-roles/capabilities).
</Note>

## 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](/mcp-gateway-concepts/mcp-servers/workstation).
* A server you want MCP Manager to launch and host for you (dedicated or shared) is a [Managed server](/mcp-gateway-concepts/mcp-servers/managed).

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:

<CardGroup cols={2}>
  <Card title="PulseMCP — remote servers" icon="bolt" href="https://www.pulsemcp.com/servers?other%5B%5D=remote">
    A large, frequently updated index. The link is pre-filtered to **remote** servers — the ones that expose a URL.
  </Card>

  <Card title="mcpservers.org — remote" icon="globe" href="https://mcpservers.org/remote-mcp-servers">
    A curated list focused specifically on remote MCP servers and their endpoints.
  </Card>
</CardGroup>

When you open a listing:

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Add it in MCP Manager">
    On the [Servers](https://app.mcpmanager.ai/settings/servers) page, add a server, paste the URL, and click **Continue**. That's what triggers MCP
    Manager to work out how the server authenticates.
  </Step>
</Steps>

<Tip>
  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.
</Tip>

## 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.

```mermaid theme={null}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','lineColor':'#6a6b76','primaryColor':'#e0e2e8','primaryTextColor':'#12141d','primaryBorderColor':'#6a6b76','edgeLabelBackground':'#ffffff','textColor':'#12141d'}}}%%
flowchart TD
  U["📎<br/>You enter the URL and click Continue"] --> D["🔎<br/>MCP Manager runs a discovery call<br/>checks OAuth metadata + sends initialize"]
  D --> Q{"What did<br/>discovery find?"}
  Q -->|"OAuth + dynamic<br/>client registration"| O1["Standard OAuth<br/>fully automatic — you just approve"]
  Q -->|"OAuth, no dynamic<br/>registration"| O2["OAuth pre-registration<br/>you supply Client ID + Secret"]
  Q -->|"Expects a token<br/>or API key"| O3["Token in headers<br/>you paste header name + value"]
  Q -->|"No authentication<br/>required"| O4["Open server<br/>connects directly — just name it"]
  O1 --> C["✅<br/>Connected"]
  O2 --> C
  O3 --> C
  O4 --> C
  classDef trust fill:#2fedb4,color:#062b4c,stroke:#059669,stroke-width:1.5px;
  classDef step fill:#aed8ff,color:#062b4c,stroke:#0b4880,stroke-width:1.5px;
  class C trust;
  class O1,O2,O3,O4 step;
```

The four outcomes map exactly to the [three authentication methods](/security/authentication-and-identity#how-mcp-manager-authenticates-to-a-server) (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 server** — `initialize` succeeds with no credentials. MCP Manager connects directly; you only give it a name.

<Tip>
  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](/build-your-own-mcp-server/debugging-self-hosted-oauth).
</Tip>

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.

<Tip>
  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](/mcp-gateway-concepts/mcp-servers/remote#how-your-credentials-are-secured).
</Tip>

## 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.

<Tip>
  Connecting a server for the first time — or troubleshooting one that won't connect? Validate it in isolation first with an [open MCP
  inspector](/advanced/validate-mcp-servers). Confirm connectivity and correctness there, so your time in MCP Manager goes to governance instead of
  diagnosing connections.
</Tip>

<CardGroup cols={2}>
  <Card title="Atlassian Rovo" icon="atlassian" href="/mcp-server-guides/atlassian">
    Connect Atlassian's Rovo MCP server (Jira, Confluence, Compass) with a single OAuth approval — no keys to generate.
  </Card>

  <Card title="AWS" icon="aws" href="/mcp-server-guides/aws">
    Connect the AWS MCP Server — IAM SigV4, not OAuth — by running AWS's proxy locally as a workstation server.
  </Card>

  <Card title="Datadog" icon="dog" href="/mcp-server-guides/datadog">
    Connect Datadog's MCP server with a service account, application key, and the region-specific URL.
  </Card>

  <Card title="HubSpot" icon="hubspot" href="/mcp-server-guides/hubspot">
    Connect HubSpot's MCP server with an MCP auth app's Client ID and Client Secret.
  </Card>

  <Card title="Salesforce" icon="salesforce" href="/mcp-server-guides/salesforce">
    Connect Salesforce's Hosted MCP Servers with an External Client App's Consumer Key and Secret.
  </Card>

  <Card title="Slack" icon="slack" href="/mcp-server-guides/slack">
    Connect Slack's MCP server with a Slack app's Client ID and Client Secret.
  </Card>
</CardGroup>

## Further reading

<CardGroup cols={2}>
  <Card title="Remote MCP Servers" icon="cloud" href="/mcp-gateway-concepts/mcp-servers/remote">
    The concept page — what remote servers are and the three authentication methods in depth.
  </Card>

  <Card title="Authentication & Identity" icon="fingerprint" href="/security/authentication-and-identity">
    How discovery maps to each method, and how credentials are stored and refreshed.
  </Card>

  <Card title="Workstation MCP Servers" icon="laptop" href="/mcp-gateway-concepts/mcp-servers/workstation">
    For local/stdio servers that have no URL — govern them through an encrypted tunnel.
  </Card>

  <Card title="Connect your AI client" icon="plug" href="/tutorials/connect-your-ai-client">
    Once a server is on a gateway, point Claude, Cursor, or VS Code at it.
  </Card>
</CardGroup>