The over-tooled agent

A release agent gets connected to more and more MCP servers until it slows down, forgets, and picks the wrong tools; the learner reasons through context cost, attention dilution, and least-tool scoping.

Intermediate · scenario

Maya's team shipped releases with an agent called `release-cli`. For a quarter it was the calmest part of their week: it cut the changelog, tagged the build, and posted the notes. Then the team went on an integration spree. Someone connected a Jira MCP so the agent could move tickets. Then a Slack MCP, so it could announce in three channels. Then a monitoring MCP, a GitHub MCP with the full REST surface, and a database MCP "in case it needs to check a migration." Each addition felt obviously good: the more the agent could reach, the more it could do.

The Friday release went sideways. The agent tagged the build cleanly, but when it went to move the release ticket to Done, it updated the wrong ticket — one from a different team's board. Then it announced the release in a channel nobody read, and paraphrased a changelog entry from two releases back. When Maya asked it to simply re-post the correct notes, it seemed to forget the notes it had generated ten minutes earlier and produced a different version.

Maya's engineer pulled the transcript and the tool manifest, and the picture was clear once they looked. Every MCP the agent connected to injected its tool definitions — names, descriptions, parameter schemas — into the context before the agent did anything at all. Five servers with broad surfaces had filled a large fraction of the window with tool descriptions alone. The release notes Maya cared about were now competing for attention with hundreds of tool signatures, and the model's attention diluted: it grabbed a plausible-looking ticket tool and a plausible-looking channel, and the earlier notes had scrolled far enough down the transcript that they no longer pulled focus. Nothing had broken. The agent was doing next-token prediction over a context that was mostly noise.

There was a second, quieter problem. The database MCP exposed write tools the release agent had no business holding, and one of the connected servers was a community MCP nobody on the team had audited — a standing attack surface, kept for a convenience they used twice a month.

The fix was not a bigger model or a longer prompt. It was context engineering: deciding what belongs in the window for this job. They cut the agent's default MCPs to two — GitHub, scoped to the release repo, and Slack, scoped to one channel. The Jira move became an explicit tool the operator enabled only during a release. The database MCP was removed; if a migration ever needed checking, a human ran it. The unaudited community server was dropped outright.

The next release was boring again. Maya wrote the lesson into the runbook: a chat is not a memory — every turn re-sends the whole transcript, so whatever you stuff into it competes for the same finite attention. More tools is more capability only up to the point where the tool definitions start crowding out the work. Past that point, each new MCP makes the agent measurably worse — and you have widened the blast radius for nothing.

Glossary

MCP (Model Context Protocol)
A standard way to expose tools and resources to a model. — The tradeoff: reach and reuse on one side; context cost and attack surface on the other.
tool definitions
The names, descriptions, and parameter schemas each connected tool injects into the context — they cost window space before the agent acts. — Five broad servers can fill much of the context with definitions alone.
attention dilution
As more content competes for the model's finite attention, focus spreads thin and the relevant material (here, the real release notes) stops steering the output.
context engineering
Deciding what goes into the finite context, and in what shape, for the specific job — the discipline that replaces 'connect everything'.
a chat is not a memory
Each turn re-sends the whole transcript to the model; there is no separate memory, so anything you want kept competes for the same attention every call.
attack surface
Every connected server and write-capable tool is something that can be abused or go wrong; an unaudited MCP is standing risk kept for convenience.

Comprehension questions

4 questions — practice and checking happen in the CLI, or sign in on the web to record your results here.

  1. Multiple choice

    What was the root cause of the release agent's degraded behaviour?

    • Connecting many MCPs filled the context with tool definitions, diluting attention so the agent grabbed the wrong tools and lost the earlier notes.
    • The underlying model was too small to handle a release at all.
    • Jira's API happened to be down during the release window.
    Record your result:
  2. Open response

    The team wants the Jira and database MCPs reconnected because they are occasionally convenient. As Maya, what do you do, and why?

    Record your result:
  3. True or false

    Because the agent runs as a chat, it reliably remembers the notes it generated earlier in the session even when they are far back in the transcript.

    Record your result:
  4. Discussion

    The agent 'forgot' the notes and grabbed the wrong ticket. Using the agents-are-like-people / agents-are-not-people lens, sort these behaviours and explain why the distinction changes how you fix them.

    Record your result:

Practice with the CLI (culture-guide practice), or sign in to check your answers and track a streak.