Pattern Matrix/White Paper/A4

A4 · Minimal Tool Set

What Problem It Solves

More tools is not better. One e-commerce customer-service agent shipped its first version with the goal of "doing everything a human agent can do" and wired in 67 tools; in the first week, customer satisfaction dropped from 78% to 51%. In the post-mortem logs, when the agent faced a simple question like "when will my order arrive," it repeatedly trial-and-errored across 14 order-related tools—three wrong calls, an answer only after eight seconds, with about 70% of the thinking tokens spent on tool selection. The tool list was too long, and the model "got dizzy."

Minimal Tool Set is a counterintuitive design principle: when it comes to the tools you give an agent, few and sharp beats many and complete. Anthropic, GitHub, and Block published the same set of data in 2026—cutting the tool count from 30-plus down to around 10 actually raised accuracy. This went from a marginal optimization to required engineering.

Why the Coordinate Is "Action × Constraint"

This is the only pattern in this module that does not land on a specific topology column, so it needs to be spelled out.

• Vertical axis · Action: It governs the number of tools on the action side, which is action design, so the vertical axis lands in the Action module.
• Horizontal axis · Constraint (not Structure): Route (A1), Chain (A3), and Hierarchy (A5) are structural patterns; they specify how an agent "organizes its actions." Minimal Tool Set specifies no structure—it does not tell you how to pick tools, how to chain steps, or how to nest a sandwich. It only adds one cross-cutting constraint to all of these structures: the total number of tools must have a ceiling. In other words, it is a design discipline that runs through the entire module, not an execution form that can be drawn as a topology diagram. Its object of action is precisely routing—the cleaner the tool set, the less likely the router's selection accuracy is to drop; the less tool pollution, the less the model's attention is diluted. So the coordinate is recorded as "Action × Constraint," emphasizing that it is a cross-cutting design principle that, in practice, attaches itself to structural patterns such as A1.

Core Mechanism

The physical root of the threshold lies in attention. Anthropic's internal benchmark repeatedly confirms: when a single agent's tool count exceeds 30 to 50, selection accuracy drops noticeably; when tool descriptions add up to more than about 5,000 tokens, the tools at the end of the list exhibit the "lost in the middle" phenomenon—they cannot be selected, or they are selected wrongly. The 30 to 50 figure is roughly the conversion of this token threshold; 10 to 15 is the sweet spot.

There are three strategies for cutting tools:

Paired with cutting tools is progressive disclosure. Claude Code itself has more than 40 tools, but by default it loads only 10 to 12 in the system prompt; the rest are loaded on demand through Tool Search. This is the de facto standard for tool management in 2026—core tools resident, extended tools on-demand.

Production Scenarios It Fits

• Latency-sensitive, accuracy-sensitive user-experience scenarios: customer service, conversation, consumer-grade agents. This is where Minimal Tool Set delivers the most value.
• Controlling per-call exposure when integrating external tool protocols: even if there are hundreds of tools underneath, a single dispatch should keep the visible tools under 30, paired with Tool Search so the agent actively finds rare tools.
• A health check before splitting a multi-function agent: when an agent's tools approach the ceiling, it is often a signal that a sub-agent should be split off.

When it does not apply: code agents whose tasks are inherently highly complex (the likes of Cursor and Claude Code, which require 30-plus tools), and enterprise multi-function agents. Forcing them down to 10 will instead lose capability.

Where It Tends to Go Wrong

• Treating "all-capable" as the goal: pursuing "one agent that does everything" inevitably leads to tool bloat, and is the root of the 67-tool incident. Tools should be organized around "what outcome the user wants" (outcome-oriented), not enumerated around "what capabilities the system has."
• Losing semantic boundaries when merging: forcing tools with large semantic differences into one makes a single tool's description vague, and selection becomes harder. Merging is only justified when functionality genuinely overlaps heavily.
• Cutting without pairing with progressive disclosure: directly deleting low-frequency tools makes rare tasks impossible. The correct approach is to push down plus Tool Search, not to delete across the board.
• Not reviewing after cutting: the tool set is alive, and new features keep being added back. A fixed evict cycle is needed, or in a few months it grows back to 67.

Key Metrics

• Tools per dispatch (healthy zone 10 to 15, hard ceiling 30 to 50): exceed the ceiling and it is time to cut or split off a sub-agent.
• Total tool-description tokens (healthy zone <5,000): cross this line and lost-in-the-middle is triggered—a leading indicator of accuracy decline.
• Default-loaded / total tool ratio (healthy zone on the low side, paired with on-demand): Claude Code is 10-12 / 40+. Too high a ratio means progressive disclosure has not been done.
• Tool selection accuracy (healthy zone >90): the direct gain from cutting tools. In the customer-service case, accuracy rose by about 10 points after cutting.

Minimal Implementation Skeleton

prune(all_tools, stats, target_size=12):
                score each tool = calls in 30 days × success rate
                sort by score descending, keep the top target_size as resident
            evict_stale(stats):
                return tools with 0 calls in 30 days      # decommission candidates
            merge_similar(tools, threshold=0.5):
                use embeddings to compute description similarity, recommend merging those > threshold
            # remaining tools are not deleted; move them to a sub-agent + attach to the Tool Search entry
            

Engineering implementation points: core tools always-on, extended tools on-demand; prune by scoring on usage frequency plus success rate; keep a Tool Search entry so rare tasks remain reachable.

Enterprise Implementation Example

Six decision points for a translation/localization agent: 5 to 7 core tools carry the full pipeline (translate / detect_lang / glossary_lookup / quality_check / format_preserve / cultural_adapt); low-frequency tools such as OCR, PDF parsing, and image translation are pushed down into a dedicated sub-agent; set a 30-day evict cycle; automatically prompt to merge similar tools; keep a Tool Search entry so the agent can find rare tasks when users ask about them; configure progressive disclosure with core always-on plus extended on-demand. With the six decisions made correctly, the agent's token cost drops by about 35% and accuracy rises by about 10 points. Back to that e-commerce customer-service case: the team cut 67 tools down to 18, and a week later customer satisfaction returned to 79%—1 point higher than the 67-tool first version.

Relationship to Other Patterns

• Tool Dispatch (A1): a same-cell pair with opposite roles. A1 solves "given a tool set, how to pick accurately," while A4 solves "before picking, first cut the tool set down to something pickable." A4 is the precondition for A1's accuracy—with less tool pollution, the router does not lose points.
• Layered Retention (Memory module): progressive disclosure shares the same origin as the Memory module's layered loading; both are the attention-management idea of "core resident, the rest fetched on demand."
• Plan-Execute (A2): when tools approach the ceiling, splitting off a sub-agent often happens together with A2's task decomposition—pushing down secondary capabilities along with their tools.

What This Pattern Teaches

Minimal Tool Set is not about trimming tools; it is about leaving the agent its focus—an LLM's attention is a scarce resource, and opening 50 tools at once is like opening 50 browser tabs at once: no one can think deeply.

This page is part of the ADPS pattern white papers. Back to the pattern matrix, or see the runnable code catalog.