The Model Context Protocol is a standard way for an AI application to talk to the tools and data outside it. That is the whole idea. The reason it exists is less obvious and more interesting.
Before a standard, every integration was a pair. If you wanted an assistant to read your database, somebody wrote a database integration for that specific assistant. If you then wanted a second assistant to read the same database, somebody wrote it again. With a handful of assistants and a handful of data sources, you are writing one integration per combination, and the number of combinations grows by multiplication rather than addition.
MCP turns that multiplication into addition. A data source is wrapped once, as a server. A client implements the protocol once. Any client can then talk to any server. It is the same shape of idea as a device driver or a database connection standard, and it is unglamorous in exactly the same way.
The pieces and their names
The vocabulary is small. Getting it straight early saves a lot of confusion later.
| Term | What it is | Example |
|---|---|---|
| Host | The application the user is actually using | Claude Desktop, an IDE, your own agent app |
| Client | The part inside the host that speaks the protocol | One client connection per server |
| Server | The thing that exposes capabilities to the model | A wrapper around a database, a filesystem, or a scraping API |
| Tool | An action the model can choose to take | run_scraper, search_products, send_email |
| Resource | Data the client can read and put into context | A file, a record, a document |
| Prompt | A reusable, parameterised instruction the user can invoke | A "review this PR" template the server supplies |
The distinction that matters: tools versus resources
Of the three primitives, tools get almost all the attention, and the difference between a tool and a resource is worth understanding because getting it wrong produces servers that feel awkward to use.
A tool is model-controlled. The model decides to call it, chooses the arguments, and the call has an effect — it runs something, it costs something, it may change the world. Tools are verbs.
A resource is application-controlled. It is data the host can pull in and show to the model, usually because the user picked it. Reading a resource should be safe, repeatable and free of side effects. Resources are nouns.
The practical test: if calling it twice in a row would be surprising or expensive, it is a tool. If calling it twice is simply the same answer again, it is probably a resource.
How a server is actually reached
Two transports cover nearly everything you will meet.
The first runs the server as a local subprocess on the same machine as the host, with messages passed over standard input and output. This is how most developer tooling works: the server has access to your filesystem and your local credentials, there is no network hop, and configuring it means telling the host what command to run.
The second runs the server as an HTTP service somewhere else, which the host connects to over the network. This is how a hosted product exposes itself to many users, and it is the transport you meet when a vendor gives you a URL and a key rather than a command to run.
The protocol itself is the same either way. From the model's point of view a tool is a tool; the transport only determines where the code runs and what it can reach.
When you do not need MCP
It is a connection standard, not a requirement. Skip it when:
- You are building one application against one API and nothing else will ever consume it — a direct SDK call is simpler and you should just do that
- The data fits in the prompt. A thousand-row price list pasted into context needs no protocol.
- You need deterministic behaviour. If the action must happen every time, put it in your code, not behind a decision the model makes.
- The integration is read-only, static and small, in which case a resource-shaped file in the repository is often enough
Worked example: why N × M becomes N + M
The claim that MCP turns a multiplication into an addition is worth doing with actual numbers, because the crossover arrives sooner than people expect. At one client and one source the protocol is pure overhead — two pieces where one function would do. The lines cross at two clients and three sources. By four and six you are maintaining ten things instead of twenty-four. The last row is the one that settles the argument.
| Clients | Sources | Bespoke integrations (N × M) | MCP pieces (N + M) |
|---|---|---|---|
| 1 | 1 | 1 | 2 |
| 2 | 3 | 6 | 5 |
| 4 | 6 | 24 | 10 |
| 6 | 10 | 60 | 16 |
| adding one more source to that last row | +6 integrations | +1 server |
What usually goes wrong
Most of the confusion around MCP is about which problem it solves, not about how it works.
- Reaching for it at one client and one source. The first row of the table is honest: at that size you have introduced a protocol, a process and a config file in order to avoid writing one function.
- Exposing an entire API as tools. Forty thin wrappers around forty endpoints gives the model forty ways to be wrong, and lesson four is about why that is worse than it sounds.
- Making something a tool when it should be a resource. If it is safe to read twice and has no effect, the application can fetch it without spending a model turn deciding to.
- Assuming the transport matters to the model. It does not — which means a local stdio server and a remote HTTP one fail identically from the model's point of view while having completely different causes.
- Expecting the protocol to supply the judgement. MCP standardises how a tool is described. Whether the description is any good remains a writing problem.
Why it caught on
Two reasons, and neither is technical elegance. First, the integration a developer writes keeps working when they switch model or client, which removes a real source of lock-in anxiety. Second, it made it reasonable for a vendor to ship one server rather than one plugin per assistant — which is why a lot of infrastructure, including ours, now has an MCP interface sitting next to its REST API.
The honest caveat is that a protocol does not make a bad integration good. A server with twelve vaguely named tools and no descriptions is just as hard for a model to use over MCP as it was over anything else. That is lesson four, and it is the lesson that actually determines whether your agent works.
Next: the specific way agents fail at live data, and why adding a tool does not automatically fix it.
Lesson 2: why agents get live data wrong