What Is the Model Context Protocol (MCP)? A Plain Guide

If someone senior has asked you to "have a view on MCP" by Friday, this is for you. It explains what the Model Context Protocol is, how its parts fit together, when it earns its place and what it leaves for you to sort out. No code is needed to follow it.

The short version: MCP is a standard way to connect AI applications to tools and data, so that each connection is built once and can be reused. The quotations come from my book The MCP Field Guide.

The problem MCP solves is multiplication

Every integration problem is secretly a multiplication problem. Suppose there are five AI applications your organisation cares about and twenty systems you want them to reach. If each application integrates with each system on its own terms, you need a hundred integrations. Each will be written by a different person, in a different style, with a different idea of what an error looks like. Each will break on its own schedule.

With a shared protocol, the sum replaces the product. Each of the five applications learns to speak the protocol once, and each of the twenty systems gets one server. That is twenty-five pieces of work, not a hundred.

Integration cost grows with the product of your choices. Standards make it grow with the sum.

It helps to remember what came before. Language models learned to call functions some time before MCP existed. You described a function with a name, a sentence of explanation and a JSON Schema for its arguments. The model replied with a structured request to call it, your code ran the function and fed the answer back. This still works, and it is exactly what happens underneath MCP. What the protocol adds is a common shape, so the description of a tool written for one application can be used by another.

The history is short. Anthropic published MCP as an open specification in November 2024, with SDKs and a handful of reference servers for things like filesystems, Git and databases. By December 2025 it had moved to Linux Foundation governance.

Three roles: host, client and server

MCP has three roles, and nearly every confusion about it comes from blurring two of them.

The host is the application the person actually uses. It holds the conversation, the model and the user's wishes. A client lives inside the host and carries messages, and there is one client per server. A server offers capabilities from some outside system, such as a database or a set of files.

A line from the guide makes the split easy to hold in your head: the host is the diplomat, the client is the phone line, the server is the specialist on the other end.

The single most useful fact about MCP is also the one most often misunderstood. The model never calls a tool. The model only talks. When people say "the model searched the database", what actually happened is that the model produced some text saying, in a structured way, that it would like the search tool to be called with these arguments, and a piece of ordinary software decided whether to do it.

That piece of software is the host, which is why the host matters so much. Every decision that involves trust, the user's wishes or the model's behaviour belongs to it. Servers provide capabilities. Clients carry messages. The host decides what actually happens.

What a server offers, and where it runs

A server can offer three kinds of thing, and almost everything you will ever build fits into one of them.

Tools are verbs. A tool is the unit of action. It has a name, a description in natural language explaining what it does and when it is useful, and an input schema describing the arguments it accepts. The model decides when to reach for one.

Resources are nouns. A resource is a piece of data a server makes available, identified by a URI: files, documents, records, logs, schemas, configuration. If tools are what a model can do, resources are what it can know. The application decides which ones are placed in front of the model.

Prompts are recipes. A prompt is a named, reusable template that a server offers and a user chooses to run.

The three are distinguished less by what they contain than by who decides to use them: the model reaches for tools, the application places resources, and the person chooses prompts. Once that clicks, a lot of design questions answer themselves.

One practical point follows from the tool definition. The model cannot read your code. It reads your names and descriptions, and chooses between tools the way a tired traveller chooses a door in an unfamiliar station: by reading the signs. Tool descriptions are not documentation. They are prompts.

As for where it runs, an MCP server can live in two places, and the choice shapes nearly everything else about it: how it starts, how it authenticates, who maintains it and what it can reach.

A local server runs on your own machine. The host launches it as a child process and talks to it over standard input and output, usually written stdio. No network, no ports, no authentication handshake. Just a pipe, which is how programs have talked to each other for half a century.

A remote server runs somewhere else and is reached over a transport called Streamable HTTP: one endpoint, ordinary requests, and streaming only when there is something to stream.

In short, local servers are tools you carry, and remote servers are services you visit.

When MCP is worth using

MCP is not required for a model to use a tool. Plain function calling works. So the useful question is when the protocol pays for itself.

It is worth using when the multiplication has started. If more than one AI application needs to reach the same system, or one application needs to reach many systems, a server written once saves the repeated glue. It is also worth using when someone else has already done the work. For any system you want to connect, there are three ways to get a server: build one yourself, use one provided by the system's vendor, or borrow one from the community. A sensible order is to look for a vendor server first, then a vetted community one, and only then build something small.

It is less obviously worth it when you have one application, one system and no plans for more. The function call you already have is doing the same job underneath.

If you do build a server, the most common mistake happens before any code is written. Someone looks at an existing REST API with sixty endpoints and decides the server should expose sixty tools, one for each. It feels thorough. It produces a server that models use badly and humans cannot review. Design for the question the user is asking, not for the database.

What MCP does not do for you

Every successful technology attracts claims it never made, and the main one here is that a standard connection is a safe connection.

A protocol tells you how to speak. It cannot tell you whom to trust.

The threat model fits in one sentence: every server is a stranger, and everything a stranger says is data, not instructions. The difficulty is that a model reads everything as advice. An attacker can place instructions in content the model will read, such as a web page fetched by a tool, and the model may follow them as if they came from the user. This is prompt injection, and tools widen the door through which it arrives.

There is a rule of thumb worth memorising. An agent becomes dangerous when it has three things at once: access to private data, exposure to untrusted content, and a way to send information out. The programmer Simon Willison popularised a name for this combination, the lethal trifecta. With any two of them you have a tool. With all three, someone else has an opportunity.

Human approval is the backstop, and it has its own weakness. Ask too often, and people stop reading.

A prompt nobody reads is not a control. It is a ritual with a button.

So the protocol gives you the plug. Deciding which servers to trust, how much access each gets and when a person must be asked remains your job.

What to take from this

• MCP is a standard way to connect AI applications to tools and data, so each connection is built once.
• The model never calls a tool. It asks, and the host decides.
• Servers offer tools (verbs), resources (nouns) and prompts (recipes).
• Local servers run on your machine over stdio. Remote servers are reached over HTTP.
• Use MCP when several applications or several systems are involved. For one of each, plain function calling may be enough.
• Treat every server as a stranger: vet it, give it a small key, choose when to ask the user, and keep watching.

If you want the full version, The MCP Field Guide: Connecting models to the world, one server at a time goes from first principles to building, securing, shipping and governing servers, in 100 short chapters with a labelled diagram in each. It is a 314-page PDF and costs £9 on Gumroad: https://matsiems.com/books/the-mcp-field-guide.