What Is an MCP Server? The Model Context Protocol Explained

Quick answer

An MCP server is a program that gives AI applications access to tools, data and reusable prompts through the Model Context Protocol (MCP), an open standard Anthropic introduced in November 2024. An AI app such as a chat assistant or code editor connects to the server through an MCP client, discovers what the server offers, and calls it using JSON-RPC 2.0 messages.

What is MCP (Model Context Protocol)?

MCP, short for Model Context Protocol, is an open protocol that standardizes how AI applications connect to external data sources and tools. Anthropic's announcement described it as "a new standard for connecting AI assistants to the systems where data lives". At launch, Anthropic shared pre-built servers for Google Drive, Slack, GitHub, Git, Postgres and Puppeteer.

"Context" is the information a large language model works with when it answers: files, records, search results and action results. A model only knows what reaches its context window. MCP gives applications a common way to fetch that information and to let the model act, without a custom connector for every pairing. The specification says the design takes inspiration from the Language Server Protocol, which standardized how code editors add support for programming languages.

An AI agent is only as useful as the systems it can reach, which is why MCP is central to the AI agents topic. The glossary keeps a short Model Context Protocol definition.

The problem MCP solves: M×N integrations

Without a shared protocol, connecting M AI applications to N tools or data sources takes up to M×N custom integrations, each built and maintained separately. Anthropic's announcement made the same point, noting that each new data source required a bespoke implementation, which made connected systems hard to scale.

MCP turns that into an M+N problem. Each AI application implements an MCP client once, and each data source or service implements an MCP server once. Any compliant client can then talk to any compliant server. A team that builds one MCP server for its ticket system can use it from every MCP-capable assistant, IDE or agent it adopts.

MCP is not a workflow engine. Automation platforms such as n8n orchestrate multi-step processes across apps, a category covered under AI workflow automation. MCP standardizes something narrower: how an AI application discovers and uses one server's capabilities.

How MCP works: hosts, clients and servers

MCP defines three roles, according to the specification:

• Host: the AI application the user works in, such as a chat assistant, an IDE or an agent runtime. It manages the model, the interface and user consent.
• Client: a connector inside the host. Each client talks to one server.
• Server: a service that provides context and capabilities. It can run locally on the user's machine or remotely as a web service.

Host (chat assistant, IDE or agent)
 ├─ MCP client A ──► MCP server: file system   (local, stdio)
 ├─ MCP client B ──► MCP server: database      (local, stdio)
 └─ MCP client C ──► MCP server: SaaS API      (remote, Streamable HTTP)

The host asks each server what it offers, passes relevant capabilities to the model and, when the model picks one, sends the request through the matching client and returns the result. Servers can also ask the host to collect extra information from the user, a client feature the specification calls elicitation.

Server primitives: tools, resources and prompts

An MCP server exposes three kinds of capability. The specification distinguishes them by who controls their use.

Tools are listed with tools/list and invoked with tools/call. Each tool has a name, a description and a JSON Schema for its inputs, which tells the model which arguments to supply. This is the same idea as tool calling in model APIs; MCP adds a standard way to discover and run tools across applications.

Resources are data identified by URIs, listed with resources/list and fetched with resources/read. The specification mentions schemes such as file:// and git://, and servers may define custom ones. Resources suit context that the application or user selects, such as a document or a table schema.

Prompts are reusable templates, listed with prompts/list and retrieved with prompts/get, often surfaced as slash commands. They package proven instructions; the prompt engineering guide covers how to write good ones.

Transports and JSON-RPC 2.0

All MCP messages use JSON-RPC 2.0, a lightweight remote-procedure-call format. A request names a method, carries params and has an id; the response echoes the id with either a result or an error. A notification is a request without an id, and it gets no response.

The specification defines two standard transports:

• stdio: the client launches the server as a subprocess and exchanges newline-delimited JSON-RPC messages over standard input and output. The server may write logs to standard error. It suits local servers.
• Streamable HTTP: the server exposes a single HTTP endpoint. The client sends each message as an HTTP POST, and the server answers with a JSON response or a Server-Sent Events stream. It suits remote, shared servers and replaced the earlier HTTP+SSE transport, deprecated since the 2025-03-26 revision.

Specification revisions are named by date. Revisions up to 2025-11-25 open each session with an initialize handshake that agrees on a protocol version and capabilities. The 2026-07-28 revision removes that handshake: each request carries its protocol version and capabilities, and servers advertise what they support through a server/discover method.

Example: an MCP server for a database

Picture a read-only MCP server for an orders database. It exposes one tool, query_orders, that runs SQL SELECT statements; a resource holding the table schema; and a prompt called weekly_summary. Asked how many orders were refunded, the host passes the tool list to the model, the model chooses the tool, the host asks the user to approve, and the client sends the call. The messages below are simplified: fields that vary by specification revision, such as request metadata, are omitted.

The server describes its tool in reply to tools/list:

{"jsonrpc": "2.0", "id": 1, "result": {"tools": [{
  "name": "query_orders",
  "description": "Run a read-only SQL SELECT on the orders database.",
  "inputSchema": {"type": "object",
    "properties": {"sql": {"type": "string"}}, "required": ["sql"]}
}]}}

The client invokes it, and the server returns content for the model:

{"jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": {
  "name": "query_orders",
  "arguments": {"sql": "SELECT count(*) FROM orders WHERE status = 'refunded'"}}}

{"jsonrpc": "2.0", "id": 2, "result": {
  "content": [{"type": "text", "text": "count: 42"}], "isError": false}}

If the query fails, the server should still return a result with isError set to true and a readable message, so the model can correct itself; protocol problems such as an unknown tool name come back as JSON-RPC errors. A file system server works the same way, exposing files as file:// resources and tools that read or write within approved directories.

MCP security: prompt injection, tool poisoning and least privilege

An MCP server is code that reads data and takes actions for a model. The specification's principles are user consent and control, data privacy and tool safety. It states that the protocol cannot enforce them itself; implementers must.

• Prompt injection. Content a server returns, such as an email, web page or ticket, can contain instructions the model may follow. The specification tells clients to validate tool results before passing them to the model and servers to sanitize tool outputs. Treat returned text as data, never as commands.
• Tool poisoning. The model reads tool names and descriptions, which users rarely see in full. A malicious or compromised server can hide instructions there or change its definitions after installation. The specification says tool annotations must be treated as untrusted unless they come from a trusted server. Install servers from publishers you trust, review descriptions and pin versions.
• Least privilege. Give each server the narrowest access that works: a read-only database user, a short list of approved folders, scoped API tokens. The specification requires servers to validate inputs, apply access controls and rate-limit tool calls, and recommends that hosts show tool inputs and ask for confirmation on sensitive operations.
• Local exposure. A stdio server runs with your user's permissions. HTTP servers must validate the Origin header, and local ones should bind only to localhost, to block DNS rebinding attacks from websites.
• Authorization. Authorization is optional, but HTTP-based servers that use it follow an OAuth 2.1-based framework in which the server acts as a resource server and checks that each token was issued for it. The specification is blunt about everything else: "MCP servers MUST NOT accept or transit any other tokens." Stdio servers take credentials from the environment instead.

Servers that employees install without approval are shadow AI; an MCP allowlist belongs in any AI governance program.

How to evaluate an MCP server

Before connecting a server to real data, check:

1. Publisher and code. Who maintains it, is the source public, and is it actively updated?
2. Permissions. Which credentials does it need, and can they be scoped to read-only?
3. Where data goes. Does it run locally over stdio or remotely, and who operates the remote side?
4. Authorization. Does a remote server use OAuth-based authorization or a long-lived static key?
5. Tool design. Are tools narrow and clearly described, with destructive actions separated from read-only ones?
6. Protocol support. Which specification revisions does it support, and does your host support the same?
7. Audit and approval. Does your host log tool calls and ask for confirmation before sensitive actions?

Tool definitions and results also consume tokens; the LLM cost calculator estimates the bill. To find tools, browse Discover or describe your use case in Mindber Ask; to pick the model that drives them, compare options on the Model Arena leaderboard.

Frequently asked questions

Method: editorial analysis of the MCP specification, Anthropic's announcement and the JSON-RPC 2.0 specification, compiled on 2026-10-18. Mindber ran no MCP servers for this article; the example is illustrative.