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.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
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.
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. 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 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. 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, per-group, or per-environment 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.
Choosing remote auth
Which method to use, and what to do when automatic OAuth fails.