Feature request: dynamic tool discovery/loading (like Mastra's ToolSearchProcessor) to avoid putting hundreds of tools in the agent context

[igorkamyshev]

Problem

When an agent has access to a large tool library (hundreds of tools), putting all tool definitions into the model context upfront is expensive in tokens and can degrade tool-selection quality. I'd like a built-in way to keep tools out of the context by default and let the agent discover/load them on demand.

Proposed solution

Something similar to Mastra's ToolSearchProcessor: https://mastra.ai/reference/processors/tool-search-processor

The idea: instead of exposing every tool upfront, expose two meta-tools to the agent:

• search_tools — the agent searches the tool library by keywords and gets back the top matches.
• load_tool — the agent activates a specific tool so it becomes available on the next turn.

Nice-to-have options seen in the Mastra design:

• topK / minScore to control search results.
• An autoLoad mode that activates matched tools directly from the search step, collapsing the two-step (search → load) flow into one.
• Loaded-tool state tracked either in-memory (per thread, with TTL) or derived from conversation messages so it's restart-safe.
• A request-aware filter hook to hide/block certain tools per request.
• Cache-friendly behavior (append-only loads so the cached prompt prefix stays stable).

Why

This would let Flue agents scale to large tool sets without paying the upfront context cost for every tool, keeping only the meta-tools plus whatever the agent actually needs loaded.

References

• Mastra ToolSearchProcessor reference: https://mastra.ai/reference/processors/tool-search-processor