Progressive Tool Loading for Large Toolsets

[RICARDO51167]

AgentScope already supports ToolGroup, which helps avoid exposing all tools at once.

But for large MCP servers, one activated group may still contain dozens of tools. In that case, all tool schemas may enter the model context, causing unnecessary token usage and possibly making tool selection harder.

Would it make sense to support tool‑level progressive loading?

For example:

ToolGroup → lightweight tool metadata → search/select relevant tools → load only selected tool schemas

This could work together with the current ToolGroup mechanism:

• ToolGroup for coarse‑grained capability selection
• Tool search/discovery for fine‑grained tool selection

DeerFlow has a similar deferred tool discovery mechanism, which may be worth referencing.

Would this be useful for AgentScope, especially for large MCP toolsets?

[DavdGao]

@RICARDO51167 Sure, that would be a valuable addition to AgentScope, and I think this discussion is related to #2310.

It seems like a SearchTool would be the natural starting point. However, one design question arises when SearchTool is used alongside tool groups: how should the search scope be defined? For example, should the search include tools from inactive (i.e., unloaded) groups? In other words, what exactly does "searching" mean in this context — are we searching only among currently active tools, or across all registered tools regardless of their load state?

[RICARDO51167]

Thanks—I believe the search scope should be explicitly specified, not fixed.

Under the current semantics, searching only active groups is redundant, as activating a group already exposes all tool schemas within that group. Therefore, tool-level progressive loading needs to separate "group activation" from "schema exposure."

A possible backward-compatible design is as follows:

• eager groups maintain their current behavior: activating a group exposes all its native tool schemas.

• deferred groups are an option for large MCP toolkits: activating a group only makes its tool catalog searchable and usable; individual schemas are loaded on demand.

• search_tools searches active groups by default and provides an explicit scope="all" option for global searches.

• Search results for inactive groups contain only lightweight metadata such as tool name, description, group, and inactive status. They should not expose full schemas or grant execute permissions.

• Before execution, the group must be active and the selected schema must be loaded. Execution should still follow existing toolkit authentication, permissions, and authorization paths. For small teams, the current instant loading behavior might be preferable, as the discovery process adds latency and introduces another potential point of failure. Therefore, I believe that for large teams, incremental loading can be an optional optimization, based more on the overall architecture size than the number of tools.

In short: Activate search only is suitable for lazy loading mode, while directory-wide search can serve as an explicit discovery fallback. Search results themselves should not change the activation or authorization status.

However, I'm unsure if this constitutes over-engineering.

[iluv7]

@RICARDO51167
Thanks for clarifying—I understand and agree with your proposed approach. The deferred mode is very close to what we discussed in #2310, which might be useful context.

I’m currently building a benchmark and running evaluations around this approach. I’ll share updates there as the work progresses.

[RICARDO51167]

ok