Lesson 6.4 · 8 min read
In the last post, tools were functions you wrote and described to a model. That works, and it is how most agents are built. It also contains a problem that becomes obvious the moment you look at it from a distance.
You wrote a tool that reads from your project management system. Someone at another company wrote one too, for their agent, against the same system. So did a hundred other teams. Each one wrote, described, tested, and maintains their own version of the same integration, and none of them can use each other's. Meanwhile the company that makes the project management system, which knows its own API better than anyone, cannot write the tool once for everybody, because there's nowhere to put it.
This is a shape you have seen before, and software has solved it before. It's the shape that produces protocols.
An agent is useful in proportion to what it can reach. A model that can only talk is limited; a model that can read your files, query your database, search your documents, and update your tickets is a different thing entirely.
But every one of those connections has to be built. And built again by the next team. And rebuilt when the API changes. The number of integrations required is the number of agents multiplied by the number of systems, and that product grows uncomfortably fast.
Whenever you see that multiplication, the answer in software has always been the same: put a standard in the middle. Define an interface. Now each agent implements the interface once, each system implements the interface once, and any agent can talk to any system. The multiplication becomes an addition.
This is exactly what happened with databases, where a common driver interface meant applications didn't need bespoke code per database. It's what HTTP did for clients and servers, which is why any browser can talk to any web server, a fact so ordinary that it takes effort to notice how extraordinary it is.
MCP, the Model Context Protocol, is that standard for connecting AI applications to external systems. It is not a framework and not a product. It is an agreement about how a request for a tool is described and how the result comes back, so that anyone implementing the agreement can talk to anyone else implementing it.
There are two sides.
A server exposes capabilities. It's a program that says: here are the tools I offer, here's what each one does, here are the arguments each takes. It might expose your file system, a database, a ticketing system, a search index. The people best placed to write it are the people who own the system it wraps.
A client is the AI application: the coding tool, the chat interface, the agent you're building. It connects to servers, discovers what they offer, presents those capabilities to the model, and when the model asks for one, sends the request to the appropriate server and returns the result.
The important word there is discovers. The client does not need to know in advance what a server can do. It asks, and the server describes itself. Which means an agent can be given a new capability without being rebuilt: connect a new server, and the tools appear.
That's the whole architecture, and structurally it should feel familiar, because it is a client and a server exchanging requests and responses over a defined interface, which is post 0.1 and post 2.1 wearing different clothes. Nothing here is conceptually new. What's new is the agreement about what the messages mean, which is what a protocol is.
Servers can offer more than tools, and the distinction is worth knowing. Tools are actions the model can request. Resources are data the client can read and place into the context, more like files than like functions. Prompts are reusable templates a server can supply. But the tool is the heart of it, and if you understand tools, you understand MCP.
A reasonable question, since these systems all have APIs already. Why not just call them?
Because an API is designed for a programmer who reads documentation and writes precise code against it. A protocol for models must carry something extra: a description of each capability, in natural language, good enough that a model reading it can decide, unprompted, whether this is the right tool for the situation and how to use it correctly.
MCP is therefore not just a transport. It's a way of describing capabilities to a reasoning system. The description is part of the interface, and it is as important as the schema, and it is subject to everything from the prompts post, because a tool description is a prompt. A badly described tool is a tool the model will misuse, and no amount of correct implementation behind it will help.
The second reason is the discovery property. An ordinary API integration is written at development time. An MCP connection is established at runtime, and the capabilities are learned then. That's a genuinely different relationship, and it's what allows an agent to be extended by its user rather than by its developer.
It's worth being precise about the claims, because this is an area with a great deal of enthusiasm and it is easy to overstate.
What it changes. Integration effort moves from being quadratic to linear. Capabilities become composable: an agent connected to three servers can use all three together, and nobody wrote code anticipating that combination. And the people who understand a system best can be the ones who expose it, once, for every agent.
What it doesn't change. Everything from the last post still holds, completely. The model still asks; your code still executes. The loop is still yours. The context window still fills up, and now it fills up with tool descriptions from every connected server, which is a real cost nobody mentions: connect enough servers and a meaningful fraction of your window is consumed describing tools before the work begins.
And the safety picture is the same, but the surface is larger. Which is worth dwelling on.
In the last post, the boundary was clear: you wrote every tool, so you knew exactly what each one could do. A protocol that makes it easy to connect capabilities makes it easy to connect capabilities you did not write.
An MCP server runs somewhere, with permissions, doing real things. Connecting one is granting access. The questions are the ordinary ones from the security posts, and they have not changed: who wrote this, what can it do, what credentials does it hold, what happens if it is malicious or merely careless.
There is a specific hazard here that deserves naming, because it is subtle and it is the security problem of this entire architecture. In post 6.2 you met prompt injection: text that arrives as content but reads as instruction. Now consider an agent that reads data from one source and has the ability to write to another. If the data it reads contains text crafted to look like an instruction, and the model follows it, the agent takes an action nobody asked for, using credentials it legitimately holds.
The dangerous combination is: access to untrusted content, plus the ability to act, plus a way for information to leave. Any one of the three is fine. Together they are a system where a document can instruct your agent to do something on behalf of whoever wrote the document.
This is not exotic, and there is no complete solution. What there is, is the discipline you already have. Untrusted content is untrusted, whatever it says. Actions that matter require a human. The permission boundary from the last post is not a formality, and when tools arrive from a protocol rather than from your own code, it matters more, not less.
You might reasonably ask why a protocol deserves a place in a series about fundamentals.
Because the pattern is the fundamental. Standard interfaces that decouple providers from consumers are how every layer of computing became composable, and every time it happens it looks unremarkable in retrospect and transformative at the time. It happened for network protocols, for database drivers, for the web itself. This is the same event, occurring in the layer where AI applications meet the systems they need.
And because it clarifies something about the whole module. An LLM is a text function. An agent is a loop with tools. MCP is a standard way of offering tools to that loop. Each layer is ordinary. The capability that emerges from stacking them is not, and that gap between ordinary parts and remarkable behavior is the most interesting thing in modern software, and it's a gap you can only see if you understand each part.
The engineers who will build well here are not the ones who learned a framework. They're the ones who recognized this as a client and a server exchanging messages over an agreed interface, asked who is trusted and what may be done without permission, and then designed carefully in a space where the answers are not obvious.
Do this before the next post
Find an MCP server, and read what it exposes, not how it's implemented.
Many exist publicly, wrapping file systems, databases, and common services. Open one and look at the list of tools. For each, read the name, the description, and the arguments. Ask yourself: if I were a model, and this description were all I knew, would I use this correctly? Would I know when not to use it? Notice that the description is doing the work of documentation, specification, and prompt simultaneously.
Then sort the tools into two piles, the way you'd sort them if you were deciding permissions. Which of these only read? Which of these change something in the world? Draw the line where you'd require a human to confirm, and notice that this is a product decision about acceptable damage, not a technical one.
Finally, do the exercise that reveals the hazard. Imagine an agent connected to two servers: one that reads a shared document store, one that sends messages. Now imagine someone writes a document containing text that reads like an instruction to the agent. Trace what happens, step by step, through the loop you learned in the last post.
If you can see clearly how that goes wrong, you understand this architecture better than most people currently deploying it, and you understand why the boring question, what may this thing do without asking a human, is the most important question in the field.