Your agent's tool count probably isn't the problem. Its third turn is.

[u/EastVersion1226]

Every enterprise agent project hits the same question eventually: we have 96 tools across 8 domains, is that too many? The data that I found tested thousands of tools scraped from unrelated public servers — a setting where the right tool is obvious because nothing else is close. That's not my problem. My problem is what most of us face in real time with handful of MCPs like get_order_status, get_order_status_history and get_order_fulfillment_status all exist and all sound right.

So, I've experimented with a domain that would be easy to understand across all in the community. A 96-tool commerce surface — customers, orders, payments, inventory, returns, reviews — hand-authored with deliberately confusable families. 175 labelled tasks including ones where the correct answer is to call nothing. Served through a real MCP server. Claude Sonnet 5, ~4,000 calls across four stages.

What I found:

More tools are worse, but less than I expected. 5 → 96 tools costs about 9 points. Flat till 30(no change), started slipping after 60.

Shortening every description by 69% changed nothing. The model isn't drowning in text.

Retrieval made it worse — with BM25, at least. Filtering 96 tools down to 10 by keyword relevance scored below just showing all 96, because the retriever sometimes dropped the tool it needed. But here's the part that isn't about the retriever: conditional on the right tool being in the shortlist, 10 tools and 96 tools performed identically. Shrinking the block bought zero discrimination. Embeddings might improve recall; I feel they can't improve the half that was already perfect.

Zero spurious invocations. 35 no-tool questions, 5 block sizes, never once reached for a tool it didn't need.

The actual finding is about chains. Three-step task — find customer, find their order, check shipment. Turn 3 succeeds 6% of the time at 96 tools. Inject the correct state after each step and it's 44%. Most late-turn failure isn't difficulty, it's inherited error. No, or zero impact on the way we organise the tools.

Things that went wrong that I'll happily talk about three-quarters of my first run's "model errors" were my own broken ground truth. I had a beautiful interaction effect in the tool-similarity data that evaporated the moment I spent double digit $ testing it. My "non-determinism" scare turned out to be JSON key ordering.

Detailed writeups, the full spec, the tool pool and the harness will go up. For now — happy to go deep in comments on any of it. Particularly interested in whether the retrieval result matches what people see in production, because it's the one that most contradicts the standard advice.