Back in article 4 we covered tool use, and I called writing tool descriptions the highest-leverage skill in agent building. That’s still true. But there’s a practical headache lurking underneath it that I glossed over, and it’s time to face it. Every tool you want your agent to use, a database, a file system, a calendar, a customer-support system, a payment API, has to be wired up by hand. You write the connecting code, the schema, the authentication, the error handling. Then your colleague, building a different agent, wires up the very same calendar again from scratch. And so does everyone else, everywhere, forever. It’s an enormous amount of duplicated plumbing.
The Model Context Protocol, almost always shortened to MCP, exists to fix exactly that. It’s an open standard for connecting agents to tools and data sources, and once you understand the problem it solves, its usefulness is obvious. This article is about what MCP is, the problem it addresses, how it’s shaped, and why it’s become such a big deal in the agent world.
The problem: an N times M mess
Let me make the plumbing problem precise, because MCP’s whole value comes from it.
Imagine you have a handful of AI applications: an agent in your product, an assistant in your IDE, a chatbot for your support team. Now imagine a handful of systems you’d like them all to reach: your document store, your ticketing system, your database, your email. Every application needs to connect to every system, and each connection is custom code someone has to write and maintain.
With three applications and four systems, that’s twelve separate integrations. Add one more system and you’re writing three new connectors, one per application. The work grows as applications times systems, the classic N times M explosion. Nobody’s plumbing is reusable, everybody rebuilds the same connectors, and the whole ecosystem drowns in redundant glue code.
Figure 1: Without a standard, every application needs a custom connector to every system, an N times M tangle. With MCP, each system exposes one standard server and each application speaks one standard protocol, collapsing the work to N plus M.
Figure 1 shows the before and after. On the left, a tangle of custom lines. On the right, a clean hub where each side only has to speak one common language. That collapse, from N times M down to N plus M, is the entire point.
The idea: a common language for tools
MCP borrows an idea that’s worked brilliantly elsewhere in computing: agree on a standard, and let everyone build to it once. The analogy people reach for is USB-C. Before it, every device had its own charger and cable, and nothing was interchangeable. After it, one standard port meant any cable fit any device. MCP is trying to be USB-C for connecting AI applications to the outside world.
Here’s how it works in shape. A system that wants to expose its capabilities, say your ticketing tool, runs an MCP server. That server describes, in the standard format, what it can do: the tools it offers, the data it can provide, the actions it can take. Any AI application that speaks MCP, acting as an MCP client, can connect to that server and immediately use everything it exposes, without any custom integration code.
Write the ticketing server once, and every MCP-speaking agent in the world can use it. Build your agent to speak MCP once, and it can connect to every MCP server in existence, ones you’ll never even hear about. That reusability, in both directions, is what makes the standard powerful rather than merely tidy.
The pieces, briefly
You don’t need to implement MCP to understand it, but a little vocabulary helps you follow conversations about it.
An MCP server wraps a system or data source and exposes its capabilities in the standard format. The three main things a server can offer are tools (actions the agent can take, like “create a ticket”), resources (data the agent can read, like a document or a database record), and prompts (reusable prompt templates the server suggests). You’ll mostly care about tools, since they map directly onto the tool-use ideas from article 4.
An MCP client lives inside the AI application and connects out to servers. When your agent starts up, its client connects to whatever servers you’ve pointed it at, discovers what each one offers, and makes those capabilities available to the model as tools. From the model’s point of view, an MCP tool looks exactly like any other tool, it’s just that the wiring behind it came from a standard server rather than hand-written code.
Figure 2: The MCP client inside the agent connects to one or more servers, discovers the tools and resources each exposes, and surfaces them to the model. To the model, they’re just tools.
Figure 2 shows the flow: the client discovers what a server can do, and hands those capabilities up to the agent loop you already understand. Nothing about the loop from article 3 changes. MCP just changes where the tools come from and how much work it took to connect them.
Why it caught on
Standards only matter when people adopt them, and MCP has spread quickly for a good reason: it turns tool integration from a bespoke chore into a shared library. When a company publishes an MCP server for its product, every agent builder gets to use it for free. That network effect feeds itself, more servers make MCP more valuable to clients, more clients make it more worthwhile to publish servers.
For you as a builder, the practical payoff is this. Instead of writing yet another custom connector, you can often reach for an existing MCP server and connect to it in minutes. And when you build something worth sharing, exposing it as an MCP server means it works with agents far beyond your own.
Standards are only useful if the industry actually converges on them, and MCP genuinely has. Since its late-2024 launch, it’s been adopted by every major AI platform (Anthropic, OpenAI, Google, Microsoft), and in December 2025 stewardship moved to the Linux Foundation’s Agentic AI Foundation, making it vendor-neutral open infrastructure rather than one company’s protocol. The registry of public servers is in the thousands, and the SDKs see tens of millions of downloads a month. That’s the “phew, this stuck” moment for a standard, and it happened faster than most protocols manage.
A word of honest caution, though, because this is a fast-moving area. The spec is still evolving as production deployments surface real needs (enterprise authentication, stateless transport, better auditing), so specific details will shift. Server quality varies too, and security deserves real thought, since connecting an agent to a server means trusting what that server does. We’ll come back to that trust question head-on in the security article that closes this track. For now, the thing to carry forward is the shape of the idea: one standard, servers on one side, clients on the other, and a whole lot of plumbing you no longer have to write yourself.
In the next article we zoom back out to a practical decision every agent builder faces: which framework, if any, to build on. Now that you’ve seen agents from scratch and the standards emerging around them, you’re in a good position to choose well.