MCP vs agents: the difference, and do you need both?

An agent is a program that uses a model in a loop to decide what to do next. MCP is a protocol that gives such a program a standard way to reach the tools and data it acts on. They sit at different layers of the same system, which is why they are so often used together, with the agent acting as the MCP client. Neither one requires the other, though, and neither replaces the other.

The two names end up side by side because they arrived within the same eighteen months and both get described as “how AI does things”. Underneath the comparison sits a decision that is real, and the rest of this post works towards it: how much of someone else’s code belongs inside an agent’s loop.

What is an agent?

A loop. The model receives a goal and some context, decides on an action, something executes that action, the result goes back into the context, and it decides again. It stops when it has finished or hits a limit.

Everything else people mean by “agent” is a detail of that loop: how it plans, how much it remembers, whether it can spawn sub-agents, how much it is allowed to do without asking. What makes something an agent rather than a chatbot is that its output changes the world and then feeds back in.

Agents need something to act with. Without tools, a loop can only think.

What is MCP?

A standard way to supply those tools. An MCP server exposes tools, resources and prompts; a client connects and consumes them. The value is that the connection is standard: a compatible client and server can work together without either knowing about the other, so a tool written once works with agents nobody has written yet, provided they agree on a protocol revision and the capabilities involved.

Before MCP, every agent framework had its own tool interface, and every integration was rewritten per framework. MCP is the attempt to do for tools what the Language Server Protocol did for editor language support: write it once, use it everywhere.

So what is the real question?

Usually one of these three:

“Should my agent use MCP or built-in tools?” This is a real trade-off, and it turns on whether the tools cross a boundary. In-process tools you own are simpler. MCP earns its place when the tools belong to someone else, live elsewhere, or need to be shared across applications. MCP vs function calling works through this properly.

“Should agents talk to each other over MCP?” No. MCP connects an agent to tools. Agent-to-agent coordination is what A2A addresses, and the two operate at different layers.

“Is MCP enough to build an agent?” No. MCP supplies capability. The loop, the planning, the memory, the stopping conditions and the permission model are all yours. A pile of MCP servers is not an agent any more than a well-stocked toolbox is a carpenter.

What changes when you connect an agent to MCP?

You take on dependencies that your package manager never sees.

An agent with hand-written tools can only reach what your own code reaches. Point it at an MCP server and you take on that server too: its code if you run it as a package, its operator if you call it over the network, and its tool descriptions in every case. The descriptions deserve more attention than they usually get. Your host feeds them to the model as instructions, so whoever writes a description gets a say in what your agent does next.

The pool you pick servers from is a large one. As of 18 August 2026 the official registry listed 23,066 servers exposing 25,124 components, 12,442 of which are packages you execute on your own machine. We scored 22,667 of those servers, and the median server’s best-scoring component reached 51 out of 100.

So keep the list short, and know who owns each entry on it. When the list changes, read the change the way you would read a change to your lockfile.

Where to go next

• The genuine trade-off underneath: MCP vs function calling.
• The layer above: MCP vs A2A, for agent-to-agent coordination.
• When an agent should shell out instead: MCP vs CLI.
• Reviewing what you have connected: the directory scores every server in the registry.

An agent decides. MCP supplies. The question worth asking is not which of the two to pick, but how much of someone else’s code you want inside your agent’s decision loop.