> ## 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.
# Remote MCP Servers
> What remote MCP servers are and how MCP Manager connects to them over HTTPS — whether a SaaS vendor's endpoint or your own self-hosted server — the three authentication methods (standard OAuth with dynamic client registration, OAuth with client pre-registration, and custom-header tokens), how to choose between them, and how credentials are secured.
A **remote MCP server** is any MCP server that is **already running at a URL**, which **MCP Manager** reaches over standard HTTPS. That includes a SaaS vendor's MCP endpoint — Atlassian, GitHub, HubSpot — and **your own self-hosted server** exposed on the web. You provide a URL, authenticate, and connect; there is nothing to install or provision. It is the simplest server type to set up.
The deciding question between Remote and [Managed](/mcp-gateway-concepts/mcp-servers/managed) is **how many instances of the server you need — not who hosts it**. A self-hosted server at a single URL is a remote server. Step up to Managed when you run the same server as **several instances** — per user, team, customer, or environment (staging and production deployments at different URLs are the classic case) — or when you want MCP Manager to generate the command that launches a not-yet-deployed server in your infrastructure.
Adding a remote server and creating its identities is gated by the **Basic server management** capability. If you don't see the **Servers** section
or an option to add a server, your role doesn't have that capability — ask a workspace administrator to grant it. See the [capabilities
reference](/deployment/rbac-and-roles/capabilities).
## Why use a remote server
A remote server is the right choice when the MCP server is already reachable at a URL and you just want to connect to it. For a SaaS product, the vendor runs and maintains the server; for your own self-hosted server, you run it and expose its URL. Either way, MCP Manager connects without any infrastructure work on its side.
Common use cases are SaaS applications that offer MCP endpoints — project-management tools, CRMs, code repositories, documentation platforms — and your own internal servers that are already deployed behind a public URL.
Keeping a self-hosted remote server private: MCP Manager connects from a single **static IP address**, shown at [Security → IP
addresses](https://app.mcpmanager.ai/settings/security/ip-addresses). Allowlist that IP on your server's firewall so only MCP Manager can reach it.
See [Lock your server to MCP Manager](/mcp-gateway-concepts/mcp-servers/managed#lock-your-server-to-mcp-manager-defense-in-depth).
## How a remote request flows through MCP Manager
When an AI app calls a remote server, the request goes to MCP Manager first. MCP Manager authenticates the caller, applies your gateway rules, logs the call, attaches the right credentials for the target server, and forwards the request over HTTPS. The response returns the same way, so every remote call is inspected and logged.
```mermaid theme={null}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','lineColor':'#6a6b76','primaryColor':'#e0e2e8','primaryTextColor':'#12141d','primaryBorderColor':'#6a6b76','edgeLabelBackground':'#ffffff','textColor':'#12141d'}}}%%
flowchart LR
Client["🤖
AI app or agent"] --> Gateway["🛡️
MCP Manager gateway
authenticate · inspect · log"]
Gateway -->|"HTTPS + OAuth token or header"| Remote["🖥️
Remote MCP server
reachable at a URL (SaaS or self-hosted)"]
classDef gateway fill:#0086ff,color:#ffffff,stroke:#062b4c,stroke-width:2px;
classDef client fill:#80cbc4,color:#062b4c,stroke:#00796b,stroke-width:1.5px;
classDef server fill:#aed8ff,color:#062b4c,stroke:#0b4880,stroke-width:1.5px;
class Gateway gateway;
class Client client;
class Remote server;
```
## Authentication methods for remote servers
MCP Manager supports three ways to authenticate with a remote server. When you add a server by URL, MCP Manager first tries **standard OAuth automatically**; if the server can't be connected that way, you choose **OAuth pre-registration** or **Token / Headers**. All three result in MCP Manager holding the credentials and attaching them to each request it makes on your behalf. Each method is detailed under [Authentication & Identity](/security/authentication-and-identity).
### Standard OAuth with dynamic client registration
Some remote servers support OAuth with **dynamic client registration**, the most seamless option. You provide the server's URL and MCP Manager handles the entire flow automatically — discovering the server's OAuth metadata, registering itself as a client, redirecting you to authorize, and managing token refresh. No app creation is required. Atlassian's MCP server works this way. See [Standard OAuth with dynamic client registration](/security/authentication-and-identity#standard-oauth-with-dynamic-client-registration).
### OAuth with client pre-registration
Some servers require you to create an application in their developer portal first. You register an app with the provider, then give MCP Manager the resulting **Client ID** and **Client Secret**, and enter MCP Manager's callback URL in the provider's app settings:
```text Callback URL theme={null}
https://app.mcpmanager.ai/api/v1/mcpm/inbound/oauth/callback
```
Once configured, token exchange and refresh work just like the standard method. Asana, HubSpot, and Slack are common examples. See [OAuth with client pre-registration](/security/authentication-and-identity#oauth-with-client-pre-registration).
### Custom headers with a token
When a remote server uses token-based authentication — an API key or bearer token — rather than OAuth, you provide the credentials directly as **custom headers**. MCP Manager attaches them to every request it sends to that server. You enter the header name (for example, `Authorization`) and value (for example, `Bearer your-token-here`) during setup. See [Token in custom headers](/security/authentication-and-identity#token-in-custom-headers).
## Choosing an authentication method
MCP Manager tries **standard OAuth automatically** first, so most servers connect with nothing to decide. When automatic OAuth doesn't connect — or a server offers more than one method and you want to pick deliberately — see [Choosing a remote server's authentication method](/mcp-gateway-concepts/mcp-servers/choosing-remote-auth). It covers the token-versus-OAuth trade-offs, the three reasons automatic OAuth fails and the pre-registration fallback, and when to run the server as a [workstation server](/mcp-gateway-concepts/mcp-servers/workstation) instead.
## How your credentials are secured
All tokens and secrets you provide — and any OAuth tokens MCP Manager obtains for you — are encrypted using **AES-256-GCM** and stored in MCP Manager's secure key vault. Your credentials are never exposed in logs and are not accessible to other users. MCP Manager also handles OAuth token refresh automatically, so connections keep working without you re-authenticating each time.
## Identities for remote servers
Every credential you set up for a remote server is stored as an **identity** — a set of access credentials scoped to that one server. An identity is **Private** by default (only you can use it), or you can make it **Global** so others in your organization can use a shared service account. Administrators can also require each user to bring their own identity, or share a single identity across everyone on a gateway — the per-server choice covered in [Identity Controls](/features/identity-controls). See [the identities section of the overview](/mcp-gateway-concepts/mcp-servers/overview#how-identities-control-access-across-all-three-types) for the full model.
## Pros and cons
* **Pros:** fastest and easiest type to deploy; one server can serve many clients; no local install or infrastructure; standard web authentication (OAuth, HTTPS); low resource use.
* **Cons:** the server must already be running at a URL; for a SaaS server you depend on the vendor for uptime and data security; can't run per-user, per-group, or per-environment instances (use [Managed](/mcp-gateway-concepts/mcp-servers/managed) for that); not an option when a tool needs local files (use [Workstation](/mcp-gateway-concepts/mcp-servers/workstation)).
## Further reading
Run a server in your own infrastructure from a generated command, dedicated or shared.
Govern a local-machine server through an encrypted tunnel.
Deep reference on each of the three authentication methods.
Which method to use, and what to do when automatic OAuth fails.