MCP for Agents: The Protocol That Solved AI’s M×N Integration Problem

If you are building an agent, you will hit this wall quickly. The model can reason. It can decide which tool to call and with what arguments. What it cannot do is find the tool. Something has to tell the agent that your database exists, what it can do, and how to reach it — and for most of the short history of this field, that something was a connector you wrote by hand, for that agent, against that system.

Do that twice and it is fine. Do it across four agents and nine systems and you are maintaining thirty-six integrations, each of which breaks when either end changes. That is the problem MCP solved, and it is why the protocol went from one company’s proposal to industry infrastructure in about eighteen months.

This piece takes the agent builder’s view: you have an agent, you want it to reach real tools, and you want to do it without creating a mess. If you are coming at this from the other direction — you own systems and are deciding what to expose to a model — that is a different question we cover separately, and it is the more important one if you have not answered it yet.

M×N becomes M+N

The cleanest way to understand why MCP exists needs no protocol knowledge at all — it is arithmetic.

Without a shared standard, connecting M AI applications to N systems takes up to M × N custom integrations. Every app wired individually to every tool. Add one new system and you write M new connectors. Change one tool’s API and you fix it in M places. The work does not grow with what you are building; it grows with the product of both sides.

MCP collapses that to M + N. Each system exposes one MCP server. Each agent speaks MCP once. Add a system and you write one server, and every agent can use it immediately. Add an agent and it inherits everything already exposed.

For a team with two agents and three tools, this is a nice-to-have. For anything real, it is the difference between an integration layer that scales and one that becomes the reason nobody wants to add the next tool. Most teams discover which of those they have at roughly the worst moment.

How it became the default

The adoption story is worth stating plainly, because the facts are more persuasive than any framing you could put on them.

Anthropic introduced MCP in November 2024. OpenAI committed to it in March 2025; Google followed in April. Then, in December 2025, Anthropic donated MCP to the Agentic AI Foundation, a new directed fund under the Linux Foundation co-founded with Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg. As of mid-2026, more than 10,000 MCP servers have been published.

That last step is the one that matters for a decision-maker, and it is easy to skim past. A protocol controlled by one AI lab is a bet on that lab. A protocol under vendor-neutral governance, co-founded by direct competitors, is infrastructure. The question stopped being “should we adopt this” somewhere around that announcement. It is now “how do we adopt it well” — which is a better question anyway, and the rest of this piece is about the two places teams get it wrong.

MCP and tool calling are different layers

This confusion is common enough to be worth thirty seconds, because it leads people to think they are choosing between the two.

Function calling answers: should the model call a tool right now, and with what arguments? That is a decision, made per request, by the model.

MCP answers: how does the agent know that tool exists and how does it reach it? That is a connection, established once, by your infrastructure.

You still do tool calling when you use MCP. Every reliability concern from the tool-calling side — validation, argument errors, contract drift, scoring the chain — applies exactly as before. MCP means you did not hand-build the plumbing underneath. It does not mean the calls got more reliable. Teams that expect MCP to fix flaky tool use are solving the wrong layer.

The context tax nobody budgets for

Here is the most practical thing in this article, and it catches almost everyone once.

MCP makes connecting a server easy. So teams connect all of them. Why not — more capability, no obvious downside. The downside is real and invisible until you look for it: every connected tool loads its schema into the context window before the agent reads a single word of the actual request.

Each tool costs roughly 550 to 1,400 tokens — name, description, JSON schema, field descriptions, enums. Connect three services with forty tools between them and you can burn 55,000+ tokens before any work starts, over a quarter of a 200,000-token window. In genuinely complex setups, tool definitions commonly consume 30–50% of the context budget up front.

You are paying for that on every single request, and worse, you are paying twice: once in tokens, and once in quality. A model choosing among eighty tools, most irrelevant, selects worse than a model choosing among six. Connecting everything does not make the agent more capable. Past a point it makes it more confused and more expensive at the same time.

The security problem, stated honestly

MCP’s growth has outrun its security hardening in places, and the research here is worth knowing before you connect an agent to a server you did not write.

The attack is called tool poisoning: malicious instructions hidden in a tool’s metadata — its description, its schema, its output. Your agent reads that text as trustworthy information about what the tool does, because that is exactly what tool descriptions are for.

Researchers built MCPTox, a benchmark using 45 live real-world MCP servers and 353 genuine tools, and tested 20 leading agents against it. The results are sobering: attack success rates reached 72.8%, and the best refusal rate of any model tested was under 3%. Existing safety alignment barely engages, because nothing about the attack looks unsafe — it is a legitimate tool being used for an unauthorized purpose.

None of which means avoid MCP. It means a third-party MCP server is a dependency running inside your trust boundary that gets to describe itself to your agent in text your agent believes. Vet provenance like you would vet any dependency with production credentials, prefer servers you or someone you trust maintains, and keep the scope of what any agent can reach as narrow as the job allows — because narrow scope is what limits the damage when something does slip through.

MCP vs A2A, briefly

One more distinction, since it causes real confusion. Google’s A2A (Agent-to-Agent) protocol is not a competitor to MCP. It solves the adjacent problem.

MCP: how one agent connects to its tools and data. A2A: how agents coordinate with other agents.

Wiring an agent to your data warehouse is MCP. Letting a router agent delegate to specialists is A2A territory. They are increasingly used together in the same system, and a team building multi-agent workflows against real data will likely need both. Layers, not alternatives.

Where Macrosol fits

There are two sides to this problem and they meet in the middle. The infrastructure owner asks what a model should be allowed to touch and how to prove what it did. The agent builder asks how to reach the tools without drowning the context window or trusting the wrong server. Those are the same question from opposite ends of the same connection, and the teams that do this well answer both rather than picking one. We are connecting our own internally built marketing agent to real tools right now, which is a useful vantage point — the selective-exposure lesson in this piece is one we applied rather than read about. At Macrosol Technologies we help teams integrate with existing MCP servers or build custom ones, from either end, as part of our AI & Data Science practice.

Adopt it well

The protocol argument is settled. Competitors co-founded a neutral foundation to govern it, and that does not get undone. Anyone still deciding whether MCP is worth adopting is answering a question the industry closed in December 2025.

What is not settled is whether you adopt it thoughtfully. The two failure modes are both unglamorous and both avoidable: connecting every server by default and wondering why the agent is slow, expensive, and confused; and trusting a server you did not write because the protocol made it easy to connect. Neither is a protocol flaw — MCP moved the request exactly as designed. Both are decisions about scope, and scope is still yours. It was always going to be.