What is an MCP server and what is it for?

Quick answer

An MCP server is a service that exposes its operations as tools a language model can call directly, following the Model Context Protocol, an open standard. The difference from a regular API is not what it does but who reads it: an API is integrated by a developer writing code, while an MCP server is discovered by the agent itself at runtime, complete with each tool's description and argument schema.

The problem it solves, before the definition

A language model on its own is a system that produces text. It knows a great deal and can do nothing. Ask it how much you spent on groceries last month and it does not know: it has no access to your data, and the best it can do is ask you to paste some in.

For a couple of years the workaround was integrating each service by hand. Somebody wrote code translating between the model and one specific API, decided which functions to expose, wrote the descriptions, and maintained all of it whenever either side changed. It worked, but it did not scale: every agent-plus-service combination was fresh work. With ten agents and ten services you do not have twenty pieces to maintain, you have a hundred.

MCP is the standard that breaks that multiplication. The service publishes a server once, describing its tools in a way any compatible agent understands. The agent, on its side, learns the protocol once. From then on either side connects to the other with no bespoke code.

What an MCP server actually contains

When an agent connects, the first thing it does is ask what is available. The server answers with a catalogue of tools, and each one carries three things.

A name, in the style of create_gasto or list_gastos, which is how the agent invokes it.

A natural-language description, and this is the most underestimated part. The agent has no documentation and no examples: that text is literally everything it knows about when to use the tool and what to expect. A well-built server documents the business rules the schema cannot express — that the line items must add up to the total, which sign each kind of movement takes — because otherwise the agent discovers them by getting them wrong.

An argument schema in JSON Schema, defining which fields are accepted, which are required and of what type. That lets the client validate before calling rather than discovering the error on the far side.

With those three things, an agent that has never seen your service can work out on its own that answering "how much have I spent this month?" means calling the list-expenses tool with a date range, and get it right first time.

How it differs from an ordinary API

The most common confusion is thinking MCP replaces REST APIs. It does not: it almost always sits on top of them.

The difference is the audience. A REST API is designed to be read by a person and integrated in code; its documentation lives on a separate website, and when it changes somebody has to notice and update the client. An MCP server is designed to be read by a model at the moment of use; the documentation travels inside the catalogue itself, so when the server adds a tool the agent sees it on the next connection without anyone touching anything.

There is a second difference, less discussed and more important in practice: MCP brings permissions and consent as a first-class idea. A typical API key is all or nothing. A well-designed MCP server exposes which permission each tool requires, and the client can announce, before executing, whether an operation is read-only or destructive, so the user can confirm.

The same idea, with a concrete case

It is worth bringing this down to earth, because in the abstract it all sounds like a diagram.

ControlarGastos — an application for tracking shared expenses between couples, flatmates or groups — publishes an MCP server at https://controlargastos.es/api/mcp. Connect an agent there with a token of yours and it discovers tools to create an expense, list the month's, check who owes what to whom, look at a budget or confirm a debt.

From that point, "log today's shopping, forty-three euros, and tell me how the month is going" stops being a request the agent cannot serve. It calls the create tool, then the summary tool, and answers with real figures. Nobody wrote an integration for that: the agent read the catalogue and decided.

It works just as well in reverse. If the token you handed over is read-only, the agent sees the create tool in the catalogue, tries it, and gets refused by the server. The permission check happens before anything executes, not somewhere inside the tool's own logic.

What an MCP server does not fix

Worth saying, because the industry's enthusiasm tends to forget it. An MCP server does not make the model more accurate: if the agent misreads what you asked for, it now gets it wrong with more reach, not less. It does not replace an interface: some tasks are simply better done looking at a screen. And it is not secure by default: a server exposing write operations with no granular permissions, no origin verification and no rate limiting is an attack surface, not a feature.

That last part is where a serious MCP server parts company with one built in an afternoon, and it deserves its own article.

Frequently asked questions

Is MCP an Anthropic thing?

The protocol was published by Anthropic as an open standard, and today clients and services from various vendors implement it. You do not need a particular model to connect to an MCP server.

Is an MCP server the same as an API?

No, although it almost always sits on one. An API is integrated by a developer writing code; an MCP server is discovered by the agent at runtime, reading each tool's description and schema.

What is the difference between a local and a remote MCP server?

A local one runs on your machine and the client launches it as a process. A remote one lives on a server and is reached over HTTP with a URL, which is what lets you use it from several devices without installing anything.

Do I need to be a programmer to use one?

To use one, no: you add it with a command or from your client's connector panel. To publish one, yes.

Can an MCP server do things I have not authorised?

It can do whatever you granted permission for, which is exactly why the token's permissions are worth reading before you connect it. Serious clients also ask for confirmation before running operations flagged as destructive.