MCP Servers Overview

The Model Context Protocol (MCP) is an open standard that defines how AI applications — Claude, Cursor, ChatGPT, 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. An MCP server is the service that exposes those tools and data to AI: it might search your company’s documents, create a ticket in your project-management tool, query a database, or read files on a local machine. MCP Manager sits between your AI applications and your MCP servers as a centralized gateway. Every request passes through MCP Manager, where it is authenticated, inspected, logged, and routed to the right destination — giving your organization visibility and control over what your AI systems can access, without slowing your teams down. MCP servers are deployed in very different ways, so MCP Manager organizes them into three types — Remote, Managed, and Workstation. Each type reflects a different hosting scenario and comes with its own connection method, setup experience, and trade-offs. This page explains what each one is, when to choose it, and how identities govern access across all three.

​

Why MCP servers come in different types

People have historically distributed MCP servers in one of two ways: as a remote, HTTP-based connection to a server already running at a URL (often a SaaS vendor’s), or as a command you run locally to start a server on a user’s own workstation. That binary — remote or local — leaves a gap. Organizations need more secure and scalable ways to run MCP servers across teams without asking non-technical users to manage commands on their own machines. To close that gap, many run command-launched servers inside containers on infrastructure they control — and MCP Manager can hand you a ready-to-run command to do exactly that (a managed server). This pattern is different enough from both the remote and local models to warrant its own category. MCP Manager therefore recognizes three distinct types, described below.

​

The three MCP server types

Whichever type a server uses, every request takes the same path: an AI app or agent calls MCP Manager, which authenticates, inspects, logs, and routes the request to the right server. Only the final hop differs — HTTPS to a remote or managed server, or an encrypted tunnel down to a workstation.

​

Remote: a server already running at a URL

A remote MCP server is one that is already running at a URL, which MCP Manager reaches over standard HTTPS — whether it’s a SaaS vendor’s endpoint or your own self-hosted server. There is nothing to install or provision; you give MCP Manager a URL, authenticate, and connect. Most remote servers authenticate with OAuth (typically OAuth 2.1) or a token sent as a request header. Remote is the fastest and easiest type to stand up. For a SaaS product, the vendor carries the burden of hosting, updates, and uptime; for your own self-hosted server, you already run it and simply point MCP Manager at its URL. Best for: SaaS tools, and any server — vendor-hosted or your own — that already has a URL and only needs a single instance.

• Pros: fastest to set up; one server serves many clients; no work on MCP Manager’s side; standard web auth (OAuth, HTTPS); low resource use.
• Cons: the server must already be running at a URL; for SaaS you depend on the vendor for uptime and data security; can’t run per-user, per-group, or per-environment instances.

See Remote MCP Servers for the three authentication methods and how to choose between them.

​

Managed: the same server as multiple instances in your infra

A managed MCP server is the same server run as multiple named instances in your own infrastructure — per user, team, customer, or environment — connected to and governed by MCP Manager as one server. An instance already running at a URL is registered directly; for a server that ships as a local command (an npx/uvx stdio package or a container image), MCP Manager hands you a ready-to-run command that starts it as a containerized server on your hardware. MCP Manager is a gateway, not a host — you bring the infrastructure, and it manages the secure connection and governance. Choose Managed over Remote for one of two reasons: you need more than one instance of the same server — per user, group, or environment, such as staging and production deployments at different URLs — or you want the ready-to-run command for a server that isn’t running yet. A server you’ll only ever run as one copy at one URL is a Remote server. Managed deployments come in two patterns:

• Managed-Dedicated — each user or agent gets their own container instance. Choose this when a server can’t be shared safely: for example, browser automation with Playwright or Puppeteer, where 30 developers driving one browser session at once would be chaos. The cost is higher resource use and more orchestration.
• Managed-Shared — a single container instance serves many users. Choose this when a resource is better centralized: for example, a Memory MCP holding shared coding standards, where a few users have write access and most read. The cost is more complex permissions and possible contention.

Best for: multiple instances of the same server — per user, group, or environment (staging vs. production) — plus command-launched or custom servers, internal databases, and shared team resources. See Managed MCP Servers for what you need and how the guided setup works.

​

Workstation: a server on a local machine

A workstation MCP server runs directly on a user’s machine — a laptop, desktop, or on-premises box — and communicates locally over STDIO. Workstation servers are the right choice only when the server genuinely needs the local machine: access to the local file system, the code a developer is editing, a code editor or IDE, or OS-level utilities. Examples include filesystem servers, an editor integration that reads open buffers, or a tool that queries local hardware. Left on their own, local MCP servers are the hardest deployment to govern: because the tool runs on an employee’s machine, it is difficult to monitor the data flowing in and out, apply enterprise policy, or secure the connection. MCP Manager solves this by running the local server behind an encrypted tunnel that routes its traffic back through the MCP Manager gateway — so a workstation server is never exposed to the public internet and every tool call is still logged, inspected, and subject to your policies. Best for: tools that must touch local files, editors, or hardware, and on-premises resources reachable only from inside your network. See Workstation MCP Servers for how the tunnel works and the setup experience.

​

Comparing the three types

The three types differ mainly in where the server runs, how MCP Manager reaches it, and what you accept in return. Remote servers are already running at a URL — a SaaS vendor’s or your own — and MCP Manager connects over HTTPS; easiest, but the server must already exist. Managed servers run on infrastructure you provide — registered where they already run or launched from a generated command — and are reached over a URL; more to operate, but they can run per-user, per-group, or per-environment instances. Workstation servers run on a local machine and are reached through an encrypted tunnel; the only option for local-only tools.

​

How identities control access across all three types

Across every server type, MCP Manager uses identities to manage how users authenticate with an MCP server and what they can reach. An identity is a set of access credentials for one specific MCP server — it determines which data and tools are available through that connection. Identities are created in one of two ways:

• Authorization / bearer token — you supply 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.

When you create an identity, you choose its availability:

• Private — the identity is only available to you. This is the default and suits personal accounts and individual access tokens.
• Global — the identity is available to other users in your organization, which is useful for a shared service account. (Legacy identities created without an availability set behave as Global.)

Administrators can also set an identity scheme on a server assigned within a gateway, which controls how users authenticate to that server:

• Per-user identity — every user must authenticate individually (bring your own identity), for individual accountability.
• Shared identity — a single pre-selected identity is shared across all users of that gateway, to simplify access with a service account.

All identity credentials — tokens you provide and OAuth tokens MCP Manager obtains for you — are encrypted at rest using AES-256-GCM and stored in MCP Manager’s secure key vault. MCP Manager also supports automated token rotation to keep credentials fresh and reduce the risk of compromise.

​

Why the type distinction matters

MCP is a communication protocol, not a batteries-included enterprise product. Remote servers are easy to adopt, but many critical business workflows require managed or workstation servers — and those are harder to run, secure, and monitor. Without an overarching plan or an enterprise gateway to wrap, monitor, and control the more complex deployments, organizations risk unmonitored data flows, no audit trail (no way to know if sensitive data leaked), and significant IT overhead. Routing all three types through MCP Manager restores what the raw protocol leaves out: end-to-end logging, security guardrails, identity management, and access control — applied consistently whether a server runs on a SaaS provider, in your own infrastructure, or on a laptop.

​

Further reading

​

External sources