Usually, no. If an agent has a large, task-dependent tool library, putting every tool definition in every model request spends context on capabilities the current task may not need and gives the model a larger menu to search. Keep a small set of core tools available and use tool discovery or deferred loading to bring relevant definitions into context as needed. For a small, stable toolset, sending all definitions can still be the simplest choice.
Why tool definitions use more than just a little context
A tool definition includes its name, description and parameter schema. All of that text can contribute to the request’s input tokens, whether or not the model calls the tool. The cost depends on how verbose the definitions are, not just how many tools you have.
As an Amazon Associate I earn from qualifying purchases.
AWS offers an illustrative estimate of roughly 250–500 tokens for a typical tool definition; under that estimate, 20 definitions would use about 5,000–10,000 tokens. This is an example in AWS guidance, not a measured average or a prediction for your tools. Count the actual definitions sent by your agent to know their cost. AWS Prescriptive Guidance on tool discovery
Context overhead is only part of the concern. Microsoft Foundry identifies rising token use, irrelevant context and wrong-tool selection as problems that can arise with a large toolbox. A crowded set of overlapping tools may make it harder for a model to choose the appropriate one, but no source establishes that a particular count will cause mistakes in every system. Microsoft Foundry guidance on tool search
Three ways to expose a tool library
| Pattern | What the model sees | Benefit | Trade-off | Best fit |
|---|---|---|---|---|
| Static selected tools | A chosen subset of definitions | Only selected tools use context, and the model can call them directly. | You must know which tools to expose; the selection can become stale if the server’s tools change. | A narrow, stable capability set known in advance. |
| Dynamic registration | All tools discovered from the server | Simple for a small, controlled library; the full set is available at once. | Context grows with the definitions, including tools irrelevant to the current task. | A small set or a use case that needs whole-library visibility. |
| Runtime search or deferred loading | A search interface first, then selected tool definitions | Keeps a large library accessible without putting every schema up front. | Adds discovery work and possible latency; poor descriptions or retrieval can lead to missed or wrong matches. | A large or task-dependent library. |
These patterns and trade-offs are described in AWS’s tool-discovery guidance. Tool search changes when definitions enter context; it does not, by itself, remove tools from the agent’s library or guarantee that the right tool will be found.
How deferred loading works in practice
With deferred loading, the model starts with a search mechanism and enough metadata to discover relevant capabilities. When it identifies a likely match, the system loads that tool’s definition into context so the model can call it. The OpenAI Responses API describes tool search as dynamically searching for and loading tools into model context as needed. Anthropic describes a similar on-demand approach, though its implementation is vendor-specific. OpenAI Responses API tool-search guide · Anthropic’s advanced tool-use post
Deferred loading is not free. The agent needs a discovery step, useful tool metadata and a way to handle searches that return no good match. A search can add latency, and a tool that is not found cannot be called through that route. Whether this is a worthwhile exchange depends on your definitions, model, task mix and implementation.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →What the major implementations support
OpenAI Responses API
In the Responses API tool-search guide, add tool_search and mark function tools or MCP servers with defer_loading: true. OpenAI recommends grouping related functions into namespaces or using MCP servers where appropriate, with clear high-level descriptions. The guide suggests fewer than ten functions per namespace as a best practice; that is OpenAI guidance, not a universal limit. Searchable namespace or server labels and descriptions remain visible initially. For individual deferred functions, the name and description may remain visible while the parameter schema is deferred.
OpenAI Agents JS SDK
The Agents SDK tools guide documents adding toolSearchTool() when deferred functions or hosted MCP tools use deferLoading: true. Related tools can be grouped with toolNamespace(), while a standalone capability can remain at the top level. The guide says deferred function tools and namespaces are Responses-only. It also notes that a discovery result belongs to the Agent that performed the search; it does not automatically transfer through a handoff.
Microsoft Foundry
Microsoft Foundry’s toolbox search exposes tool_search for natural-language capability lookup and call_tool for invoking discovered tools. Its documentation says matching uses BM25 over tool names, descriptions and parameter information. Microsoft suggests considering tool search when a toolbox has more than 10–15 tools. Treat that as platform-specific guidance, not a general cutoff for all models or tool systems.
MCP servers
For MCP, an OpenAI Agents API guide describes servers as publishing tool definitions and handling tool calls. The documented connection options include service-side HTTP, environment-side HTTP and stdio; which option fits depends on where the server can be reached and how it is hosted. MCP supplies a way to connect to tools, but does not determine whether every tool definition should be sent to the model. OpenAI MCP connections guide
Recommended Free Tools
How to decide whether 100 is too many
There is no provider-independent threshold in these sources that makes 100 tools inherently too many. Schema size, overlap between tools, task distribution, model behavior and discovery quality all affect the trade-off. Microsoft’s 10–15-tool suggestion applies to Foundry; AWS’s token estimate is illustrative. Neither sets a universal rule.
Anthropic’s 2025 engineering post gives examples of tool search reducing upfront definition context, including a case it describes as reducing token usage by 85%. It also reports internal evaluations where Opus 4 moved from 49% to 74% and Opus 4.5 from 79.5% to 88.1% with its Tool Search Tool enabled. These are Anthropic’s examples and internal results, not independent comparisons or guarantees for other models, tasks or providers. Anthropic’s advanced tool-use post
Choose based on representative tasks rather than a headline count. Compare the alternatives using the same task set and track:
- Input tokens spent on tool definitions.
- Whether the needed tool is discovered, including missed matches.
- Wrong-tool calls and overall task completion.
- End-to-end latency, including discovery.
- How easily the setup stays current when tools change.
- Implementation and maintenance complexity, including metadata and namespaces.
These are practical evaluation criteria inferred from the documented trade-offs, not a published universal benchmark. Record the actual schemas and configuration you test; a search approach that saves tokens but misses essential tools may be a poor fit for your workload.
Design a toolbox that is easy to search
Discovery depends on metadata. Use names and descriptions that distinguish what a tool does, when it is appropriate and what information it needs. Organize related capabilities into useful domains or namespaces, and keep frequently used core tools directly available when doing so makes sense. OpenAI and Microsoft both describe search based on tool metadata, so vague descriptions can undermine the mechanism intended to reduce context. OpenAI tool-search guide · Microsoft Foundry tool-search guide
For larger systems, academic work such as MCP-Zero explores proactive construction of toolchains. Its reported results belong to that paper’s approach and evaluation; they should not be treated as a production guarantee. MCP-Zero paper
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
