What an MCP server is, in plain terms

A program that gives an assistant something to act on

An MCP server is a small program that an AI client connects to so the model can do things outside the conversation: read a file, run a database query, open a ticket. The Model Context Protocol is the shared format for that connection. The server describes what it offers, the client lists it for the model, and when the model asks to use something, the server does the work and returns the result.

Without one, an assistant can only discuss what you paste into the chat. With one, it can go and fetch the thing itself, and sometimes change it. That second part is why the rest of this post spends as long on what a server can touch as on what it is.

Tools, resources and prompts

A server can offer three kinds of thing. Tools are actions with inputs, such as a search, a query or a write, and they are what most people mean when they talk about MCP. Resources are pieces of data the client can read, like the contents of a document. Prompts are prepared instructions a server ships for a common task, which the person using the client can pick from a list.

Most servers in practice are mostly tools. A server for a code host might offer tools to list issues, read a file and open a pull request. A server for a database might offer one tool that runs a query and another that describes the tables. The names and descriptions of those tools are written by the server's author, and the model reads them to decide when to call each one.

That last fact matters more than it looks. The model chooses a tool from its description, so a vague or misleading description leads to the wrong call. Reading the tool list before installing anything is the cheapest check there is.

Where the server runs and who it acts as

Some servers run on your own machine as a local process the client starts. Others run somewhere else and the client connects over the network. A local server can usually reach whatever your user account can reach, which on a laptop is a great deal. A remote one reaches whatever its operator has given it, plus whatever you hand it when you connect.

In both cases the server acts with a credential: an API key, a token, a database password or a session you signed in with. The server does not have permissions of its own. It borrows yours. A server given a token that can delete repositories can delete repositories, whatever its README says it is for.

This is the single most useful way to think about any server: list what it can reach, then list what the credential you gave it allows on each of those. The overlap is what the model can do.

Why there are so many of them

Because the protocol is shared, a server written once works with any client that speaks it. That made writing one cheap, and the result is a very large number of public repositories, many of them small wrappers around a single API, some of them copies of a starter template with nothing changed.

The MCP server directory publishes those that pass its checks (servers on record: 8,106), each read from its own repository, with what it reaches and the credential it asks for set beside the name. It also says how many repositories it read and why the rest were held back, so the number means something.

How an MCP server differs from an agent skill

An agent skill is a set of written instructions a model loads, usually a file with a short description at the top and guidance below. It connects to nothing and asks for no key. A server is a running program with access to something real. The two are often mentioned together and they carry very different risks.

The skills directory lists skills (count on record: 3,022) apart from the servers for exactly that reason. A reader deciding whether to install something needs to know first whether it hands a model a key to anything. For a wider view of the agent tooling around both, the agents layer groups the frameworks and products.

What happens during a single tool call

Take a request typed into a coding agent: find the open issues labelled bug and list them. The client has already connected to a server for the code host, and that server told the client at startup which tools it has, with a name, a description and the shape of the inputs each one takes. The model reads those descriptions alongside the request and decides that a tool for listing issues fits.

The model does not call the code host itself. It produces a structured request naming the tool and its arguments, the client passes that to the server, and the server makes the real call to the code host using the token it was configured with. The result comes back to the client as text or data, and the model reads it and writes the answer you see.

Two things follow from that sequence. The model only ever sees what the server returns, so a server that returns too much puts too much into the conversation. And the server, not the model, holds the token, so the token's limits are the real limits. A client may ask you to approve a call before it runs, and that approval is only as useful as your attention to the arguments in it.