LIBRA tests tool connections to help AI agents find missing prerequisites

Finding a tool that matches a request is not the same as finding every tool needed to carry it out. A request to change an alarm, for example, may not mention authentication. A retriever that ranks tools independently can identify the alarm-changing function while leaving login outside its shortlist.

In an arXiv preprint submitted on November 3, 2026, Zekai Li, Zhenke Liu and colleagues introduce LIBRA, short for Library Induction by Runtime Assembly. Their approach builds reusable knowledge about tool composition before user queries arrive. The reported results concern retrieval quality, not end-to-end task completion.

From descriptions to execution evidence

LIBRA starts with a catalog of tools, their public descriptions and interfaces, and an executable runtime. A language model proposes a contract for each tool: candidate calls, values or state changes that other tools could reuse, and observable conditions indicating success or failure. Execution feedback can trigger up to two contract revisions after the initial proposal.

The framework then tests candidate connections in an isolated sandbox. Matching data types alone are insufficient: a payment-card identifier and a transaction identifier can both be integers without being interchangeable.

For a value passed between tools, LIBRA compares a consumer call using the provider’s observed output with a control call from the same saved state. The control substitutes an independently constructed value or, where appropriate, omits an optional input. If the observed value succeeds and the control fails, LIBRA records an input-provenance relation. This supports the value’s necessity relative to that particular control, not every possible alternative.

Importantly, the library also distinguishes compatibility from necessity. When both calls succeed, LIBRA can retain a compatibility relation if the output and input are semantically aligned. Separately, it tests state dependencies by checking whether identical consumer calls fail before a provider runs and succeed afterward.

Recovering tools the request does not name

At query time, LIBRA keeps the original tool descriptions as the documents used for embedding-based retrieval. It does not replace them with generated contracts. Instead, a dense retriever first identifies relevant seed tools, and the library supplies connections to their providers.

The default procedure follows those connections backward for one hop. For each consumer input, it selects at most two providers: the best match between output and input field names, and the provider most relevant to the query. It then uses the connected consumers’ scores to promote providers in the ranking.

This is retrieval assistance, not a system for generating or executing a task-specific plan. The same preconstructed library can support either a single retrieval pass or an agent that searches repeatedly.

What the benchmarks show

The authors evaluate LIBRA on AppWorld’s everyday app workflows, SciToolEval’s scientific tools, and BFCL’s multi-turn function-calling tasks. Compared with the same dense retriever without library-based propagation, they report average one-shot improvements of 7.9 percentage points in Recall and 3.7 points in NDCG. Recall measures how many annotated required tools are recovered; NDCG also rewards placing relevant tools higher in the ranking.

On AppWorld, Recall among the top 15 results rises from 28.7% to 40.7%. A case study illustrates the intended mechanism: the alarm-update tool ranks first under dense retrieval, but login ranks 28th. LIBRA brings the prerequisite into the top results. In a scientific example, it recovers a required format converter initially ranked 169th.

Integrated into ToolReAGt, an iterative retrieval framework, LIBRA produces average gains of 4.5 Recall points and 2.9 NDCG points after ten iterations, across three benchmarks, three agent models and three random seeds. It does not lead every comparison: TGR-Adapt achieves higher NDCG on AppWorld.

An ablation also finds that propagating scores over schema-compatible connections without execution filtering delivers little benefit or slightly worsens results, supporting the authors’ emphasis on testing compositions.

Where the evidence stops

LIBRA requires executable tools in an isolatable, resettable environment. Its retained relations are supported only under the tested contracts and sandbox states, not universally across inputs and environments.

Construction also has an upfront cost. Reported wall-clock times range from 4 minutes 28 seconds for BFCL to 260 minutes 40 seconds for AppWorld, using jobs configured with 96 CPU workers and a GPU for field embeddings.

Coverage remains a limitation. Query-specific information can be unavailable during construction, preventing useful connections from being discovered. Existing connections cannot help when their consumer is not retrieved as a seed, and promoted tools can still remain below the cutoff.

The evaluation also uses a curated 270-task subset of SciToolEval’s 530 released tasks, excluding tasks involving tools that cannot execute in the runtime. These boundaries matter: the preprint supports improved candidate-tool retrieval in the tested settings, not a demonstrated increase in completed agent tasks.