Key Takeaways
- Static tool injection doesn’t scale: access to unlimited tool libraries drives up token consumption.
- Dynamic tool selection controls token consumption by loading only what the agent needs.
- Boomi MCP Gateway delivers this as infrastructure: Tool Groups, policy gating, and auto-refresh.
Dynamic tool selection lets agents work with massive tool libraries that would otherwise exceed context window limits. The assumption that agents could discover tools at runtime has existed since the start of MCP, but recent advancements in “tool search” capabilities following the Advanced Tool Use framework from Anthropic have made it practical for production use.
This evolution in how agents interact with the MCP protocol unlocks new capabilities without pushing context windows to extreme limits, making large-scale tool catalogs viable for the first time. This affects security posture, orchestration strategy, and ultimately how scalable your agent architecture can become.
What Is Dynamic Tool Selection?
As agent tool ecosystems grow, the traditional approach of sending the entire tool catalog in every request quickly breaks down. Large schemas increase token usage, slow down responses, and push the model’s context window to its limits.
The idea behind dynamic tool selection is simple but powerful: register the full tool catalog with the API, but avoid loading everything into the model’s context up front.
Instead, tools can be marked as deferred with defer_loading: true
You register the full tool catalog with the API, but mark most tools as deferred, so they are discoverable but not injected into the model’s context up front. The model initially sees only a search primitive and any explicitly non-deferred core tools. When the model needs additional capabilities, it calls the search primitive. The API returns a small number of tool_reference objects, typically three to five. Only those references get expanded into full schemas inside the active context.
This pattern lets agent systems, MCP servers, and gateway-based architectures scale to hundreds or thousands of tools without exploding context size, making dynamic tool selection a key building block for real-world, production-grade agent infrastructure.
Why Static Full Catalog Injection Breaks at Scale
Static tool injection assumes that showing the model everything improves decision-making. That works at a small scale, but it degrades rapidly as catalogs grow.
1. Context and Token Overhead
Tool schemas consume significant context. Anthropic’s data shows that in typical production setups, 50 tools cost 10K to 20K tokens of context that cannot go toward reasoning, memory, or output.
Boomi MCP Gateway’s dynamic tool selection changes the cost structure. The upfront search primitive costs approximately 500 tokens. A typical search returns three to five relevant tools at roughly 3K tokens total. In Anthropic’s framing, this results in 8.7K tokens of total context consumption, compared with 77K in the static approach.
2. Accuracy Degradation
Selection accuracy degrades when too many tools are visible simultaneously. Anthropic’s evaluation data shows that selection quality drops significantly once models see more than 30 to 50 tools in conventional setups. Enabling Tool Search improves MCP evaluation accuracy by reducing the visible tool space.
Fewer visible tools reduce interference and ambiguity. In production, this translates directly into fewer incorrect tool calls and fewer retry loops.
3. Observability and Governance Blind Spots
When every tool is scoped to every use case, it becomes harder to trace agent reasoning, and relies on an agent’s reasoning to determine what tools to use within a given prompt, which can also lead to undesirable activity or data access.
Static injection cannot put boundaries around tool selection. Dynamic selection makes the boundaries clear and simple. Tool discovery produces a shortlist you can log, audit, and analyze.
The Context and Token Management Value of Dynamic Tool Discovery
Tool definitions consume significant portions of context. By reducing tool evaluation work, the context window can be directed at the work required from a prompt, instead evaluating all possible tools.
Tool search exists specifically to address both context efficiency and selection accuracy. By paying for only the tools actually needed for a given task, you preserve most of your window for reasoning, chaining, and execution.
For teams running multi-step agents, retrieval-augmented workflows, or long-lived sessions, complex workloads regain an important proportion of the context window for task-related work, not tool evaluation.
How Dynamic Tool Selection Improves Security, Governance, and Observability
Dynamic selection is not a silver bullet for LLM security, but it does increase structural control.
Threat models increasingly include tool poisoning and prompt injection embedded in tool metadata. If malicious or compromised tool descriptions get injected into the model’s decision boundary, they can manipulate tool calls or bypass guardrails.
Boomi covers the full AI attack surface in The CISO’s Guide to AI Governance and Control
Dynamic selection contributes to several governance outcomes:
- Reduced attack surface in context: fewer tool schemas are present at any moment.
- Contextual least privilege: only tools discovered for the current task are eligible for use.
- Observability: discovery produces an explicit shortlist that can be logged and audited.
In other words, dynamic selection narrows exposure windows and clarifies accountability.
Improving Agent Efficiency and Orchestration
Dynamic tool selection improves efficiency in two complementary ways.
First, it improves tool choice. Research reports significant accuracy gains in MCP evaluations when dynamic selection mechanisms are enabled.
Tool selection quality is also heavily influenced by prompt design. A well-structured prompt guides the model toward the correct tools, while a vague or overloaded prompt makes selection less reliable, leading to unnecessary searches or incorrect tool usage. For a deeper look at how prompts shape tool selection and agent reasoning at runtime, see this related post.
Second, it improves orchestration discipline. Once you can reliably discover relevant tools, you can begin to migrate multi-step agentic sequences to deterministic workflows. Instead of relying on probabilistic chaining inside the LLM for strict multi-step processes, you can combine discovery with programmatic tool calling, reducing context pollution from intermediate reasoning and making flows more predictable.
Dynamic tool selection often becomes the first step toward a more governed, hybrid orchestration model. Rather than loading every available tool into context up front, the agent discovers what it needs when it needs it.
How to Use Dynamic Tool Selection with Boomi
Boomi’s Dynamic Tool Group Selection is a governed, runtime implementation of the same principle: agents should see only the tools they need, when they need them, and tool exposure should stay centrally controlled.
Within Boomi MCP Gateway:
- Tool Groups let teams organize tools across multiple servers into reusable collections aligned to workflows.
- These groups can be applied across multiple agents, keeping access consistent across environments.
- Policy gating enables runtime control based on identity, environment, or workload.
- Tool exposure becomes a dynamic control surface rather than a static registry decision.
Dynamic Tool Selection also addresses the stale-tool-view problem. By aligning with MCP list changed notifications, Boomi can signal clients when tool access changes. In clients and IDEs that support this behavior, the tool list can auto-refresh. Where client support is incomplete, fallback behavior may require a restart or periodic resync, depending on the client.
The result is a cross-client, runtime-governed implementation of dynamic tool selection, not just a prompt engineering pattern.
To see how Boomi helps you govern tool access and agentic traffic at scale, read more about the Agent Control Plane.