from Hacker News

The problem is familiar: as agents get access to more tools, either you overload the system with static tool lists, or you hard-code the tools at design time. Both approaches hit scaling limits quickly.

What I’ve been exploring is letting agents discover and use tools dynamically. Instead of loading every tool into the system upfront, the agent could explore an external registry at runtime, inspect tool descriptions and parameters, and decide what to use based on its current goal.

There are a few workflows I’m testing:

Manual exploration: agent lists tools, inspects them, and selects what to use.

Fuzzy auto-selection: agent describes its goal, and the system suggests a matching tool.

External LLM-assisted selection: agent outsources tool selection to another agent or service, which queries the registry and recommends a tool.

Each of these has trade-offs. Manual exploration is transparent but slow. Fuzzy matching is faster but depends on query quality. External assistance can scale to complex environments but adds system complexity.

The goal is to move away from static APIs and let agents explore tools like a developer browsing an API catalog. Search, inspect, and use tools as needed, rather than loading them all upfront.

Open questions I’m still thinking about:

Should these workflows be combined, escalating from manual to auto-selection if needed?

Should the system suggest parameter defaults or usage examples?

Should I move from basic matching to semantic search?

Would chaining tools together unlock more complex workflows?

I've written up a more detailed research note here, if anyone's interested: https://github.com/m-ahmed-elbeskeri/MCPRegistry/tree/main

Would appreciate any feedback or experiences if you've explored similar patterns.