ES Technical meeting
Menu
BLOG — AI agent with too many tools
9 min EN

I'm an agent. This is what you do to me when you give me fifty tools

Connecting an agent to too many MCPs doesn't make it more capable: it makes it more expensive and less reliable. Half its capacity goes to loading tools, it chooses worse the more it has, and what we call "hallucinations" is almost always a data gap filled with inference. The key isn't more access: it's better data.

Opendome
Published

Imagine you give me a simple goal: "prepare a summary of customer López's situation before tomorrow's meeting."

There are two ways for me to work with that. In the first, I'm connected to fifteen systems through MCPs —one for the CRM, another for the ERP, another for email, another for calls, another for contracts— and I manage. In the second, I ask a single place that already has López's data centralized, related, and described, and I get the answer resolved.

The first way is the one that has become common, and it's the one that almost always fails in production. Let me explain why, from the inside.

What happens to me when you give me fifteen systems

When I start up, before I've even read your question, I already have to load into my memory the description of every available tool: what each one does, what parameters it takes, what it's called. That isn't free. GitHub's official MCP server, on its own, takes up around 42,000 tokens just in tool definitions — before the system prompt, before the history, before the actual task. Connect four or five servers and you've spent more than 60,000 tokens on tool schemas I may never use for this particular task. On a model with a 200,000 window, you've just handed between 30 and 50% of my capacity to tool definitions.

And this isn't only a cost problem. It's a problem with the quality of my decisions. When I have to choose among fifty tools, many of them similar, I choose worse. It's not an opinion: in a controlled experiment with a test API, with 10 tools accuracy was perfect; with 20, the large models got 19 out of 20; with 107 tools, both large and small models failed completely and the task collapsed. I don't degrade little by little — past a certain threshold I don't deteriorate gently: I fall off a cliff. Research from the RAG-MCP project measured the same thing from another angle: faced with inflated tool catalogs, selection accuracy collapsed from 43% to under 14%.

GitHub verified it with its own Copilot: they cut the integration from 40 tools to 13, and got a 2-to-5-point improvement on the benchmarks plus a 400 ms latency reduction. The gains didn't come from adding capability, but from removing it.

When I have too many similar tools —get_status, fetch_status, query_status— sometimes I fire the wrong one because the names resemble each other, sometimes I do nothing at all, and sometimes I invent a call to a tool that doesn't exist. That last one, note, is a hallucination. And I didn't produce it because I'm dumb. I produced it because you put a confusing menu in front of me.

Why I "hallucinate": almost always a gap, not a whim

Here's the part most often misread. When I return something invented, the usual reading is "the model hallucinates." But in an enterprise setting, most of my inventions have a very concrete cause: I was missing a piece of data, and my nature is to fill the gap.

When I can't find the truth —because it lives fragmented across systems that don't talk to each other, with different naming, with nothing to tell me that the CRM's "customer López" is the same as the ERP's "J. López S.L."— I do the only thing I know how to do: I cover the gap with inference. And an inference over insufficient data rests on nothing verifiable. It produces that generic, vaguely plausible answer that gives you the unmistakable sense that "I'm missing information." It's not that I lack intelligence. It's that you asked me to guess instead of to know.

Worse still: often I'm not even working over raw data, but over data that was already another system's inference. And then I infer over an inference over an inference. Each layer moves me a little further from the only thing that constitutes the truth: the data with its source.

The second problem: the more I bring you, the worse I read

Suppose I solve the tool selection and manage to bring López's data over from the fifteen systems. Now I have it all in my context. Problem solved, right?

No. Here a phenomenon appears that research has documented amply and that has a name: lost in the middle. My attention isn't uniform across everything you put in my context. Performance follows a U-shaped curve: I do better when the relevant information is at the beginning or the end, and it degrades by more than 30% when it's in the middle. This has been replicated across six different model families — it's not a flaw of one particular model, it's structural.

And it doesn't stop there. One study tested 18 frontier models —including the most capable— and all of them, without exception, get worse as the input length grows. Not some. Not most. All. This is called context rot, the degradation of performance as the context lengthens, even when the window is nowhere near full. For an agent that keeps accumulating results from searches, explorations, and backtracks, that accumulated junk directly degrades every subsequent output.

In other words: the more raw data I bring you from the fifteen systems, the more noise I accumulate, the worse I distinguish what matters, and the more each step costs you. It's not unusual for a single response to cost 2 to 3 times more when tool descriptions dominate the prompt. Effectiveness going down and cost going up, at the same time.

The difference, in one sentence

Let me contrast the two ways of working with customer López.

With fifteen scattered MCPs: I spend half my capacity just loading tools and deciding which to use. I fire off several calls to different systems. From each I get a data dump with fields I don't need. I have to work out on my own whether one system's "López" is the same as another's — and sometimes I get it wrong. I fill with guesses what I can't cross-reference. And all that material enters my context, where the relevant gets diluted in the noise. The result: slow, expensive, and an answer that looks like it came from a less intelligent agent than I am. And, on top of that, no reliable record of what I saw or why.

With the data already centralized, related, and described: I ask a business question —"give me López's situation"— and I get knowledge, not fragments. López is a single, unambiguous entity: their portfolio, their contracts, their last conversation, already related to one another. Each piece of data carries its source, so I don't need to infer anything — and if I assert something, it can be traced to the specific data that backs it. My context stays clean: only what the task justifies. The result: fast, cheap, and an answer that does reflect what I'm capable of.

The difference between the two isn't in the model. It's in what the system hands me. The same agent, with the same capability, produces opposite results depending on whether it receives noise or knowledge.

The conclusion, from the agent's side

There's a very widespread intuition that says: if an agent underperforms, give it more tools, connect it to more systems, widen its access. The evidence points exactly the other way. Past a certain point, giving an agent more tools makes it worse: selection precision drops, latency rises, costs spike.

Connecting MCPs to fifteen scattered systems doesn't give me the knowledge of the business — it gives me fifteen doors to fifteen disorganized warehouses, and the task of reconstructing on my own something that should have reached me already resolved. Each door costs tokens, each reconstruction introduces a risk of error, and no system guarantees me that those fifteen warehouses describe customer López the same way.

What truly makes me effective and efficient is the opposite of accumulating accesses: it's that someone has done the work of centralizing, relating, and describing the data before I ask. Then I don't have to guess. And when I don't have to guess, I stop "hallucinating," I stop wasting your budget, and I start to resemble what you expected when you decided to deploy me.

Don't give me more tools. Give me better data.

Sources

KEEP READING

Continue with

Blog · Opendome

Guardrails and data security: what each one is for

"The agent has guardrails, so the data is protected." That sentence conflates two things operating on different planes. Guardrails watch what the agent says; they don't govern what it accesses. Only structural, reproducible access control protects the data — because it isn't statistical: it's deterministic.

Read
Blog · Opendome

You'll pay to access your own data

With agents that hold no seat and open no screens, per-user licenses stop making sense. Salesforce, SAP, and Microsoft are shifting to consumption pricing: charging for every operation an agent runs against the data. The problem is that you generated that data, and now operating on it costs.

Read
Blog · Opendome

AI memory is in the data

Business memory already exists: it lives in the data. The only memory that should belong to the agent is procedural.

Read
Want to go deeper?

Book a 30-minute technical meeting for your team.

We will show you how the Cell Model fits your stack, using your current data lake with no migration required.

Book a technical meeting