What is MCP Server? A Complete 2026 Guide with 25 Servers to Know

TL;DR

1. Definition: An MCP server is a program that exposes tools, prompts, and resources to an AI client over the Model Context Protocol.

2. Role: It sits between an LLM client and an external system (database, SaaS app, file system) and translates each into the other's language.

3. Capabilities: Every MCP server exposes some combination of tools (callable functions), prompts (templated workflows), and resources (readable data).

4. Types: Four deployment models exist (local stdio, remote SSE, remote Streamable HTTP, managed SaaS) with different trade-offs.

5. Used by: Claude, Cursor, ChatGPT Desktop, Windsurf, and any client that implements the protocol can connect to any MCP server.

6. Why it matters: MCP servers are the agent-era equivalent of REST endpoints; governing them is now a board-level conversation.

What is an MCP server, and how does it fit in the MCP architecture?

An MCP server is a program that exposes tools, prompts, and resources to an AI client over the Model Context Protocol. It is the "backend" half of the protocol: where an MCP client sends requests, an MCP server answers them by calling tools, reading resources, or returning prompt templates. The server hides the messy details of authentication, data fetching, and API translation so the LLM can reason in plain language.

Anthropic published the protocol in November 2024 to standardize how LLMs reach outside their context window. Before MCP, every AI client (Claude, ChatGPT, Cursor, your custom agent) had to write a custom adapter for every external system. With MCP, each system implements the protocol once, and any compliant client can talk to it. That is the N x M to N + M reduction that made the protocol attractive in the first place.

The 4 roles in the MCP architecture

Every MCP deployment has four roles. Understanding which role a piece of software plays is the fastest way to know what to build, buy, or govern.

• Host: The application the human uses. Claude Desktop, Cursor, Windsurf, ChatGPT Desktop, and any custom agent application are hosts. The host renders the interface, holds the conversation history, and decides when to call an MCP client.
• Client: The component inside the host that speaks the protocol. One host can run multiple clients, each connected to a different MCP server. The client handles handshakes, capability negotiation, and request routing.
• Server: The program that exposes tools, prompts, and resources. Servers can be remote SaaS endpoints, processes running on the user's laptop, or workloads inside a customer Kubernetes cluster.
• Gateway: An optional control plane that sits between many clients and many servers. Most enterprises that adopt MCP at scale put a governed MCP gateway in the middle so registry, identity, policy, observability, and audit all live in one place.

Anthropic's specification defines the first three roles. The fourth role (the gateway) is what every serious enterprise deployment converges on. We cover the gateway deeply in the MCP gateway architecture guide and contrast it with REST gateways in MCP vs API gateway.

5 things an MCP server is, 5 things it isn't

An MCP server is:

• A long-running process that exposes a stable surface (tools, prompts, resources) to MCP-compliant clients.
• A translation layer between LLM-friendly semantics and the external system it represents.
• A unit of governance: it can be approved, version-pinned, scoped, audited, and revoked through an MCP governance framework.
• A unit of identity: the user, agent, and tool token all flow through it on every call.
• A potential security perimeter: the server's authorization decides what an agent can actually do downstream.

An MCP server is not:

• A REST API, even when it wraps one. Differences are detailed in section four below.
• A plugin in the OpenAI sense, which had a different protocol with manifest files and OpenAPI hosting.
• An AI agent. Agents are clients of MCP servers, not servers themselves.
• A guarantee of safety. A server with broad scopes can still be misused if there is no enterprise MCP gateway enforcing policy.
• Always remote. Many servers run locally on the user's machine via stdio (see types in section three).

What capabilities does an MCP server expose? Tools, prompts, resources

Every MCP server exposes some combination of three primitives: tools (callable functions), prompts (templated workflows), and resources (readable data). A minimal server exposes one or two; a comprehensive server exposes all three. The mix decides what an LLM can do with the server and how the server should be governed.

The capabilities list is part of the initial handshake. When a client connects, the server returns its declared capabilities, and the client surfaces them to the model. This is how the model "knows" which tools it can call without being hardcoded.

Tools: the functions an LLM can call

Tools are the most common and most powerful capability. Each tool has a name, a description (natural language), a JSON schema for parameters, and a return type. When the LLM decides to take an action, it picks a tool, fills the parameters, and the server executes the underlying code.

A tool can do anything code can do: read from a database, send a Slack message, create a Linear issue, deploy a service. Because tools are described in natural language, they are also the surface area for tool poisoning attacks, where a malicious server embeds hidden instructions in the description. Every approved server needs description vetting in the MCP server security checklist.

Prompts: reusable templated workflows

Prompts are named, parameterized templates that the host surfaces in the UI (often as slash commands or a prompt picker). They are pre-written instructions the user can invoke, not autonomous tool calls. A "Summarize this PR" prompt or a "Draft a customer reply" prompt are typical examples.

Prompts are underused. Most SERP pieces skip them. They are the most natural place to encode an organization's preferred workflows so non-technical users get the same quality output without writing prompts from scratch.

Resources: data the LLM can read

Resources are addressable, readable data the server makes available: documents, database rows, search results, files. The client reads them and decides whether to include them in the LLM context. Each resource has a URI, a content type, and (often) a description.

Resources are how an MCP server replaces what we used to call "retrieval." Instead of dumping a vector database into the context window, the server exposes resources by URI and the host fetches only what is needed, when it is needed.

When to use which capability

‍

A complete server typically mixes all three. The Slack MCP server exposes tools (send message, create channel), prompts (summarize thread), and resources (channel history). The Postgres MCP server exposes tools (run query) and resources (table schema, sample rows).

What types of MCP servers exist, and how do you pick?

Four deployment models exist: local stdio, remote SSE, remote Streamable HTTP, and managed SaaS. Each combines a transport choice (how the client and server communicate) with a hosting choice (where the server runs). Picking the right model is downstream of two questions: how sensitive is the data, and how many clients need to share the server.

The decision affects everything from network architecture to which transport options for MCP your governance stack needs to handle. The 2x2 below maps the four common models.

The 4 deployment models

‍

Local stdio servers

Local stdio servers are processes that the host launches on the user's machine. The client and server talk over stdin and stdout. There is no network, no auth, no public endpoint. The trust boundary is the user's laptop.

These servers are common for file-system access, dev tools, and personal scripts. They are not appropriate for shared production workloads because every user runs their own instance. Enterprise teams typically deploy stdio servers only when the data being accessed is local to the user.

Remote SSE servers

SSE (Server-Sent Events) was the original remote transport for MCP. It is a simple HTTP-based protocol that the original spec supported. Many existing servers still use SSE, but the protocol is being deprecated in favor of Streamable HTTP for new deployments.

Remote Streamable HTTP servers

Streamable HTTP became the recommended transport in mid-2025. It uses a single HTTP endpoint with chunked responses, which simplifies network architecture (no separate SSE channel) and reduces latency. New servers should default to Streamable HTTP. We cover the protocol details and the migration path in MCP gateway architecture.

Managed SaaS servers

Managed SaaS servers are vendor-hosted endpoints that any client can connect to. The vendor handles hosting, scaling, identity, and updates. The trade-off is data sovereignty: every tool call goes through the vendor's infrastructure.

Most enterprises end up running a mix of all four. The hybrid MCP deployment pattern (a managed control plane plus customer-side data plane) is one way to keep data inside the customer perimeter while still offloading control plane operations.

How to pick

• For personal productivity and dev tools: local stdio.
• For multi-user remote tools with low complexity: remote Streamable HTTP behind a self-hosted MCP gateway.
• For pre-built SaaS integrations: managed SaaS with secure MCP endpoint controls at the edge.
• For regulated data: Streamable HTTP behind a customer-controlled gateway with full audit and data residency.

How is an MCP server different from an API, a plugin, and an AI agent?

An MCP server is a stateful, bidirectional, capability-declaring program designed for LLM clients. A REST API is a stateless, unidirectional, schema-declaring program designed for deterministic clients. A plugin is the previous-generation answer to the same problem. An AI agent is a client of MCP servers, not a server itself. The differences shape every governance decision downstream.

The query "is an MCP server an API" sits at position 1 in Google Search with one impression. The answer matters because conflating the two leads teams to apply the wrong governance pattern.

The 4-way comparison

‍

When each is the right primitive

• MCP server: when an LLM client needs ongoing, capability-declaring access to a system. The server stays connected, declares what it can do, and handles many requests over the session lifetime.
• REST API: when a deterministic client needs predictable request-response semantics. Most production systems still ship REST APIs as the lowest-common-denominator surface.
• Plugin (OpenAI 2023): historical interest only. The plugin model was deprecated in favor of GPTs in late 2023.
• AI agent: when you need autonomous planning, multi-step reasoning, and memory across tool calls. Agents are clients of MCP servers, not replacements for them.

The pragmatic pattern in 2026 is "REST API as the system of record, MCP server as the agent-facing wrapper, agent as the autonomous caller." For teams already running a REST estate, the cheapest path is to expose existing endpoints as MCP servers, which we cover in convert API to MCP and how to make APIs MCP-ready.

For the gateway side of the comparison (MCP gateway vs API gateway), see MCP gateway vs API gateway.

How do you connect to and use an MCP server?

Connecting to an MCP server takes three steps in any modern client: declare the server in config, restart the client, then call the tools. The exact config format varies by host (Claude Desktop, Cursor, ChatGPT Desktop, custom). The transport and auth differ. The mental model is identical across all of them.

The walk-throughs below cover the four most common 2026 hosts. For production enterprise use, none of these connect direct to public servers; they connect to an internal endpoint behind a gateway that handles secure MCP endpoint controls, identity propagation, and audit.

Connecting from Claude Desktop and Claude Code

Claude Desktop reads a claude_desktop_config.json file. Add the server to mcpServers.

{
  "mcpServers": {
    "postgres": {
      "command": "uvx",
      "args": ["mcp-server-postgres", "postgresql://localhost/mydb"]
    }
  }
}

For remote servers, point at the URL:

{
  "mcpServers": {
    "company-tools": {
      "url": "https://mcp.example.com",
      "transport": "streamable-http"
    }
  }
}

OAuth is handled automatically when the server advertises an authorization server. For enterprise deployments, point at your gateway URL so MCP authentication patterns (per-user token issuance, audience validation, token isolation) are enforced centrally.

Connecting from Cursor

Cursor reads ~/.cursor/mcp.json with the same schema. Cursor also supports per-workspace MCP config in .cursor/mcp.json inside the project, which is useful for scoping servers to specific repositories.

Connecting from ChatGPT Desktop

ChatGPT Desktop added MCP support in 2025. The UI is Settings, Integrations, MCP Servers. Add the URL and authorize. Streamable HTTP is the default transport.

Connecting from a custom client

Custom clients use the official SDKs (TypeScript, Python, Java, .NET) to handle the protocol. The client connects, negotiates capabilities, and exposes tools to the model layer of your choice. The SDKs handle JSON-RPC framing, capability negotiation, and reconnection.

What you should always do before connecting

• Verify the server. Inspect tool descriptions for prompt injection. The MCP server security guide explains what to look for.
• Use a gateway in production. Direct client-to-server connections do not scale to multi-team enterprise use. The governed MCP gateway is where policy, identity, and audit live.
• Scope credentials narrowly. Per the MCP data privacy guidance, never grant agent credentials broader than the calling user has.
• Log every call. Per-user, per-tool, per-parameter capture is the auditor expectation.

How do you build (or convert an existing API to) an MCP server?

Three paths exist: build from scratch with the official SDK, convert from an OpenAPI specification, or wrap an existing REST API behind a gateway with adapter logic. The choice depends on what you already have and how fast you need to ship. For most enterprises with mature REST estates, paths two and three are dramatically faster than rewriting.

The GSC data shows real demand here. "What is the most efficient way to convert existing APIs into MCP servers" sits at position 2.2 with 37 impressions. "What steps are required to convert existing APIs into MCP servers to enable autonomous AI agents" sits at position 4.9 with 35 impressions. Teams are actively looking for the right recipe.

Path A: Build from scratch with the official SDK

Pick an SDK (TypeScript, Python, Java, .NET) and implement the server interface. You define the tools, prompts, and resources, handle the protocol, and run the process under stdio or HTTP. This is the path for net-new functionality or for servers that need fine control over the protocol.

Time to first working tool: 1 to 3 days for a developer familiar with the SDK. Production hardening (auth, observability, error handling) is the multi-week part.

Path B: Convert from an OpenAPI specification

Many internal APIs already have OpenAPI 3.x specifications. Tools that read the spec and generate a working MCP server have proliferated in 2025 and 2026. The generated server maps every API operation to a tool with the corresponding request schema.

This path is the fastest for teams whose APIs are already documented. The one-click OpenAPI conversion is the canonical implementation: pick the operations, get governed MCP tools without writing custom server code. The make APIs MCP-ready guide covers the spec hygiene that produces the best results.

Time to first working tool: minutes if the spec is clean. Production readiness depends on how much of the original API still needs custom adaptation.

Path C: Wrap an existing REST API behind a gateway

Some enterprises do not want a 1:1 mapping. They want a curated subset of operations exposed as MCP tools, with custom names, descriptions, and parameter handling. Path C uses a gateway with adapter logic to translate between the two surfaces.

This is the path for governed MCP gateway deployments where the gateway is already the enforcement point for the REST API estate. Adding MCP support means writing adapters, not building new servers. The MCP gateway architecture guide explains how this layer sits.

How to pick between paths

‍

For most 2026 enterprise teams, Path B + Path C is the cheapest combination: convert what you have, curate the resulting surface through the gateway, and apply Cedar policy enforcement at runtime.

What 25 MCP servers should every enterprise know in 2026?

The MCP server ecosystem grew from a dozen reference servers at launch to hundreds by mid-2026. The list below is the 25 we see most often in enterprise deployments, grouped by category. Each entry covers maintainer, transport, auth, and primary use case. Use it as a discovery list, not as an installation recipe; vetting belongs in your registry workflow.

For full vendor and gateway analysis (including which gateways host which servers natively), see best MCP gateways 2026.

Productivity (5 servers)

‍

Data (5 servers)

‍

Developer tools (5 servers)

‍

Customer (5 servers)

‍

Observability (5 servers)

‍

Adoption is not the same as enterprise readiness. Every server on this list still needs vetting through your MCP governance maturity model before production approval.

How do you secure and govern MCP servers?

Every MCP server in production needs the same five minimum controls: per-user identity propagation, tool-level policy, content filtering, per-call audit logging, and version-pinned lifecycle management. The gateway is the standard enforcement point for all five. Without the gateway pattern, each server reimplements security on its own, badly.

The GSC base for "mcp server security" sits at 139 impressions at position 86, and "mcp server security best practices" sits at 127 impressions at 85.9. Demand is high; competition is thin. A focused security posture is the fastest way to move from "scattered server installs" to "audit-ready program."

The 5 minimum controls every server needs

• Per-user identity propagation: The user's identity (not a shared service account) flows through to the underlying system. See secure MCP endpoint guide for the OAuth 2.1 patterns.
• Tool-level policy: Decisions are made per tool and per parameter, not per server. Covered in the MCP governance framework.
• Content filtering: PII redaction, secret detection, and prompt injection screening apply to both request and response payloads. See MCP data privacy controls.
• Per-call audit logging: Every tool call captures user, agent, server, tool, parameters, response, decision, and latency. Retained for at least 90 days.
• Version-pinned lifecycle management: The registry tracks the approved version, and continuous re-validation catches rug pulls.

Why a gateway is the standard enforcement point

A gateway centralizes these controls so individual servers do not have to reimplement them. The MCP gateway pillar covers the broader architecture. The MCP gateway architecture deep dive walks through the two-plane design (control plane plus data plane) that makes enforcement scale.

For organizations evaluating gateway options, the best MCP gateways 2026 listicle scores 14 vendors and 5 open-source options against the same eight criteria.

Where MCP server governance fits in the broader program

MCP server security is a component of MCP governance, not a substitute. The full program covers six pillars: registry, identity, policy, observability, lifecycle, and compliance. We detail all six in the MCP governance framework along with a five-level maturity model and a six-framework compliance crosswalk.

For regulated industries, the developer portals for governance guide covers how internal developer portals tie into MCP server vetting workflows.

90-second self-assessment

Answer yes or no to these eight questions. Three or more "no" answers means your MCP servers are not yet production-ready.

1. Can you list every MCP server running in production, including version and owner?
2. Does every tool call carry a per-user, per-tool token?
3. Are tool descriptions scanned for prompt injection before approval?
4. Are tool calls logged with parameters, decisions, and latency?
5. Can you block a server from running in production through a single change?
6. Is there a documented submission and vetting workflow for new servers?
7. Are high-risk tool calls (writes, payments, deletions) gated by human approval?
8. Are MCP servers covered by your SOC 2, HIPAA, or ISO 27001 evidence collection?

How does DigitalAPI fit in the MCP server ecosystem?

DigitalAPI is an API Management platform that ships an enterprise-grade MCP gateway alongside its broader API governance product. For teams running existing REST estates, DigitalAPI's one-click OpenAPI to MCP conversion turns documented endpoints into governed MCP servers without writing custom server code. The same control plane that governs the REST APIs governs the resulting MCP tools.

For teams building net-new MCP servers, DigitalAPI's gateway provides the registry, identity, policy, observability, lifecycle, and compliance layers around customer-operated servers. Cedar policy decisions, OAuth 2.1 token isolation, OpenTelemetry-native audit, and SIEM-grade export all work out of the box. Deployment options include hybrid (managed control plane plus customer-side data plane) and fully self-hosted on customer Kubernetes.

The wedge: existing customers who already use DigitalAPI for REST API governance get MCP server governance without buying a separate product. Teams new to DigitalAPI typically reach Level 2 maturity (per the MCP governance maturity model) within 30 days of contract.

See how DigitalAPI's MCP gateway turns REST APIs into governed MCP servers. Book a demo.

FAQs

1. What is an MCP server?

An MCP server is a program that exposes tools, prompts, and resources to an AI client over the Model Context Protocol. It is the backend half of the protocol: where MCP clients (Claude, Cursor, ChatGPT Desktop) send requests, MCP servers answer them by calling tools, reading resources, or returning prompt templates.

2. Is an MCP server an API?

An MCP server wraps APIs and exposes them in a format LLM clients can use, but it is not the same as a REST API. MCP servers are stateful and bidirectional. REST APIs are stateless. MCP servers declare capabilities in natural language. REST APIs declare schemas. Production deployments often run both, with the REST API as the system of record and the MCP server as the agent-facing wrapper. See MCP gateway vs API gateway for the gateway-level comparison.

3. What does an MCP server do?

An MCP server exposes three primitive capabilities to clients: tools (functions the model can call), prompts (templated workflows), and resources (data the model can read). A complete server typically combines all three. The Slack MCP server exposes send-message tools, summarize-thread prompts, and channel-history resources.

4. What are the types of MCP servers?

Four deployment models exist: local stdio (process on user's machine), remote SSE (deprecated HTTP transport), remote Streamable HTTP (current best practice), and managed SaaS (vendor-hosted). The transport and hosting choices have different trade-offs documented in section three. Production enterprise deployments typically run a mix behind a self-hosted MCP gateway.

5. How do I install an MCP server?

Most modern hosts read a claude_desktop_config.json or equivalent file. For local stdio servers, declare the command and arguments. For remote servers, declare the URL and transport. Restart the host. The capabilities appear in the UI. For enterprise deployments, point clients at an internal gateway endpoint that enforces secure MCP endpoint controls.

6. Are MCP servers secure?

MCP servers are as secure as their controls. Without a registry, gateway, and governance program, MCP servers expose enterprises to tool poisoning, rug pulls, confused deputy attacks, credential exposure, and shadow MCP. With the MCP governance framework, the same servers can be made audit-ready for SOC 2, HIPAA, PCI-DSS, EU AI Act, NIST AI RMF, and ISO 27001.

7. How do I build my own MCP server?

Three paths exist: build from scratch with the official SDK (TypeScript, Python, Java, or .NET), convert from an OpenAPI specification with a generator, or wrap an existing REST API behind an MCP gateway architecture. Build from scratch gives total control. Conversion from OpenAPI is fastest for teams with documented APIs. Wrapping behind a gateway gives curated exposure with governance built in.

8. Can I turn my existing REST API into an MCP server?

Yes. The fastest path is to point a converter at your OpenAPI 3.x specification and let it generate a working MCP server. DigitalAPI's one-click OpenAPI conversion is the canonical implementation. The make APIs MCP-ready guide covers the spec hygiene that produces the cleanest result. Teams with cleanly documented APIs typically have a working server in minutes.

9. What is the difference between an MCP server and an MCP gateway?

An MCP server exposes capabilities (tools, prompts, resources) to clients. An MCP gateway is a control plane that sits between many clients and many servers, enforcing registry, identity, policy, observability, lifecycle, and compliance. The server is the unit of capability. The gateway is the unit of governance. The governed MCP gateway pillar goes deeper on the role.

10. Which MCP servers should I use first?

For most enterprises, the highest-leverage starting set is one productivity server (Slack or Notion), one data server (Postgres or Snowflake), one developer-tools server (GitHub), one customer server (HubSpot or Salesforce), and one observability server (Datadog or Honeycomb). Section seven lists 25 production-ready servers grouped by category. Vet each through your MCP governance maturity model before production approval.