Understanding MCP Server Types in MCP Manager

Introduction

The Model Context Protocol (MCP) is an open standard that defines how AI applications — such as Claude, Cursor, or custom-built agents — connect to external tools, data sources, and services. Think of it as a universal adapter that lets your AI systems interact with the software your teams already use every day.

MCP servers are the services that expose these tools and data to AI. They might give your AI assistant the ability to search your company's documents, create tickets in your project management tool, query a database, or interact with files on a local machine.

MCP Manager sits between your AI applications and those MCP servers as a centralized gateway. Every request passes through MCP Manager, where it is authenticated, inspected, logged, and routed to the right destination. This gives your organization visibility and control over what your AI systems can access — without slowing your teams down.

To support the wide variety of ways MCP servers are deployed, MCP Manager supports three server types: Remote, Managed, and Workstation. Each type is designed for a different hosting scenario, and each comes with its own connection method, setup experience, and set of benefits. This article walks through all three.

Remote Servers

What are Remote Servers?

Remote servers are MCP servers hosted by a third party on the public internet. When you connect to a SaaS vendor's MCP endpoint — like Atlassian, GitHub, or HubSpot — you're connecting to a remote server. MCP Manager reaches these servers over standard HTTPS, making them the simplest server type to set up.

Why Use a Remote Server?

Remote servers are ideal when you want to connect your AI tools to a third-party application and its data without managing any infrastructure yourself. The MCP server is already running and publicly accessible — all you need to do is authenticate and connect through MCP Manager.

Common use cases include connecting to project management tools, CRMs, code repositories, documentation platforms, and other SaaS applications that offer MCP endpoints. If you also want to connect to your own self-hosted MCP server that has an exposed public URL, you can connect via Remote.

Authentication Methods for Remote Servers

MCP Manager supports three ways to authenticate with remote servers, depending on what the server requires:

1. Standard OAuth via URL

Some remote MCP servers support OAuth with dynamic client registration. This is the most seamless experience: you provide the server's URL, and MCP Manager handles the entire OAuth flow automatically — registering as a client, redirecting you to authorize access, and managing token refresh behind the scenes.

Example: Atlassian's MCP server supports this approach. You simply provide the server URL, MCP Manager registers itself as an OAuth client, and you authorize access through Atlassian's standard login flow. No app creation or developer configuration is required on your part.

2. OAuth via Client Pre-Registration

Some MCP servers require you to create an application in their developer portal before connecting. In this case, you register an app with the provider, and then supply MCP Manager with the Client ID and Client Secret from that app. MCP Manager provides the callback URL that you'll need to enter in the provider's app settings.

https://mcp.mcpmanager.ai/api/v1/mcpm/inbound/oauth/callback

Once configured, the OAuth flow works the same as the standard method — MCP Manager handles token exchange and refresh automatically.

Examples:

• Asana — Create an app in the Asana developer console, enter the Client ID and Client Secret in MCP Manager, and paste in the callback URL that MCP Manager provides.
• HubSpot — Build a public or private app in HubSpot's developer platform, configure it with the MCP Manager callback URL, and provide the resulting Client ID and Client Secret. HubSpot's developer documentation has a guide on integrating with remote MCP servers that walks through this process.

3. Custom Headers via Token

When a remote MCP server uses token-based authentication (such as an API key or bearer token) instead of OAuth, you can provide the credentials directly as custom headers. MCP Manager will attach these headers to every request it sends to that server on your behalf.

This approach works well for servers that issue static API keys or personal access tokens through their settings pages. You simply enter the header name (e.g., Authorization) and value (e.g., Bearer your-token-here) during setup.

All tokens and secrets you provide are encrypted using AES-256-GCM and stored in MCP Manager's secure key vault. Your credentials are never exposed in logs or accessible to other users.

How to decide which method to connect with?

Some remote servers offer multiple ways of authentication (ex: Github allows both OAuth and header tokens). Some remote servers don't make it clear how to connect to clients that are not Claude/Cursor/etc. In those cases, how can you decide which method to connect with? There are a few ways to think about ideal authentication:

1. Token authentication is often times more customizable (with scope definition being part of the core flow to create a token) and more stable.
2. Connecting via OAuth is often easier for non-technical users to navigate as it requires simply accepting conditions in a pop up window for that application and not generating a token deep inside an application's developer settings menu.
3. Sometimes, connecting via automatic OAuth does not work and you need to provide a client secret and a client ID. This could be for 3 reasons: 
   1. The server is more security-conscious and requires clients to register ahead of time in admin or personal settings. This gives extra visibility and control to system admins to monitor what is being connected. Slack is a good example here. 
   2. The server does not support dynamic client registration and so needs pre-registration.
   3. The server has a defined allowlist of common MCP clients like Claude, Cursor, Goose, etc, but does not allow any client to connect by default. This is when you need to register MCP Manager as a client app in your server's application. If an MCP server does not allow custom clients at all, then they likely allow localhost to connect and you can run a local server through MCP Manager via Workstation (see below).

Managed Servers

What are Managed Servers?

Managed servers are MCP servers that run inside Docker containers within your own cloud infrastructure. MCP Manager helps you provision and connect to these servers through a guided setup process, but the server itself lives in an environment you control.

This server type is designed for situations where you need to run an MCP server that isn't available as a public remote endpoint — for example, a database MCP server that needs direct access to your internal systems, or a custom-built MCP server specific to your organization.

The other reason to use a managed server vs. exposing a self-hosted server via a URL is if the MCP server needed to be exposed differently to different groups of people (per team, per project, per customer, etc). Managed servers allow you the benefit of easy portability to gateways while still allowing there to be different server instances within that single server.

Why Use a Managed Server?

Managed servers give you the flexibility to run any MCP server while still benefiting from MCP Manager's gateway capabilities (authentication, logging, security guardrails, and access control). Here are some common use cases:

• Database access — Run a Postgres, MySQL, or other database MCP server that connects directly to your internal databases. Because the server runs in your environment, it can reach databases that aren't exposed to the public internet.
• Project or team-specific memory — Deploy a memory MCP server that gives your AI tools persistent context for a specific project or team. This is useful for long-running initiatives where you want AI assistants to recall past decisions and context.
• Shared team resources — Stand up MCP servers that multiple team members access through MCP Manager, with centralized identity and access controls governing who can use them.
• Custom or internal tools — Run MCP servers built in-house that expose your organization's proprietary tools and workflows to AI systems.

What You Need to Set Up a Managed Server

To create and connect a managed server, you'll need:

• SSH access to your hosting environment — either via SSH password or SSH key. This is required so that MCP Manager can help you provision the container.
• The ability to stand up new containers in that environment (Docker must be available).

MCP Manager handles the authentication layer between itself and your managed server automatically. Each managed server is assigned a shared secret that only MCP Manager and your server know, ensuring that requests are authenticated without any additional configuration on your part.

The Setup Experience

MCP Manager provides a wizard in the product that walks you through the entire managed server setup:

1. Configure your server — Provide the server details such as the instance name, the MCP server image or command, and any required environment variables or configuration.
2. Connect to your environment — Provide the SSH connection details for your hosting environment.
3. Run the generated command — The wizard generates a single terminal command tailored to your configuration. You copy this command and run it in your hosting environment. The command handles pulling the Docker image, setting up the container with the correct networking and authentication, and starting the server.
4. Test the connection — Once the server is running, use the built-in test to verify that MCP Manager can reach your managed server and discover its available tools.

The container that gets provisioned includes an authentication layer that validates requests from MCP Manager before forwarding them to the MCP server process. This means your server is protected even if the container's port is reachable from other sources.

Workstation Servers

What are Workstation Servers?

Workstation servers are MCP servers that run locally — on a user's laptop, desktop, or an on-premises server. These servers are connected to MCP Manager through an encrypted tunnel, meaning they are never exposed to the public internet. All traffic between MCP Manager and a workstation server flows through an end-to-end encrypted WireGuard tunnel.

Why Use a Workstation Server?

Workstation servers are the right choice when:

• The MCP server needs local access — Servers like Playwright (browser automation), filesystem MCP servers, or other tools that interact with a user's local machine need to run where that machine is.
• You're working with on-premises resources — If your MCP server needs to reach systems that are only available on your internal network, running it on a workstation inside that network is the simplest approach.
• You want MCP Manager governance for local servers — Even though the server runs locally, all traffic still flows through the MCP Manager gateway. This means you still get full logging, security guardrails, identity management, and access controls — the same benefits as remote and managed servers.

One of the key benefits of routing local MCP traffic through the MCP Manager gateway is visibility. Without it, local MCP servers are invisible to your organization's security and governance tooling. With workstation servers connected through MCP Manager, every tool call is logged, inspected, and subject to your policies.

How Workstation Servers Connect

MCP Manager uses a lightweight tunnel agent to create a secure connection between your workstation and the MCP Manager gateway. Here's how the connection works at a high level:

1. A small container runs on your machine that establishes an encrypted WireGuard tunnel to MCP Manager.
2. MCP Manager routes requests through this tunnel to reach your local MCP server.
3. A local router component validates each request using an access key before forwarding it to your MCP server.

The tunnel handles NAT traversal automatically, so workstation servers work even behind firewalls or corporate networks without any special network configuration.

The Setup Experience: TUI + CLI

MCP Manager provides a wizard in the product that generates a single Docker command for you to run on your workstation. This command starts the tunnel agent and connects your local MCP server to MCP Manager.

When you run the command in your terminal, it launches a terminal user interface (TUI) — an interactive dashboard right in your command line. The TUI provides:

• Connection status — See the progress of each step as the tunnel is established and your workstation registers with MCP Manager.
• Health monitoring — View real-time health information and connection statistics.
• Logs — Access local workstation logs for troubleshooting.
• Port information — See which ports are in use on your machine.
• Server controls — Start, stop, or restart the workstation connection directly from the TUI.

The container runs in the background with an automatic restart policy, so your workstation server stays connected even after reboots. The TUI is there for setup and monitoring — once the connection is established, it continues working silently in the background.

Identities and Identity Availability

Across all three server types, MCP Manager uses identities to manage how users authenticate with MCP servers and access their data. An identity represents a set of access credentials for a specific MCP server — it determines what data and tools are available through that connection.

Identities can be created in two ways:

• Authorization/bearer tokens — You provide an API key or access token that represents your level of access in the target application.
• OAuth — You authenticate directly with the application through an OAuth flow, and MCP Manager securely manages the resulting tokens on your behalf.

Identity Availability: Public and Private

When you create an identity for an MCP server, you can choose its availability:

• Private — The identity is only available to you. No one else in your organization can use your credentials to access the MCP server. This is the default and is appropriate for personal accounts and individual access tokens.
• Global — The identity is available to other users in your organization. This is useful when you've set up a shared service account and want team members to use it without each person needing their own credentials. For example, if your organization has a service account for a project management tool, you can authenticate once and make that identity available to your team.

Administrators can also configure an identity scheme on assigned servers within a gateway. This setting controls whether every user must authenticate individually with the server (bring your own identity) or whether a single pre-selected identity is shared across all users of that gateway. This gives administrators flexibility to match their organization's security policies — requiring individual accountability where needed, or simplifying access with shared service accounts where appropriate.

All identity credentials — whether tokens you provide or OAuth tokens that MCP Manager obtains on your behalf — are encrypted at rest using AES-256-GCM and stored securely. MCP Manager also supports automated token rotation to keep credentials fresh and reduce the risk of compromise.