Load Tools Just in Time

An agent with a long tool menu does not automatically become more capable. It has more names to distinguish, more descriptions to read, and more chances to select a near-match rather than the right operation. The problem becomes visible when a general assistant accumulates databases, ticketing, files, browser actions, deployment commands, and a dozen domain-specific integrations. A straightforward request can arrive with a crowded control panel already competing for attention.

The practical move is to keep a small core toolset available and load specialized tools only after the task shows it needs them. Give the agent enough capability to inspect the request, search a catalog, and perform common safe reads. Then expose a bounded group of specific tools when the task, target system, and intended action are clear. This is progressive disclosure for agent tools: not fewer capabilities overall, but fewer irrelevant capabilities in the active working set.

OpenAI’s tools guide describes tool search as dynamically loading relevant tool definitions to optimize token usage, and says deferred function definitions can be loaded once the model decides they are needed.^[1] Anthropic documents the same design for MCP tools: names and server instructions can be present initially while full tool definitions are deferred until needed, reducing MCP context use.^[2]

Separate core tools from specialist tools

Start with the jobs that recur across almost every request. A typical core set might include: inspect the workspace, search approved capabilities, read a named record, and ask for or check a required approval. These tools should be small, safe, and obvious enough that the agent can use them without an exploratory search.

Everything else belongs in a specialist group. “Create an invoice,” “rotate a deployment,” “change production DNS,” and “publish a social post” should not sit next to a simple file reader for every turn. Group tools by the task boundary a person would recognize: billing, source control, customer support, analytics, or hosting. Give each group a concise catalog description that says what it can do, when it should be searched, and its important permission boundary.

This is not merely a cost optimization. A smaller visible surface gives a model a clearer routing decision and gives your team a better place to define safety rules. The catalog should answer, “When is this group relevant?” before the agent sees a powerful write method.

Copy this tool-discovery contract

Use this as an agent instruction, a tool-catalog design review, or a gateway policy. Adjust the names to your system, but keep the sequence explicit.

ALWAYS-AVAILABLE CORE
- inspect_context: identify the task, target, and available evidence
- search_capabilities: find a specialist group by task and system
- read_status: perform scoped, read-only checks
- request_or_check_approval: verify permission for consequential actions

WHEN A REQUEST ARRIVES
1. Classify the intended outcome: answer, retrieve, draft, or change state.
2. Use only core tools until the target system and action are known.
3. Search the capability catalog with: [system] + [verb] + [object].
4. Load the smallest specialist group that can complete the named task.
5. Read current state before any write.
6. For a consequential action, show the exact target and proposed effect,
   then require the configured approval boundary.
7. Unload or ignore the specialist group after the task; do not treat a
   prior tool as permission for a new target.

CATALOG ENTRY FORMAT
Group: [e.g., cpanel publishing]
Use when: [specific task and system]
Read tools: [named, scoped methods]
Write tools: [named methods]
Requires before write: [current-state check / approval / both]
Forbidden: [unrelated domains, bulk deletion, credential access]

The phrase “smallest specialist group” matters. Do not load a whole administration server just because the task needs one report. A reporting request may need only list_campaigns and get_campaign; a change request may additionally need update_campaign, with its own approval rule. Keep tool names concrete and descriptions front-loaded with the words the agent will search for. Anthropic notes that tool search matches against descriptions and that critical information should appear early; vague descriptions make discovery less reliable.^[2]

Test the catalog like a routing layer

Make a compact test set of real task wordings, especially ambiguous ones. For each, record the intended group, tools that must not load, and whether a write is allowed. Then test “show last month’s invoice totals,” “refund invoice 824,” and “delete all test invoices” separately. Similar nouns do not imply the same permission or capability set.

Inspect tool-search logs or traces if your platform provides them. A successful final answer can hide bad routing: perhaps the model loaded six irrelevant groups before finding the right one, or it searched a write-capable system for a question that a read-only tool could answer. Tune group descriptions, not just the agent prompt, when that happens.

Failure mode: hiding a critical control

Deferred tools add a discovery step. If an essential safety check, emergency stop, or ordinary read operation is hidden behind vague search terms, the agent may fail to find it or take an improvised path. Keep universal guardrails and the few tools needed on every turn in the core set. Also test catalog changes after renaming tools or moving services; a correct capability that cannot be found is operationally absent.