How many tools should an AI agent have?

Tool count is treated as a capability question and is really a reliability question. Selecting the right tool is a decision made from a list of descriptions, and like any decision made from a list, it degrades as the list grows and as the entries become harder to distinguish. An agent with a small set of clearly separated tools chooses correctly far more often than one with a large set containing several plausible candidates for the same job.

The second effect is on risk, and it is simpler. A capability that exists can be used in a situation nobody anticipated. Removing a tool the job does not require removes an entire class of unexpected behaviour at no cost, and it is the cheapest safety improvement available in most agent configurations because it requires no policy, no prompt and no review.

This is why connecting every available integration is a mistake even when each one individually seems harmless. The effects compound: more descriptions to distinguish between, more overlapping capabilities, more surface. Businesses that connect three things deliberately generally get better behaviour than those that connect fifteen because the connectors were offered, and the difference is visible in tool selection long before it shows up as an incident.

Given a set, the quality of the descriptions matters more than the count. A tool whose description says what it does, what it does not do, when to prefer it over the near neighbour, and what its output looks like is chosen correctly. A tool described in three words is chosen approximately. This is ordinary interface design, and the interface here has a machine on the other side of it: the same clarity that helps a new colleague pick the right one is what helps here, for recognisably similar reasons.

Overlap deserves specific attention because it is the most common defect in a grown tool set. Two tools that could both plausibly serve a request produce inconsistent behaviour across runs, and the inconsistency looks like flakiness rather than like a configuration problem. When a set has grown organically, the useful exercise is to find pairs where a reasonable reader could not say which one applies, and to merge or rename them.

There is a case for a larger set, and it is worth stating so this does not read as an argument for minimalism. Where a job genuinely spans several systems, giving the agent a way to reach each of them beats forcing it to work around a gap, and an agent that cannot reach something it needs will improvise, which is worse than a slightly crowded tool list. The rule is that each tool should be there because a step of the job needs it, not because it was available.