MCP Explained: How AI Agents Actually Use Tools

Every agent demo hits the same wall. The model is smart, the conversation is impressive, and then someone asks the only question that matters: can it actually touch my systems? Can it read the CRM? Can it file a ticket in the tracker the support team actually uses? A model that can't act on real data is a very expensive chat window.

The Model Context Protocol is the answer the industry settled on, and it settled fast. Anthropic published MCP in late 2024. Within a year it had stopped being an Anthropic thing and become the de facto standard for connecting agents to tools, the way USB-C became the default port. This essay is the first in a series on how agents communicate. The next two cover A2A, the agent-to-agent protocol, and ACP, the one that didn't survive, and the field guide puts the whole map together.

The problem MCP solves

Before MCP, connecting a model to a tool meant writing a custom integration. Your agent needed Salesforce, Postgres, and Slack? Three integrations. You switch model providers? Write them all again, because every provider had its own function-calling format. With M models and N tools you were staring at M×N integration projects, each one bespoke, each one rotting quietly as APIs changed underneath it.

MCP collapses that to M+N. The tool side implements one MCP server, once. The model side implements one MCP client, once. Anything on one side of the protocol can now talk to anything on the other. That's the entire pitch, and it's why adoption was so quick: nobody loves writing glue code, and MCP made most of it somebody else's problem.

How a tool call actually flows

The protocol has three roles, and keeping them straight clears up most of the confusion.

• Host — the application the user is actually in: Claude Code, an IDE, your internal agent app. It owns the conversation and the model.
• Client — a connector embedded in the host. One client per server connection. It speaks the protocol so the host doesn't have to.
• Server — the thing wrapping a capability: a database, a SaaS API, a file system. It advertises what it can do and executes requests.

A request runs end to end like this. You ask the agent something that needs outside information. The model decides a tool is required and names the one it wants, with arguments. The client formats that as a JSON-RPC call and routes it to the right server. The server does the real work, calling the API or running the query, and returns a structured result. The model reads the result and keeps reasoning. From your side it looks like the agent just knew the answer. Under the hood it was a round trip you can log and put permissions around.

Servers can expose more than tools. The spec also covers resources, which are pieces of context the host can pull in, like a file or a record, and prompts, reusable templates the server offers. Most of the ecosystem's energy is in tools, but the other two matter once you build serious internal servers.

What it feels like in practice

I run a lot of my work through agents, and MCP is the plumbing behind almost all of it. Analytics, GitHub, email, media tools: each is just a server my session connects to. When I want an agent to reach a new system, I don't scope an integration project. I find or write a server, add it to the config, and the tools show up in the agent's hands the same afternoon. That speed compounds. It's a big part of why a handful of agents on one laptop can cover ground that used to take a platform team.

Writing a server for your own systems is also less work than people expect. If your internal API already exists, an MCP server is mostly a thin layer that describes each endpoint well enough for a model to use it responsibly. The code is the easy part. Deciding what the agent should be allowed to do takes longer, and that's a governance question you were going to have to answer anyway.

Where teams get it wrong

Three mistakes come up constantly.

Treating MCP as agent-to-agent communication. It isn't. MCP connects an agent to capabilities. The moment you want two autonomous agents negotiating with each other and handing work back and forth, you've left MCP's job description and entered A2A territory. You can wrap an agent inside an MCP server and call it a tool, and sometimes that's fine, but you lose the task lifecycle and the back-and-forth that real delegation needs.

Connecting everything and drowning the model. Every tool you expose is another thing the model can misuse or get distracted by. Forty servers with three hundred tools doesn't make an agent powerful. It makes it scattered. The fix is the same discipline I argue for in designing agents like very stupid employees: give each agent the few tools its one job requires, and nothing else.

Ignoring the trust boundary. An MCP server executes real actions with real credentials, and tool results flow straight back into the model's context. A malicious or sloppy server is an injection vector. Treat servers like you treat third-party dependencies: vet them, pin them, and give them the narrowest credentials that still work. Log every call. Your security team already preaches this supply-chain hygiene; servers are just a new place to apply it.

The bottom line

MCP is the least glamorous layer of the agent stack and the most important one. It's how capability gets into an agent's hands, and it's already the standard, so adoption stopped being a real decision a while ago. What's left to decide is which of your systems deserve a server first, and what each agent is allowed to touch. Get that right and everything above it, including multi-agent delegation, gets much easier.

If you're mapping out which internal systems to expose to agents and how to keep that safe, that's work I do with companies every week. Let's talk →