Skip to main content

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.

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. A self-hosted server only needs to be a Managed server instead when you want MCP Manager to give you a command to launch and run it in your own infrastructure, or to run different instances for different users or groups. If it already runs at a URL and you don’t need either of those, add it as a remote server.
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.

​
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. Allowlist that IP on your server’s firewall so only MCP Manager can reach it. See Lock your server to MCP Manager.

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

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

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

​
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:
Callback URL
https://mcp.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.

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

​
How to choose an authentication method

Some servers offer more than one method (GitHub, for instance, accepts both OAuth and header tokens), and some don’t make it obvious how a non-Claude/Cursor client should connect. Use these guidelines:
  • Token authentication is often more customizable — scope definition is usually part of creating the token — and tends to be more stable.
  • OAuth is usually easier for non-technical users: you accept a consent screen in a pop-up instead of generating a token deep in a developer-settings menu.
  • If automatic OAuth doesn’t work, fall back to client pre-registration (Client ID and Secret). This happens for one of three reasons: the server requires clients to be registered ahead of time (Slack is a good example); the server doesn’t support dynamic client registration; or the server allows only an allowlist of well-known clients (Claude, Cursor, Goose) and you must register MCP Manager as a client app.
If a server allows no custom clients at all, it typically still allows localhost — in which case you can run it locally through MCP Manager as a workstation server.

​
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. See the identities section of the overview 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 or per-group instances (use Managed for that); not an option when a tool needs local files (use Workstation).

​
Further reading

Managed MCP Servers

Run a server in your own infrastructure from a generated command, dedicated or shared.

Workstation MCP Servers

Govern a local-machine server through an encrypted tunnel.

Authentication & Identity

Deep reference on each of the three authentication methods.