Exploring scalable agent tool use: dynamic discovery and execution patterns

I’ve been thinking a lot about how AI agents can scale their use of external tools as systems grow.

The issue I keep running into is that most current setups either preload a static list of tools into the agent’s context or hard-code tool access at build time. Both approaches feel rigid and brittle, especially as the number of tools expands or changes over time.

Right now, if you preload tools:

• The context window fills up fast.
• You lose flexibility to add or remove tools dynamically.
• You risk duplication, redundancy, or even name conflicts across tools.
• As tools grow, you’re essentially forced to prune, which limits agent capabilities.

If you hard-code tools:

• You’re locked into design-time decisions.
• Tool updates require code changes or deployments.
• Agents can’t evolve their capabilities in real time.

Either way, these approaches hit a ceiling quickly as tool ecosystems expand.

What I’m exploring instead is treating tools less like fixed APIs and more like dynamic, discoverable objects. Rather than carrying everything upfront, the agent would explore an external registry at runtime, inspect available tools and parameters, and decide what to use based on its current goal.

This way, the agent has the flexibility to:

• Discover tools at runtime
• Understand tool descriptions and parameter requirements dynamically
• Select and use tools based on context, not hard-coded knowledge

I’ve been comparing a few different workflows to enable this:

Manual exploration
The agent lists available tools names only, for the ones that seem promising it reads the description and compares them to its goal, and picks the most suitable option.
It’s transparent and traceable but slows things down, especially with larger tool sets.

Fuzzy auto-selection
The agent describes its intent, and the system suggests the closest matching tool.
This speeds things up but depends heavily on the quality of the matching.

External LLM-assisted selection
The agent delegates tool selection to another agent or service, which queries the registry and recommends a tool.
It’s more complex but helps distribute decision-making and could scale to environments with many toolsets and domains and lets you use a cheaper model to choose the tool.

The broader goal is to let the agent behave more like a developer browsing an API catalog:

• Search for relevant tools
• Inspect their purpose and parameters
• Use them dynamically when needed

I see this as essential because if we don’t solve this:

• Agents will remain limited to static capabilities.
• Tool integration won’t scale with the pace of tool creation.
• Developers will have to continuously update agent toolsets manually.
• Worse, agents will lack autonomy to adapt to new tasks on their own.

Some open questions I’m still considering:

• Should these workflows be combined? Maybe the agent starts with manual exploration and escalates to automated suggestions if it doesn’t find a good fit.
• How much guidance should the system give about parameter defaults or typical use cases?
• Should I move from simple string matching to embedding-based semantic search?
• Would chaining tools at the system level unlock more powerful workflows?
• How to balance runtime discovery cost with performance, especially in latency-sensitive environments?

I’ve written up a research note if anyone’s interested in a deeper dive:
https://github.com/m-ahmed-elbeskeri/MCPRegistry/tree/main

If you’ve explored similar patterns or have thoughts on scaling agent tool access, I’d really appreciate your insights.
Curious to hear what approaches others have tried, what worked, and what didn’t.

Open to discussion.