What is an MCP server?

The problem MCP solves

Before the Model Context Protocol, connecting an AI assistant to an external system meant writing an integration specific to that assistant. Ten tools across four assistants was forty integrations. Each vendor had its own plugin format, its own auth model and its own lifecycle.

MCP, released by Anthropic in November 2024, replaces that with one protocol. A server describes what it offers; a client discovers and calls it. The N-times-M problem becomes N plus M.

What a server exposes

MCP servers offer three kinds of capability, and the distinction matters when designing one:

Tools are functions the model may call, each with a typed schema of arguments. A tool does something — queries a database, files a ticket, sends a request. Because the model only sees the schema and description, a vague description is the single most common cause of wrong calls.

Resources are data the client can read — files, records, documents. Resources are addressed by URI and are meant to be read, not executed. Putting a side effect behind a resource is a design error.

Prompts are reusable templates the server offers, so common interactions do not have to be re-derived by every user.

How a connection works

1. The client launches or connects to the server over a transport — stdio for a local process, HTTP for a remote one.
2. Client and server perform capability negotiation, agreeing which features each supports.
3. The client asks what tools, resources and prompts exist.
4. The client surfaces those to the model, which may then request a tool call.
5. The client executes the call, returns the structured result, and the model reasons over it.

Note where control sits: the model never calls a tool directly. It asks the client to, and the client decides whether to comply. That indirection is the whole basis of MCP's security model.

Security: the part people skip

An MCP server is code running with real credentials, and tool results flow straight back into a model's context. Two consequences follow.

Tool output is untrusted input. If a tool returns text containing instructions, and your system treats model context as authoritative, you have a prompt injection vulnerability. Retrieved content and tool results are data — never instructions.

Scope credentials to the server, not the user. A server with a full-access API key gives every connected model that access. Issue narrow, revocable credentials per server.

Add an approval gate for anything irreversible. Reading a calendar and deleting a production table should not have the same trust level.

When to build one

Build an MCP server when a capability needs to be reachable from more than one assistant, or when you want it maintained independently of any product. If a capability is used by exactly one application and always will be, a direct integration is simpler and has fewer moving parts.

The ecosystem is young — the protocol stabilised through 2025 and 2026 — which cuts both ways. Conventions are still forming, and there is correspondingly little competition for attention in the space.