III · Tool Use & EnvironmentMature★★

Tool Loadout

also known as Tool Subset Selection, Per-Task Tool Filtering, Tool Filter, Limit Exposed Tools

Select a small task-relevant subset of available tools per request rather than exposing the full registry to the model.

Context

A team is running an agent with access to a large tool registry: an MCP catalogue, a plugin marketplace, or an internal directory holding fifty or more tools. Only a handful of those tools are relevant to any single user request, and the team can build a quick classifier (rule-based or model-based) that runs ahead of the main loop.

Problem

Function-calling accuracy falls off sharply once the model is shown more than roughly twenty tool definitions at once: the model picks the wrong tool, mixes up similarly named ones, or ignores the right tool entirely. Worse, every irrelevant tool definition still consumes context tokens on every call. Exposing the full registry to the main inference is effectively unusable past a certain size, and a static loadout cannot adapt to per-request intent.

Forces

  • Filter quality (does the agent get the right tools?).
  • Filter cost (one extra model call per request, or rule-based).
  • Tool-discovery latency on each request.

Example

A general-purpose agent has access to a 100-tool registry and selection accuracy is poor because the model cannot keep that many tool descriptions in working attention. The team adds a quick classifier ahead of the main loop that picks N relevant tools per request (rule-based by routed lane, or model-based). The agent's main loop now sees only the curated subset; selection accuracy and latency both improve.

Diagram

Solution

Therefore:

Before the main loop, classify the request and select N relevant tools (rule-based: by routed lane; or model-based: a quick classifier picks tools). Expose only the selected subset to the agent's main inference call. Tools outside the subset are unavailable for this request.

What this pattern forbids. The agent's tool palette is exactly the filtered subset for the current request; tools outside the subset cannot be invoked.

The smaller patterns that complete this one —

  • usesRouting★★— Classify an incoming request and dispatch it to the specialist (lane / agent / model) best suited to handle it.

And the patterns that stand alongside it, or against it —

  • complementsAgent-Computer Interface★— Design the tool surface for an LLM agent specifically, with affordances different from human-facing CLIs.
  • complementsTool Discovery★— Let the agent discover available tools at runtime rather than hardcoding the tool list at agent build time.
  • conflicts-withTool Explosion✕— Anti-pattern: expose every available tool in every request and watch function-calling accuracy collapse.
  • alternative-toTool Search Lazy Loading★— Defer loading tool schemas into the context window until a search step shows they are needed.
  • alternative-toMCP-as-Code-API★— Materialize MCP servers as a directory of typed code wrappers so the agent writes code that imports them and large tool outputs flow between calls inside the sandbox without ever entering the model's context window.
  • alternative-toTool Loadout Hot-Swap✕— Anti-pattern: add or remove tool definitions during a running task so the tool set the model sees changes from turn to turn.
  • complementsAgent Adapter★★— An interface layer connecting an agent's tool-calling protocol to heterogeneous external tools, normalizing their schemas into one the agent expects.
  • alternative-toTool Over-Broad Scope✕— Anti-pattern: grant the agent tools scoped so broadly that a single hallucinated argument can escalate into a privilege incident.
  • complementsProgressive Tool Access★— Grant tool permissions on a need-to-use basis, starting minimum and expanding only as the agent proves competency, mirroring how humans earn system access.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

Used in frameworks

References

Provenance