Agentic and Multi-Agent Systems

Can models decide better than retrievers which tools to use?

Traditional retrieval picks tools upfront based on initial queries, but do models themselves make better decisions about tool needs as they reason? This explores whether authority over tool selection should move from external systems to the LLM.

Note · 2026-05-03 · sourced from Tool Computer Use

MCP-Zero's structural argument is that retrieval-based tool injection — match the user query to relevant tools via semantic similarity and inject only those — fails on realistic agent tasks for three specific reasons. First, retrieval is passive: the external retrieval system selects tools based on the initial query rather than letting the model express its evolving needs as it reasons through the task. Second, there is semantic misalignment between colloquial user inputs and formal API documentation — the distributional mismatch reduces retrieval precision. Third, retrieval is single-round: it happens once per query and cannot accommodate progressive refinement of subtask requirements or correction when initial retrievals prove inadequate.

A query like "Debug the file" needs filesystem tools, code-generation tools, and command-execution tools — three different domains that no single semantic match against the initial query can identify, because the requirements only become clear as the model reasons.

MCP-Zero's response inverts the direction. Proactive Tool Request: the model emits a structured <tool assistant>server: ... tool: ...</tool assistant> block specifying what it needs in API-aligned vocabulary — bypassing the colloquial-to-formal mismatch. Hierarchical Vector Routing: a coarse-to-fine retrieval first selects candidate servers, then ranks tools within them — only top-k descriptions returned, reducing context overhead. Iterative Proactive Invocation: the model can initiate multiple tool requests across the conversation for different subtasks, building a cross-domain toolchain progressively, and revise requests if returned tools are insufficient.

The deeper move is to return the authority of tool requirement specification to the LLM itself — leveraging chain-of-thought, self-reflection, and planning that modern models already have. The implication is that for thousands-of-tools ecosystems, the retrieval system should be a service the model calls, not a gatekeeper that pre-selects what the model is allowed to consider. This is the same architectural move as Will agents compete for attention just like users do? viewed from the supply side: tools become services agents discover and invoke, not options pre-selected by an upstream retriever.


Source: Tool Computer Use

Related concepts in this collection

Concept map
15 direct connections · 136 in 2-hop network ·dense cluster

Click a node to walk · click center to open · click Open full network for a force-directed map

your link semantically near linked from elsewhere
Original note title

proactive tool retrieval lets the model itself decide when and which tools to fetch — replacing passive single-round semantic matching with iterative cross-domain toolchain construction