Why an Agent Needs an MCP Server at All

The model cannot reach anything

Start with the constraint that makes all of this necessary. A language model takes text in and produces text out. It has no file handle, no socket, no credential and no ability to cause anything to happen in the world.

So when an agent reads your repository, queries your database or opens a ticket, none of that was done by the model. The model emitted a request. Something else carried it out and put the result back into the conversation as text.

That something else is the runtime, and every capability an agent appears to have is a function the runtime was given and agreed to run.

Which raises the practical question this protocol answers: how does a capability get in front of an agent in the first place?

The first generation of answers was to write it directly into the agent. If you wanted an agent to read your issue tracker, you wrote issue tracker code inside that agent. It worked, and it did not survive contact with a second agent or a second system.

The combinatorial problem

Consider the shape of the work without a shared protocol.

You have several agents in use, because different tools suit different tasks and teams rarely standardize on one. You have many systems worth reaching: a repository host, a database, a ticket tracker, a documentation store, an internal service or two.

Every pairing needs its own integration, written against that agent's particular extension mechanism and that system's particular API. Agents times systems. Add an agent and you write an integration for every system again. Add a system and you write one for every agent.

That multiplication is why integrations were scarce and why most agents could reach almost nothing beyond a filesystem.

A protocol converts it into addition. Wrap each system once as a server that speaks the protocol. Teach each agent once to speak the protocol. Now adding a system costs one server, available to every agent, and adding an agent costs nothing at all on the integration side.

This is an unglamorous piece of plumbing and it is the reason the ecosystem changed quickly. Nothing became newly possible. It became affordable.

When you do not need one

The honest counterweight, because a server is not free.

When only one agent will ever use it. If the capability is specific to a single tool and always will be, an extension written for that tool directly is less machinery. The protocol earns its cost through reuse, and reuse that will not happen is not a benefit.

When what you need is knowledge, not access. A great many things people build servers for are really questions about how a system works, what a convention is, or why a decision was made. That is retrieval, and answering it through a tool call is slower and more expensive than answering it from an index. RDK's stacked retrieval resolves most such queries before the model runs at all.

When it is instruction. How your team wants work done belongs in a conventions file or a skill, not in tool descriptions that are loaded on every request.

When the system already speaks something simpler. A shell command or a plain HTTP call the agent can already make does not need wrapping to become reachable.

The test worth applying: would a second agent, or a second person, want this same capability? If yes, a server pays for itself. If no, you are paying protocol overhead for a single caller.