What Is an MCP Server?

What Is an MCP Server?

An MCP server is a program that exposes tools, resources, and prompt templates to AI applications through the Model Context Protocol. It solves the integration problem between AI assistants and external systems: instead of writing a separate connector for every model, app, API, database, and workflow, you expose a stable MCP interface once and let compatible hosts such as Claude, Cursor, VS Code, or other MCP clients discover and use it. Developers, AI engineers, platform teams, and technical founders should consider MCP when an AI assistant needs controlled access to live data or safe actions outside the chat window.

The simplest way to think about it: a REST API is built for software to call; an MCP server is built for an AI host to understand what it can read, what it can do, and how to ask for it safely.

MCP does not replace your application, database, API gateway, or authentication system. It sits between an AI application and those systems. A good MCP server translates a small, well-governed set of capabilities into protocol messages the AI host can inspect, approve, call, and audit.

Why MCP Exists

Before MCP, connecting AI assistants to real systems usually meant building one-off integrations. A team might build one connector for Claude, another for an IDE, another for an internal agent, and another for a separate workflow runner. Each connector had to solve the same problems again: authentication, tool descriptions, schema validation, error handling, permission boundaries, logs, and user approval.

That does not scale. It creates the classic many-to-many integration problem:

Anthropic introduced MCP as an open standard for connecting AI assistants to the systems where data lives. The official MCP documentation now describes it more broadly as an open-source standard for connecting AI applications to external systems including data sources, tools, and workflows.

That scope matters. MCP is not only about "function calling." Function calling is a model/API feature. MCP is an integration protocol: it defines how a host and server negotiate capabilities, exchange messages, discover available actions, retrieve context, handle transports, and apply trust boundaries.

Core Terms: Host, Client, Server

MCP uses words that sound familiar but mean specific things in the protocol.

The official architecture docs make one detail especially important: a host can connect to multiple MCP servers, and each connection is maintained by a separate MCP client instance. "MCP server" refers to the program that serves context and capabilities, regardless of whether it runs locally on the user's machine or remotely on the internet.

MCP Architecture

At a high level, the user talks to an AI host, the host uses an MCP client to talk to an MCP server, and the server talks to the outside systems it owns or wraps.

flowchart TD
  U[User] --> H[AI host<br/>Claude, Cursor, VS Code, internal agent]
  H --> C[MCP client<br/>one connection per server]
  C --> S[MCP server<br/>tools, resources, prompts]
  S --> API[External APIs]
  S --> DB[(Databases)]
  S --> FS[Files and documents]
  S --> SaaS[Third-party services]

The server is the boundary you design. It decides which operations are exposed, how inputs are validated, which credentials are used, what gets logged, and which actions require approval. The host decides how to show capabilities to the user and model, how to ask for consent, and how to route requests to the right server.

How an MCP Server Works

MCP has two conceptual layers:

• The data layer defines JSON-RPC messages, lifecycle, capability negotiation, tools, resources, prompts, notifications, progress, and errors.
• The transport layer defines how those messages move between client and server, including stdio for local processes and Streamable HTTP for networked servers.

A normal connection follows this shape:

1. The host creates an MCP client for a configured server.
2. The client starts a local process or connects to a remote endpoint.
3. The client sends initialize with the protocol version and client capabilities.
4. The server replies with its supported protocol version, server info, and capabilities.
5. The client sends an initialized notification.
6. The client discovers tools, resources, and prompts with list methods such as tools/list, resources/list, and prompts/list.
7. The host decides what context to include and which tool calls need user approval.
8. The client sends requests such as tools/call or resources/read.
9. The server validates the request, calls the underlying system, and returns structured results or errors.

sequenceDiagram
  participant Host as AI Host
  participant Client as MCP Client
  participant Server as MCP Server
  participant System as API / DB / Service
  Host->>Client: Configure server
  Client->>Server: initialize
  Server-->>Client: capabilities + serverInfo
  Client->>Server: notifications/initialized
  Client->>Server: tools/list, resources/list, prompts/list
  Server-->>Client: available capabilities
  Host->>Client: User-approved request
  Client->>Server: tools/call or resources/read
  Server->>System: Validate and execute
  System-->>Server: Result
  Server-->>Client: JSON-RPC result or error
  Client-->>Host: Context or tool output

The lifecycle is stateful. The client and server negotiate a protocol version and capabilities before normal operation. During operation, both sides are expected to respect only the capabilities that were successfully negotiated. Implementations should also configure request timeouts so a hung server does not block the host indefinitely.

MCP Uses JSON-RPC 2.0

MCP messages are encoded as JSON-RPC 2.0. JSON-RPC is a lightweight remote procedure call protocol with request, response, notification, and error objects. MCP uses those message shapes but defines MCP-specific methods such as initialize, tools/list, tools/call, resources/list, resources/read, prompts/list, and prompts/get.

A simplified tool discovery request looks like this:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

A simplified response might include tool names, descriptions, input schemas, and metadata:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "search_issues",
        "description": "Search open engineering issues",
        "inputSchema": {
          "type": "object",
          "properties": {
            "query": { "type": "string" }
          },
          "required": ["query"]
        }
      }
    ]
  }
}

The key point is not the syntax; it is the contract. An MCP server gives the host enough structure to discover what exists, decide when it is relevant, validate inputs, and return results in a predictable form.

Tools, Resources, Prompts, and Sampling

Most confusion about MCP servers comes from treating every capability as a "tool." The protocol is more precise.

Tools let a model perform actions through the server. The tools spec says tools are intended to be discoverable and invokable by language models, but host applications should still provide human review and confirmation for sensitive operations.

Resources expose context. They are identified by URIs and can represent files, database schemas, application records, logs, or other data. A resource is usually better than a tool when the model only needs to read information.

Prompts expose reusable interaction templates. They are normally selected by the user through UI commands or similar host patterns.

Sampling is different: it is a client feature. It lets an MCP server request an LLM generation from the client while the client keeps control over model access, model selection, and user permissions. In the 2025-11-25 specification, sampling also gained tool-calling support when the client declares the appropriate capability.

For a deeper split between read-only context and executable functions, see MCP resources vs tools.

MCP Server vs REST API

An MCP server often wraps one or more REST APIs, but it is not the same thing as a REST API.

Build a REST API when you need a durable software interface for applications. Build an MCP server when an AI host needs to discover, reason about, and safely invoke a curated set of capabilities.

In practice, many production MCP servers sit on top of REST APIs. They translate broad application endpoints into smaller, safer, model-readable capabilities. For example, a CRM API may have dozens of endpoints, but the MCP server might expose only find_customer, summarize_account, and create_follow_up_task.

MCP Server vs OpenAPI

OpenAPI is also not the same thing as MCP. The OpenAPI Specification defines a standard, programming-language-agnostic description for HTTP APIs so humans and computers can understand a service without reading source code or inspecting traffic. It describes an HTTP API; it does not by itself define an AI host connection, tool approval flow, prompt templates, or resource subscriptions.

OpenAPI is extremely useful when building MCP servers from existing APIs. A good generator can inspect paths, schemas, auth, and descriptions, then propose MCP tools. But the generated server still needs editorial and security review. Not every HTTP operation should become an MCP tool, and many API descriptions need clearer tool names and parameter descriptions for model use.

For implementation details, see the OpenAPI to MCP guide.

MCP Server vs AI Plugin

"AI plugin" is a broad product term. MCP is a protocol with a specific client-server architecture.

If you are integrating with one vendor's app store, a plugin may be enough. If you want the same capability to work across multiple MCP-compatible environments, use MCP.

Local vs Remote MCP Servers

MCP servers can run locally or remotely.

Local servers usually use stdio. The host launches the server as a subprocess, sends JSON-RPC messages to its stdin, and reads responses from stdout. The current spec says stdout must contain only valid MCP messages; logs should go to stderr.

Remote servers usually use Streamable HTTP. The server runs independently and exposes a single MCP endpoint that supports HTTP POST and GET. Streamable HTTP replaced the older HTTP+SSE transport in the 2024-11-05 protocol line, although some clients still support SSE for compatibility.

For local setup patterns, see the Claude MCP setup guide. For implementation examples, see the Next.js MCP server tutorial.

When Should You Build an MCP Server?

Build an MCP server when the AI assistant needs controlled access to systems beyond the conversation. Strong scenarios include:

• A support team wants an assistant to look up tickets, customers, invoices, and internal runbooks.
• Developers want an IDE agent to read issue trackers, inspect logs, query feature flags, and open pull requests.
• An internal operations agent needs to trigger safe workflows such as creating tasks, drafting emails, or summarizing incidents.
• A data team wants natural-language access to curated warehouse queries without giving unrestricted SQL access.
• A SaaS company wants customers to connect Claude, Cursor, or another MCP host to their product.
• A platform team wants a standard integration layer instead of maintaining separate connectors for every AI client.

The strongest MCP servers have a clear domain boundary. "GitHub repository operations for one organization" is a good boundary. "Everything our company can do" is usually too broad.

When You Probably Do Not Need One

MCP is powerful, but it is not always the right answer.

You probably do not need an MCP server if:

• The assistant only needs static documentation that can be pasted, indexed, or retrieved another way.
• A normal API integration between two deterministic services is enough.
• The workflow should never be initiated by an AI model or agent.
• The action is too risky to expose without a mature permission and approval system.
• The API is unstable and the team cannot maintain tool contracts.
• You only need a one-off script for a private task.

Do not build an MCP server just because MCP is available. Build one when the protocol gives you a real benefit: cross-host compatibility, dynamic discovery, structured tool invocation, safer user approval, or clearer governance over model-accessible capabilities.

Common MCP Server Use Cases

The most common MCP server patterns are practical and domain-specific:

When deciding how many servers to run, align boundaries with ownership, risk, and permissions. A single server with 80 unrelated tools is hard for both humans and models to reason about. A fleet of tiny servers can also become operational noise. The practical middle ground is covered in how many MCP servers you should run.

Security Considerations

The official specification is blunt about the security model: MCP enables arbitrary data access and code execution paths, so implementers must address trust, consent, and control. The protocol can define messages and capabilities, but it cannot magically make unsafe tools safe.

Security work should start before implementation:

For HTTP transports, the MCP authorization spec is based on OAuth 2.1-related standards, protected resource metadata, authorization server metadata, dynamic client registration, and newer client ID metadata documents. For stdio transports, the spec recommends retrieving credentials from the environment rather than following the HTTP authorization flow.

For broader deployment controls, read MCP security best practices and running MCP in production. If OAuth discovery fails during implementation, the OAuth metadata troubleshooting guide is the most relevant next step.

Performance Considerations

MCP performance problems usually come from tool design, not JSON-RPC itself.

Watch these areas:

• Tool count: too many similar tools make selection harder and increase discovery noise.
• Tool descriptions: vague descriptions cause wrong calls and retries.
• Latency: remote servers add network time, authentication checks, downstream API calls, and sometimes SSE streaming.
• Payload size: large tool results can overwhelm context windows and slow model reasoning.
• Timeouts: every request should have a timeout, and long-running work should report progress or use a durable task pattern where supported.
• Pagination: list methods and large data reads should support pagination or filtering.
• Caching: stable resources such as schemas and docs can often be cached.
• Concurrency: tools that mutate state need idempotency keys, locking, or conflict handling.

A good MCP server returns the smallest useful result. Do not dump an entire CRM account, database table, or log file when the model asked for a summary or a filtered record. Prefer tools that accept precise filters and resources that expose bounded context.

Production Best Practices

Production MCP servers are integration infrastructure. Treat them like any service that can read sensitive data and trigger business actions.

Before launch, run a practical checklist:

• Define the server's domain boundary.
• Decide which tools are read-only, write-capable, or destructive.
• Require approval for irreversible actions.
• Validate every input schema.
• Enforce authorization in the server, not only in the host UI.
• Use least-privilege credentials for every downstream system.
• Add structured audit logs.
• Test tool discovery, invalid inputs, timeouts, and auth failures.
• Document what each tool can and cannot do.
• Monitor latency, error rate, tool usage, and rejected approvals.

For validation workflows, use the official MCP Inspector during development and a broader test MCP server guide before production.

Common Mistakes

The most common MCP mistakes are design mistakes:

1. Exposing your API too literally. A one-to-one API wrapper often creates too many unsafe or confusing tools.
2. Making tools too broad. admin_action is not a safe contract; archive_completed_project is easier to reason about.
3. Treating resources as tools. If the model only needs to read context, expose a resource.
4. Skipping authorization because the server is "only for internal use."
5. Trusting external content returned by tools.
6. Returning huge payloads instead of concise structured results.
7. Forgetting that tool descriptions influence model behavior.
8. Not testing with the real host that users will use.
9. Running local stdio servers from untrusted repositories without code review.
10. Changing tool names or schemas without migration planning.

If you are debugging client-specific connection behavior, start with official client logs. For Cursor-specific setup and failure patterns, see Cursor MCP connection troubleshooting.

The Short Decision Guide

Use this decision path:

flowchart TD
  A[Does the AI assistant need live data or actions?] -->|No| B[Use docs, retrieval, or normal chat context]
  A -->|Yes| C[Is there already a safe API or service boundary?]
  C -->|No| D[Design the service/API boundary first]
  C -->|Yes| E[Can the actions be scoped and audited?]
  E -->|No| F[Do not expose them to MCP yet]
  E -->|Yes| G[Build a narrow MCP server]
  G --> H[Test with Inspector and target hosts]
  H --> I[Deploy with auth, approvals, logs, and monitoring]

An MCP server is worth building when it creates a safer, reusable bridge between AI systems and real operational capabilities. It is not worth building when it hides unclear permissions behind a shiny tool list.

Official References

• Model Context Protocol introduction
• Model Context Protocol specification, 2025-11-25
• MCP key changes for 2025-11-25
• MCP architecture overview
• MCP lifecycle specification
• MCP transports specification
• MCP authorization specification
• MCP tools specification
• MCP resources specification
• MCP prompts specification
• MCP sampling specification
• Model Context Protocol GitHub organization
• Anthropic: Introducing the Model Context Protocol
• Claude Code MCP documentation
• Cursor MCP documentation
• MCP Inspector documentation
• JSON-RPC 2.0 specification
• OpenAPI Specification