Give Claude Fewer, Sharper Tools

A tool-set design principle: expose the smallest set of tools that covers the job, each doing one clear thing, rather than a sprawling menu with overlapping or near-duplicate functions. Tool accuracy is a selection problem before it's a calling problem.

Claude has to choose which tool to call before it can call it well. Every additional tool widens that choice and adds a chance to pick the wrong one — and overlapping tools (three ways to fetch a user) make the choice genuinely ambiguous even for a careful reader. A tight set where each tool owns a distinct capability makes selection obvious, keeps each description focused, and leaves less context spent on the tool menu itself. Fewer, sharper tools reliably beat a large, fuzzy toolbox.

When you're designing or auditing an agent's tools — especially if you've watched Claude call the wrong function, ignore a tool it should use, or thrash between similar ones. A good prompt to yourself: which two tools here would confuse a new hire?

When a genuinely broad surface is required and the tools are truly distinct — a real integration may need many non-overlapping tools. The rule is against redundancy and vagueness, not against breadth that the task actually demands.

Here is my current tool set: <list tools with descriptions>. Audit it for the model's benefit: which tools overlap or could be confused, which are unnecessary, and how would you consolidate this into the fewest, most distinct tools that still cover every capability? Show the merged set with one-line descriptions.

An agent had search, find, query, and lookup — four tools that all hit the same database. Claude kept guessing between them and sometimes chained two. Collapsing them into one query_records(filter) removed the ambiguity entirely; tool-selection errors dropped to near zero because there was only ever one right call.

When you can't reduce count, disambiguate by making names and descriptions state not just what a tool does but when to prefer it over its neighbour: 'use search_orders for status/date filters; use get_order only when you already have an exact ID.' Encoding the choice into the descriptions does the routing work for the model.

• Adding a new tool for every edge case until the menu is unnavigable, instead of extending an existing one's parameters.
• Shipping near-duplicate tools with overlapping scope and hoping Claude infers the intended split.
• Judging tools only by whether each works in isolation, never by whether the set is easy to choose from.