We kept adding MCP servers. Git, GitHub, Postgres, Slack, a search tool, a browser, three internal APIs. Each one felt like a win — the agent could do more.
Six weeks later it could do less.
What actually happened
The tool list grew past what the model could reason about in one pass. Two tools sounded interchangeable. One was described as "search the codebase," another as "find references." The agent started picking by vibes, and every wrong call cost a retry loop and a confused human reading the trace.
Tool count is not capability. It's a tax on every decision the agent makes, because it has to hold the whole list in context and choose.
The failure modes are predictable
Generic descriptions are the first rot. "Get data from the API" could mean four of the tools you installed. Naming collisions are the second: two tools both called search, one over files and one over tickets. The third is scope creep — a tool that was meant for one job grew three optional parameters until nobody knew when to call it.
The agent doesn't tell you it's guessing. It just calls the closest-sounding one and moves on.
The fix is subtraction, not more tools
We cut the list in half. Merged the two search tools into one with a clear purpose. Rewrote every description to say when NOT to use it. A tool that says "use this for repo files, not tickets" prevents more wrong calls than a longer tool ever enabled.
For API work this was the clearest win: one well-described tool that runs a spec against a live endpoint beat three scattered fetch-and-parse tools, because the agent stopped having to decide which one applied. We ended up keeping that flow local rather than wiring it through yet another server.
Worth auditing this week
Open your agent's tool list and read every description out loud. If two could plausibly be the same call, merge them. If a description doesn't say when to skip it, rewrite it. You'll ship a slower-looking setup that gets more right on the first try.
How many tools does your agent actually have — and how many of them have you used in the last week?
Top comments (2)
Rewriting each description to say when NOT to use it is the part I would copy first. One thing that bit us after that: a description can be accurate and still lose the choice, because the model (or a search step in front of it) matches on words. In our own tool search, "silver price" returned US CPI, and the stemmer turned "rates" into "rat". Both looked fine when we read the descriptions out loud; they only showed up when we ran ambiguous plain-word requests and checked which tool came first.
Cutting tools worked for you at 40. At a few hundred we stopped listing them at all: three front tools, so the model sees about 1,109 tokens of tool text instead of about 34,508 for the full list. I built it: canli-mcp, free, MIT, no key, runs locally (
npx -y canli-mcp, github.com/arhancanli/canlicapital). Do you track which of your 40 tools were actually called in the last week, or is that still a guess?The “when not to use it” part of a tool description is especially valuable because it turns a fuzzy selection problem into an exclusion check. I would pair that with a small evaluation set of ambiguous requests and track first-choice accuracy after each tool-list change; otherwise a cleaner catalog can still hide a regression in routing.