ToolWeaver: Weaving Collaborative Semantics for Scalable Tool Use in Large Language Models
Authors: Bowen Fang
Wen Ye
Yunyue Su
Jinghao Zhang
Qiang Liu
Yesheng Liu
Xin Sun
Shu Wu
Jiabing Yang
Baole Wei
Liang Wang
Venue: ICLR 2026 Poster (2026)
Keywords: Large Language Models
Tool-Augmented LLMs
Scalable Tool Use
Tool Learning
Collaborative Semantics
Primary area: foundation or frontier models, including LLMs
TL;DR: We enable LLMs to use massive toolsets by learning compact, compositional tokens whose structure is guided by collaborative semantics, boosting scalability and multi-tool reasoning.

Abstract: Prevalent retrieval-based tool-use pipelines struggle with a dual semantic challenge: their retrievers often employ encoders that fail to capture complex semantics, while the Large Language Model (LLM) itself lacks intrinsic tool knowledge from its natural language pretraining. Generative methods offer a powerful alternative by unifying selection and execution, tasking the LLM to directly learn and generate tool identifiers. However, the common practice of mapping each tool to a unique new token introduces substantial limitations: it creates a scalability and generalization crisis, as the vocabulary size explodes and each tool is assigned a semantically isolated token. This approach also creates a semantic bottleneck that hinders the learning of collaborative tool relationships, as the model must infer them from sparse co-occurrences of monolithic tool IDs within a vast library. To address these limitations, we propose ToolWeaver, a novel generative tool learning framework that encodes tools into hierarchical sequences. This approach makes vocabulary expansion logarithmic to the number of tools. Crucially, it enables the model to learn collaborative patterns from the dense co-occurrence of shared codes, rather than the sparse co-occurrence of monolithic tool IDs. We generate these structured codes through a novel tokenization process designed to weave together a tool's intrinsic semantics with its extrinsic co-usage patterns. These structured codes are then integrated into the LLM through a generative alignment stage, where the model is fine-tuned to produce the hierarchical code sequences. Evaluation results with nearly 47,000 tools show that ToolWeaver significantly outperforms state-of-the-art methods, establishing a more scalable, generalizable, and semantically-aware foundation for advanced tool-augmented agents.

Published as a conference paper at ICLR 2026
TOOLWEAVER, WEAVING COLLABORATIVE SEMAN- TICS FOR SCALABLE TOOL USE IN LARGE LANGUAGE MODELS
Bowen Fang Wen Ye!2, Yunyue Su', Jinghao Zhang', Qiang Liu', Yesheng Liu² Jiabing Yang" Xin Sun' Shu Wu Baole Wei Liang Wang'
NNew Laboratory of Pattern Recognition (NLPR), Institute of Automation, Chinese Academy of Sciences (CASIA)
Sccooo of Artificial Intelligence, University of Chinese Academy of Sciences #Zhongguaneun Academy
*Zhongguancun Institute of Artificial Intelligence bwn. fange gma com, shu. wuêr.pr. ia. ac. en, weibacle@zgcii cn
ABSTRACT
Prevalent retrieval-based tool-use pipelines struggle with a dual semantic chal- lenge: their retrievers often employ encoders that fail to capture complex seman- tics, while the Large Language Model (LLM) itself lacks intrinsic tool knowledge from its natural language pretraining. Generative methods offer powerful al- ternative by unifying selection and execution, tasking the LLM to directly learn and generate tool identifiers. However, the common practice of mapping each tool to unique new token introduces substantial limitations: it creates a scala- bility and generalization crisis, as the vocabulary size explodes and each tool is assigned semantically isolated token. This approach also creates a semantic bot- tleneck that hinders the learning of collaborative tool relationships, the model must infer them from sparse co-occurrences of monolithic tool IDs within a vast library. To address these limitations, we propose ToolWeaver, a novel generative tool learning framework that encodes tools into hierarchical sequences. This ap- proach makes vocabulary expansion logarithmic to the number of tools. Crucially, it enables the model to learn collaborative patterns from the dense co-occurrence shared codes, rather than the sparse co-occurrence of monolithic tool IDs. We generate these structured codes through novel tokenization process designed weave together a tool's intrinsic semantics with its extrinsic co-usage patterns. These structured codes then integrated into the L.MM through generative alignment stage, where the model is fine-tuned to produce the hierarchical code sequences. Evaluation results with nearly 47,000 tools show that ToolWeaver significantly outperforms state-of-the-art methods, establishing a more scalable, generalizable, and semantically-awe foundation for advanced tool-augmented agents]
INTRODUCTION
LLMs have rapidly evolved into powerful interactive agents by integrating with external tools, en- abling them to access dynamic information and perform comprehensive real-world tasks (aao et al.
2023 Qin al. 2023] Hao al.] 2023 Gao al., 2024b Wang et al.) 2024b Zhao et al.) 2025 Cheng et al., 2025). Concurrently, the number and diversity of available tools have grown substan- tially, ranging from general services to domain-specific APIs, leading to significant challenges such
scalability and generalization for tool selection and execution (Mialon et al. 2023).
Existing methods (Patil et al. 2023 Hao et al., 2023 Paranjape et al. 2023 Yao et al. 2023 Wang et al. 2024b Qin et al. 2024 have focused on equipping LLMs with tool-use capabilities through
"Corresponding authors.
Data and code available
weaver

---

Published as a conference paper at ICLR 2026
retrieval-based or generative approaches. Retrieval-basee methods, such as TooILLM (Qin et al., 2023) and Gorilla (Patil et al. (023), employ external retrievers to select tools from a large corpus, which are often constrained by the LLM's imput length and add pipeline complexity. In contrast, generative methods (Hao et al. 2023; Wang et al. 2024b; Zhu et al., (025) offer end-to-end sim- plicity by fine-tuning the L.M to directly generate tool invocations. A common strategy in this paradigm is to map each tool to unique special token (Liu et al. 20244)
However, this simple "one-token-per-tool"" paradigm suffers from two fundamental drawbacks. Firstly, it faces a critical scalability and generalization challenge. As illustrated in Figure[a a). the vocabulary size grows linearly with the number of tools, which hinders generalization as each new tool requires semantically isolated token. For a model like Llama-3-8B (Dubey et al.) (024) with a vocabulary of 128,256, integrating large benchmark like ToolBench would require adding nearly 47,000 new tokens. This massive injection of out-of-vocabulan (OOV) tokens leads to significant memory overhead and risks disrupting the model's pretrained linguistic knowledge, causing catas- trophic degradation of its general language capabilities (Wang et al. 2024a). Secondly, it suffers semantic bottleneck for complex reasoning. By flattening tools into isolated, unique tokens, the model struggles to learn collaborative relationships, it is forced to rely the statistically sparse co-occurrence of their individual IDs. For instance, consider the query "is a good day to take my kid to the park?" as illustrated in Figure bb). To answer this comprehensively, model needs to infer the relationship between tools like Rea i Weather and Air Qual 1 i ity. However, because the joint appearance of any specific tool pair is rare in a vast library, the model might check the weather but fail to consider air quality, thus providing an incomplete or misleading answer.
To address these challenges, we propose Toveee framework that fundamentally rethinks tool representation. Instead of flat identifiers, ToolWeaver represents each tool as a composi- tional sequence of discrete codes. This hierarchical structure, generated via our novel, unsupervised collaborative-awee vector quantization, is not only highly cacllalle-reuucee vocabulary expansion from linear to logarithmic- more importantly, it inherently compatible with the autoregressive nature of LLMs and enables the model to learn from dense collaborative signal.
By jointly modeling a tool's intrinsic function and its extrinsic co-usage patterns, this method encourages functionally related tools to share codes. For instance, Realtime Weather (<T1.>><T2.>>) and Air Quality (<T1_1><) <<T1_>><T2.2>> can share a parent code (<T1_1>) that emerges group tools for shared context like "outdoor conditions", allowing the model to learn their collaborative nature from the dense co-occurrence of the shared code rather than the sparse co-occurrence of individual tools. Subsequently, these structured codes are integrated into the LLM via a generative alignment stage, training the model to produce the hierarchical code sequences for complex tool invocation. In summary, our main contributions are follows:
* We propose Weaver a novel framework that represents tools as compositional codes. A collaborative-awart tokenization process generates these codes, enabling the model to learn robust collaborative patterns from the dense co-occurrence of shared codes, thus over- coming the scalability and semantic bottlenecks of prior methods while enhancing gener- alization.
We introduce a multi-stage generative alignment process that effectively aligns the struc- tured tool codes with the LLM's s internal knowledge. This fine-tuning teaches the model to natively generate the hierarchical code sequences, enabling both accurate tool selection and complex external tool use.
Experimental validation on large benchmark of nearly 47,000 tools demonstrates that Tool Weaver significantly outperforms state-of-the-ar methods in complex task completion while substantially mitigating the impact on the LLM's general capabilities.
2 RELATED WORK
2.1 LARGE LANGUAGE MODELS WITH TOOLS
Equipping LLMs with external tools (e.g., APIs, knowledge bases) enables them to execute complex, interactive tasks. Current methods are broadly categorized as tuning-free free or tming-basee Tuning- free approaches use in-context learning, placing tool descriptions and examples in the prompt to
2

---

Published as a conference paper at ICLR 2026
(b)
Tools
One- Token-per-Tool
it good day take my kid the park?
Realtime Weathor
<Realtime Weather>
<Top Moviess
means should weather
using the <Realtime Weather> function.
<Air Quallty
<Game Search?
Air Quality
N new tokens
Yes, it's perfect day! It's and 22"C.
Top
ToolWeaver
Kid's park nip? Safety key.
ther to air quality. I'll <TI <T2_F>
<
<TL
<12
<T2
<T1_1>
<12_2>
<TL
<1__1>
While it's the quality is unheulthly day. to stay indoors.
Total Tools: N 96,985
LogN new tokens
(c)
Vector Quantization
Realtime Weather
Expand Vocabulary
Air Quality
Embeehling
Encoder
Docoder
Embrdding
Alignment Tuning
User:
What's the current weather in Tokyo?
Thought: The asking current wealber ... need use weather toul
Action: <TI_
Document: (temperanure: ...] Observatio: The currett wenther in Tokyo
Ceolinb
Cadibbak
Figure I: An overview of the ToolWeaver framework. (a) We contrast the standard "one-token-pee tool" method, which creates massive flat vocabulary, with compositional approach that scales logarithmically. (b) Our model leverages collaborative signals between tools (e.g.. Rea 1 ie Weather and Air Qua 1 fty for complex reasoning where "one-token-per-tooo representations fail. (c) The Wealer architecture learns these structured representations through a collaborative- aware vector quantization process, which are then integrated into an LLM.
guide the LLM without updating its parameters (Qin al. 2024 Paranjape al. 2023
Yao al.
2023 Wu et al.. 2024 Liu et al. 2025). In contrast, auning-based methods fine-tune [.MMs on
tool-use datasets (Schick et al. [2023 Wang et al., 2024b Su al.) 2025). This has evolved from
domain-specifie tools like retrieval modules (Gao et al. 2024c) (c.g.. WebGPT (Nakano et al. 2022
for web browsing (Brown al.) 20200) to general-purposs toolsets (Qin al. 2023 et 2023)
(e.g.. Toolformer (Schick et al.
2023) using calculators, QA systems) (Zhuang et al. 2023 Chen
al. 2025).
The growing scale of toolsets, highlighted by benchmarks like ToolBench (Qin et al., 2023) and
API-Bank (Li et al., [202)), creates a major scalability problem. In-context methods face context window limitations, while tuning-based methods require constant retraining. This necessitates more efficient tool retrieval and selection mechanisms.
2.2 TOOL SELECTION
With expanding toolkits, effective tool selection is critical. One approach is retriever-basede selection, which treats tools as documents to be ranked by information retrieval models like BM25 (Robertson Zaragoza 2009) or dense retrievers (Karpukhin et al. |0200 Xiong et al. 2020). as used Gorilla PPtil et al. 2023). While techniques like query rewriting (Chen al. (0224) and iterative refinement
Xu et al. 2024) improve accuracy, these pipelines suffer from high latency and complexity.
An alternative is generative selection, where each tool is mapped to single, atomic token that the LLM generates directly (Hao et al. 2023] Wang et al. 2024b). ToolGen (Wang et al. 2024b) virtual tokens. However, this approach scales poorly: large tool vocabularies increase memory and latency, artificial tokens can disrupt linguistic priors, and the flat token representation impedes reasoning semantic tool relationships.
exemplifies this by integrating tool knowledge
3

---

Published as a conference paper at ICLR 2026
2.3 INTEGRATING COLLABORATIVE SEMANTICS INTO LLMS
Recent research seeks to integrate collaborative semantics into LLMs, bridging the semantic gap between their native linguistic space and the symbolic knowledge embedded in collaborative sig- nals (Lin et al. 2025). Existing methods primarily project collaborative knowledge into the LLM's semantic space. For instance. SeLLa-Rec (Wang al. (025) maps collaborative knowledge to specialized tokens, while LC-Rec (Zheng et al., 2024) utilizes learning-base based vector quantization a
Variational AutoEncoder (RQ- (AE) (Lee et al.) 2022) to generate struc- tured identifiers. Others leverage graph structures, such as GAL-Rec (Guan et al., [024], which uses GNN-inspired techniques to teach relational patterns. This principle also extends to generative retrieval, where models like CFRAG (Shi et al. 2025) infuse collaborative filtering into the RAG pipeline.
Despite their progress, these approaches share fundamental limitation: they all rely post-hoc alignment. This paradigm introduces semantically isolated identifiers and then forces the model to learn their meaning through separate alignment phase, disconnected from its foundational rep- resentations. This reveals a critical research gap for a more foundational approach that integrates collaborative semantics directly into the tokenization process, enriching representations from the ground up.
3
TOOLWEAVER
3.1 PRELIMINARIES
Current tool-augmented agents often operate by iteratively reasoning and acting. Given user query q and a large tool corpus D = {di..... .. dy) where |D] N. an agent typically follows multi-stage process: (1) planning step (p,). (2) selecting tool (d,). (3) generating its parameters (a,), and (4) observing the execution feedback (f.). This cycle repeats until the task is complete, forming an interaction trajectory Traj [g, (pi, d1, 01 fi)..... (pc, de, Ct2, ft), a). To streamline this process, a promising generative paradigm (Hao et al., 2023] Wang et al., (024b) reframes tool selection as next-token prediction task. This is achieved by mapping each tool d D unique, specially added token in the language model's vocabulary. While simple, this "one-token-per-tool scheme
suffers from the scalability, generalization, and semantic limitations discussed in the introduction.
To overcome these challenges, we propose Weaver. Instead of single token, it represents each tool compositional sequence of discrete codes. As visualized in Figure [Tc). we employ a set of I codebooks, C= [C1,-.. C. where each codebook C₁ contains K learnable code vectors. Each tool then mapped unique sequence of indices, [41, 12; (2....,,'.] ..... This hierarchical structure yields representation capacity of up to KL tools while only requiring the addition of T. x K new tokens to the vocabulary, achieving the logarithmic compression contrasted in Figure Ia).
While this compositional structure is inherently scalable, the key contribution of Tool is its novel structured tokenization process. An integral aspect this process the explicit use of collaborative signals from tool usage data during codebook learning, which ensures the resulting representations are not only semantically coherent but also aligned with their practical, collaborative functions in downstream tasks.
3.2 STRUCTURED TOKENIZATION GUIDED BY COLLABORATIVE SEMANTICS
The core of Woveee is its structured tokenization process (see Figure (c)). which transforms each tool's unstructured documentation into compositional representation. This process is de- signed to embed both semantic and collaborative relationships directly into the code structure. It involves a multi-stage pipeline of initial semantic encoding, collaborative-awarc residual quantiza- tion, and conflict mitigation.
Initial Semantic Representation. Given the textual documentation for each tool d E D (including its name and description), we first leverage powerful pretrained text encoder to generate dense semantic embedding. This initial representation, denoted as ea E DR captures the core functionality of the tool.
ed Text-Fnncnder(Doca))
4

---

Published as a conference paper at ICLR 2026
these embeddings fealdED serve the foundational input for our structured tokenization frame- work.
Collaborative-Aware Residual Quantization. To create a compact and hierarchical code struc- ture. employ RQ-VAE (Lee et al. 2022). multi-level vector quantization approach. This method operates without requiring human-annotated labels. Unlike traditional single-layer vec- tor quantization simple clustering algorithms that offer flat representation, RQ-VAE sequen- tially quantizes residual errors, allowing it to achieve significantly larger expression space with more compact and manageable vocabulary size. As defined in the preliminaries, we use L code- books, {C1, ..., [C1,...,CI] C where each codebook C₁ contains K learnable centroid vectors [ur, Jk= with VLk RD, For efficiency, to D' using a linear projection, yielding =d-
1
first reduce the dimensionality of the initial embeddings ed from D
The quantization process is recursive. For each tool d, the initial residual to its projected embedding, 'a,1 = žd- At each level E (1..... ........ L). we find the closest centroid in codebook C₁ for the current residual rd, and subtract it compute the residual for the next level:
arg min ||ra, - -1, ke ().....,)
(2)
rd1+1 rd, V1,6a,1
where 4, is the discrete code index assigned to tool d level I. The final quantized representation
the sum of the selected codebook vectors: &α = Σ Uh,a..
The standard RQ-VAE is trained to minimize combination of a reconstruction loss and a quantiza-
tion loss:
Lreeom = || 2al1
(4)
b
Lquant
([|sg[ra]) - Vi,,,.13 12 Bllra, sg(vr...,11B)).
where sg[-] is the stop-gradient operator and ( is commitment weight, typically set to 0.25.
To ensure the resulting codes capture not only a tool's intrinsic function but also its extrinsic collab- orative patterns, we guide the quantization process using pre-computed tool-tool similarity matrix A.
This matrix derived from tool co-occurrence matrix C built from the usage trajectories, where each element Cuv counts the total number of times tools u and appear together. The similarity score Aue is then calculated using cosine similarity:
Cuv
Aun
(5)
Vou Cov'
where Cun and C.p represent the total occurrence counts for tools u and c, respectively.
We introduce graph Laplacian regularization term that encourages similar tools to have nearby quantized representations:
Colllab
Σ M.VED
A E 2.113
This term penalizes large distances between the quantized representations of tools that frequently co-occur functionally related. This integration with RQ crucial, its multi-layer, residual nature facilitates a progressive refinement of collaborative semantics: the initial layers capture broad functional similarities, while subsequent layers model finer distinctions the residual information. Combining these objectives, the final training objective for our structured tokenization becomes:
Liokenize =
Ea- + Lquam] + XCcollab.
where is a hyperparameter balancing the reconstruction fidelity with the collaborative structure alignment.
5

---

Published as a conference paper at ICLR 2026
Conflict Mitigation via Uniform Mapping. A practical challenge in any tree-based multi-level quantization is index collision, where multiple distinct tools map to the exact same sequence of code indices [ fz... A naive solution of adding extra, semantically meaningless layer of IDs undesirable, as can disrupt the learned semantic structure. To resolve this while preserving semantic integrity, we enforce uniform mapping constraint the final codebook Ct.
Our objective to ensure that tool representations are distributed as uniformly as possible across the centroids of the final codebook. We formulate this constrained optimization problem, adapting the standard quantization objective for the final level L. For a batch of final-level residuals B,
{ra. debach,, we aim solve:
Taillra - U1,N
(8)
dEBL
subject to:
Br
Vil Σ
VK,
Σ deB
(9)
K
where Tak p(L,, kl),,)) represents the soft assignment probability of tool d's residual to centroid kt The first constraint ensures that each tool's residual is fully assigned across the codebook. The second, more critical constraint, enforces that each centroid in the final codebook is assigned an equal share of tools from the batch, thereby mitigating collisions.
Following Zheng al. (2024), frame this as optimal transport problem where ||a,, vr is the transport cost. This formulation allows us to find an optimal assignment matrix IT that satisfies the uniform distribution constraint. our implementation, we solve this problem efficiently using the Sinkhorn-Knope algorithm (Cuturi 2013). This strategy promotes a unique identifier for every tool without compromising the learned semantic space.
3.3 MULTI-STEP GENERATIVE ALIGNMENT TUNING
The final stage of our framework is integrate these structured codes into the LLM via generative alignment tuning. The code sequence for each tool, e.g., ['a, fd.r... is mapped to a sequence of new, unique tokens (c.g., <T1.1><T2.1>) added the LLM's vocabulary. Let 4 denote this sequence of code-tokens. The corresponding embeddings for these new vocabulary tokens are ran- domly initialized. We then fine-tune the model two stages:
Stage 1: Tool Retrieval Alignment. The model learns to generate the correct tool's code sequence ba from a user query q by fine-tuning on dataset of query-tool pairs.
Lrettieaal = - E( [log P(all))).
(10)
Stage 2: Tool Usage Trajectory Alignment. We further fine-tune the model full interaction trajectories. The model learns to generate sequences reasoning, actions (tool calls, including their code-tokens la and parameters aa), and final answers, with the loss computed only over the assistant's 's tokens.
This progressive tuning aligns the model for both accurate tool selection and effective execution in downstream tasks.
3.4 INFERENCE
To prevent the model from generating invalid tool codes during inference, we employ a constrained beam search, standard technique in similar generative frameworks /Wang et al. 2024b). A pre- computed prefix tree (trie) of all valid tool code sequences (La for all E D) guides the search, ensuring that only valid identifiers are generated by masking the logits of invalid next tokens each step. This constraint is applied only during the tool selection phase, preserving the model's full generative capacity for other tasks.

---

Published as a conference paper at ICLR 2026
Table Tool retrieval evaluation performance on ToolBench. Performance measured by NDCG@K across varying query complexities (I1-13). ToolWeaver consistently outperforms both retrieval-based (BM25, EmbSim, ToolRetriever) and generative (ToolGen) methods. represents the results disclosed in [Wang et al.] (2024b), while the others are the results we re-implemented based on the open-source checkpoints.
Model
NDCG@1
NDCG@3
NDCG@5
NDCG@1
NDCG@3
NDCG@5
NDCG@1
NDCG@3
NDCG@5
BM25*
22.77
22.64
18.29
20.74
22.18
10.00
10.08
12.33
EmbSSi**
54.00
50.82
55.86
40.84
36,67
39.55
18.00
17.77
20.70
ToolRetrievee
72.31
64.54
52.00
39.89
ToolGen"
87.67
83.84
91.54
83.46
86.24
88.84
79.00
79.80
84,79
BM25
26.92
26.13
29.00
20.00
21.92
23.46
10.00
10.08
12.33
EmbSim
50.50
48.15
53.41
46.00
39.58
43.05
18.00
17.77
20.94
ToolRetriever
75.92
76,96
82.31
63,00
66.38
72.72
28,00
39.28
44.54
ToolGen
88.50
88.83
84.00
85.65
80.83
ToolWeaver
91.16
91.14
93.48
89.76
89,70
91.80
$8.00
85,80
90.12
EXPERIMENTS
We conduct extensive experiments evaluate ToolWe on large-scale tool retrieval and end- to-end evaluation, focusing on performance, generalization, and scalability against state-of-the-a methods.
4.1 EXPERIMENTAL SETUP
Dataset. We use the large-scale ToolBench benchmark (Qin et al. 2023). which consists of over 16,000 tool collections comprising 46,985 unique APIs. Although tool collection may contain multiple APIs, for simplicity, we refer each individual API "tool" in this paper.
The dataset's structure allows evaluation across scenarios of increasing complexity, from simple single-tool tasks (II), to multi-tool planning within single category (12), and finally to complex orchestration of tools across different categories (I3) (Qin et al., (023). Furthermore, to rigorously assess generalization, we adopt fine-grained splits: I1 Tool., Cat., and Cat., where "Tool." " and "Cat." denote tools and categories, respectively, that unseen during training. All data for retrieval and agent-tuning experiments are converted from this benchmark, with further details in Appendix A.
Baselines. We compare Weaver against comprehensive set of baselines for both tool retrieval and end-to-end task completion. For retrieval evaluation, we use the classic unsupervised methods BM25 (Robertson & Zaragoza 2009) and Embedding Similarity (EmbSim), alongside the state- of-the-art supervised models ToolRetriever (Qin et al. (2023) and ToolGen (Wang et al.) (002bb. For end-to-end evaluation, we benchmark against strong generative models including GPT-4o-mini ToolLlama- (Qin et al. 2023), and ToolGen (Wang et al. 20245). detailed description of each baseline is provided in Appendix A.2
Metrics. For tool retrieval, we use Normalized Discounted Cumulative Gain (NDCG @ k) (Järvelin Kekäläinen 2002) for (=,,,,,5), which evaluates the ranking quality of retrieved tools by con- sidering both relevance and position. For the agent task, adopt the StableToolBent work (Guo et al. (024) and report two key metrics: Solvable Pass Rate (SoPR), the percentage of tasks successfully completed, and Solvable Win Rate (SoWR), which measures the quality of the final answer against strong reference model.
frame-
Implementation Details. For our main experiments presented the body this paper, we use the pretrained Llama-3-8B the primary foundation model for both Weaver and key generative baselines to ensure a fair comparison. To demonstrate the robustness and generalizability of our approach across different architectures,
provide full set of supplementary results using the Qwen model series (Yang et al.] (2025) in Appendix [B.]] All other architectural choices, training procedures, and hyperparameter settings are detailed in Appendix A.3

---

Published as a conference paper at ICLR 2026
4.2 RESULTS
Table presents a comprehensive comparison of tool retrieval evaluation performance. Across all query complexities (I1-I3), ToolWeaver consistently outperforms all baselines. In the most com- plex 13 scenario, WoolWe achieves an NDCG@ of 88,00, significantly higher than ToolGen (81.00) and all retrieval-based methods. Table 2 details the end-to-end evaluation results. Tool-
Table 2: Comparison of end-to-end evaluation performance on ToolBench, measured by Solvable Pass Rate (SoPR) and Solvable Win Rate (SoWR). The SoWR is calculated against the GPT-4o- mini baseline. GPT-4o-min and ToolLlama-2 are tested in a challenging Retrieval setting (Re.) that requires selecting tools from the full set. In contrast, ToolGen and TooeWeaver generate tool tokens directly, without the need for a retriever. ToolWeaver outperforms other models in diverse scenarios, highlighting its effectiveness in both tool selection and execution.
SoWR
Model
Set.
11
12
13
11-Tool.
11-Cat.
12-Cat.
11
12
13
11-Yool.
I1-Cat.
12-Cat,
GPT-to-mini
52.25
39.38
lama-2
Re.
28.94
24.69
10.93
28.48
36.93
19.09
25.15
30.19
24.59
26.58
27.45
20.16
ToolGen
52.97
45.13
36.34
55.56
45.56
36.20
42.48
37.90
ToolWeaver
53.17
44.03
52.19
54.83
57.41
46.24
40.49
48.11
59.02
36.08
43.14
35.48
Weaver achieves superior performance in most cases, excelling in both task completion (SoPR) and solution quality (SoWR). the challenging retrieval setting, Weaver attains the highest SoPR scores in nearly all scenarios. Its advantages are clear not only in simple (I1) and complex multi-tool tasks (I3), but also in generalizing to both unseen tools (II-Tool) and unseen categories (II-Cat). The substantial lead in the multi-tool 13 scenario (52.19 vs. ToolGen's 36.34) particularly underscores the effectiveness of our collaborative aware design for complex planning. Regarding SoWR against the GPT--4-mini reference, Weaver again demonstrates superior performance in the majority of scenarios. The advantage is particularly pronounced in the most complex 13 tasks, where it achieves win rate of 59.02, substantially outperforming ToolGen (49.18). Full results across all settings, including additional baselines and evaluation domains, are detailed in Appendix B.1
4.3
ABLATION STUDIES AND ANALYSIS
4.3.1 ANALYSIS OF COLLABORATIVE REGULARIZATION WEIGHT
We conducted sensitivity analysis to assess the impact of the collaborative regularization weight, X, tool selection performance. As
Avg. NDCG@1
shown in Figure [ model performance across all NDCG metrics consistently improves increases from 0.01 to 1, peaking at A=1. This trend demonstrates that incorporating collabo- rative signals is crucial for learning semanti- cally rich representation that captures how tools function together. However, when À is in- creased further to 10, performance declines, in- dicating that excessively strong collaborative prior can distort tool representations by sacrific- ing the fidelity of their intrinsic functions. This result empirically validates our central hypoth- esis: optimal performance is achieved by strik- ing a balance between a tool's intrinsic seman- ties and its extrinsic collaborative patterns, con- firming the effectiveness of Weaver' 's design.
Avg. NDCG@3
Aug. NDCG@5
0.01
10
Figure 2: Analysis of the collaborative regulariza- tion weight X. Performance, measured by average NDCG@1 across all 11-13 scenarios, consistently peaks at 1.
4.3.2 COMPONENT ABLATION ANALYSIS
To demonstrate the cumulative impact of our core components, we performed wise ablation. The results Figure reveal a clear hierarchy contributions.
8

---

Published as a conference paper at ICLR 2026
100
120
NDCG
80
100
70
60
21 1 13 Narrerioal
11
13 11
1:
13 33 Trahhhove
1: Namertool
11 Hierandwoo)
13
21 2B 8
B
41 12 33
(a) Retrieval Evaluation (Avg. NDCG@ (1,3,5).
(b) End-to-end Evaluation (SoPR/SoWR).
Figure 4: Comparison of tokenization strategies.
The model without semantic initialization (blue bars), which lacks both of our proposed com- ponents, performs poorly and serves as base- line. The first crucial step is adding seman- tic initialization. This step alone (transitioning from blue pink bars) causes a dramatic per- formance leap of over 20 NDCG points, under- scoring that a meaningful tool representation is the single most critical foundation.
50
00
60
SC0004 Koclaga XB0gge
kookel XD00g0 Nocaag
XDO0g koClaja XD00gE
Figure Cumulative ablation analysis of Teaver'' components on tool selection (NDCG@K). Performance is shown for the base- line (w/o Semantic Initialization), after adding semantic initialization (w/o Collaborative Guid- ance), and for the full model.
Building upon this semantically-awe aware founda- tion, the final step is to incorporate collabora- tive guidance (transitioning from pink to grey bars). This yields further, significant improve- ment whose magnitude scales with task com- plexity. The benefit is modest for simple Il tasks but becomes most pronounced for com- plex, multi-too 13 tasks. This trend provides strong evidence for our thesis: while semantic under- standing is foundational, explicitly encoding collaborative patterns is the key to mastering complex tool orchestration.
4.3.3 COMPARISON OF TOKENIZATION STRATEGIES
To further validate the effectiveness of our collaborative-awar structured tokenization, particu- larly against other methods that attempt to embed structure or semantics into tool representations, compare ToolWeaver against several alternative strategies. These baselines represent different paradigms: Atomic (as in ToolGen) assigns a single unique token per tool, serving as a flat gen- erative baseline; Numerical uses fixed-length numeric strings, providing a minimal-vocabularyy but non-semantic bascline; Hierarchical generates structured code sequences based on clustering, rep- resenting a static, tree-like approach to tokenization; and Semantic leverages human-readable parts of tool names, reflecting a direct, dexicon-based semantic approach. Detailed descriptions of these methods are provided in Appendix B.2
As shown in Figure ToolWeaver consistently outperforms all other tokenization strategies across both tool retrieval and end-to-end evaluation. Notably, while the Hierarchical and Semantic methods attempt to incorporate structure, they struggle to outperform the strong Atomic baseline, particularly in the end-to-end evaluation (SoPR/SoWR). This indicates that simply adding naive structure not sufficient for improving performance.
These results underscore the core advantage Teveee it does not merely rely on pre-existing hierarchies or basic semantic similarity. Instead, it uniquely weaves collaborative signals into structured, semantic representation. The underperformance of other structured methods compared to the Atomic baseline highlights that the quality and type of encoded information critical. Tool- Weaver's 'ss holistic approach creates tool codes that are not only descriptive of a tool's function but also predictive of its role in complex, multi-tool workflows, leading superior performance.

---

Published as a conference paper at ICLR 2026
4.3.4 IMPACT ON GENERAL LANGUAGE CAPABILITIES
A critical concern with generative tool learning that adding new tokens might disrupt the pre- trained linguistic knowledge of the LLM. Methods like ToolGen inject nearly 47,000 new tokens, linearly expanding the vocabulary and potentially skewing the model's internal distribution. con- trast, ToolWeaver employs logarithmic expansion strategy that adds significantly fewer tokens.
To rigorously quamtify this impact, we selected two complementary evaluation protocols. First, we measured Perplexity (PPL) on WikiTextt2 (Merity et al. 2016) to assess how well the model maintains the original probability distribution of natural language. Second, we evaluated Text Sum- marization on CNN/DailyMaii (See et al.] (0117) and XSum (Narayan et al., (2018) to verify the model's ability to generate coherent and high-quality text in zero-shot settings.
Table Impact of tool vocabulary expansion on general language capabilities. We report Perplexity (lower is better) and Summarization BERTScore FI (higher is better). ToolWeaver preserves the base model's capabilities significantly better than ToolGen.
Language Modeling (PPL)
Text Summarization (BERTScore FI)
Model
Wiki'Text-2 (1)
CNN/MM (t)
XSum (t)
Avg. Drop
Llama-3-8B (Base)
6.34
85,35
85.05
TholGen
104.54
82.93
82.53
2.47
ToolWeaver
25.36
85.07
84.18
0.57
Table 3 summarizes the results. The linear vocabulary expansion in ToolGen leads to catastrophic degradation. Specifically, its PPL on WikiText-2 increases drastically 104.54, which is approx- imately 16 times that of the base model. Furthermore, its generation quality drops notably on the abstractive XSum benchmark. In contrast, ToolWeaver demonstrates superior robustness. The PPL remains much lower at 25.36, and the summarization performance on CNNi/aillMMai is nearly identical the base model, achieving BERTScore of 85.07 compared the original 85.35.
These findings indicate that our structured tokenization preserves the linguistic core of the LLM far better than assigning isolated atomic tokens vast tool library. We provide additional eval- uations on general understanding benchmarks, such as MMLU, along with detailed experimental configurations in Appendix B.4]
CONCLUSION
In this paper, we introduced Toaver framework designed to address the critical scalabil- ity, generalization, and semantic challenges of the "one-token-per-ttee paradigm. ToolWeaver represents each tool as a hierarchical sequence of discrete codes, making vocabulary expansion logarithmic to the number of tools. Through a novel, collaborative-aware tokenization process, our framework weaves tool's intrinsic semantics with its extrinsic co-usage patterns, encouraging functionally related tools to share codes. This allows the model to learn robust collaborative pat- terns from the dense co-occurrence of shared codes, rather than the sparse co-occurrence of isolated tool IDs. Extensive experiments the ToolBench benchmark demonstrate that Too/ee signif- icantly outperforms state-of-ther methods in complex task completion and generalization, while better preserving the model's general language capabilities. Our work establishes a more scalable, generalizable, and semantically-awaan foundation for building advanced tool-using agents, with fu- ture directions including reinforcement learning to autonomously discover collaborative patterns.
ACKNOWLEDGMENTS
This work is sponsored by Beijing Natural Science Foundation (L.252033) and National Natural Science Foundation of China (62236010, 62141608, 62206291, 62372454).
10

---

Published as a conference paper at ICLR 2026
ETHICS STATEMENT
Our work aims to advance the capabilities of tool-using Al agents. We acknowledge the potential for misuse, as more capable agents could be directed to interact with malicious APIs. Furthermore, the ToolBench dataset, while based on real-world tools, was not audited for biases or privacy risks. We present this as foundational research and emphasize that any real-world deployment requires robust safety protocols and human oversight.
REPRODUCIBILITY STATEMENT
To ensure reproducibility, our complete source code provided in the supplementary material. All experimental configurations, including dataset processing (Appendix [A.]), baseline details (Ap- pendix A.2). and implementation hyperparameters (Appendix (A.3), are thoroughly documented. Our experiments utilize the public ToolBench dataset and the StalleToolBench evaluation frame- work.
REFERENCES
Yonatan Bisk, Rowan Zellers, Ronan Le Bras, Jianfeng Gao, and Yejin Choi. PIQA: Reasoning about physical commonsense natural language. In Proc. of the AAAI Conf. on Artificial Intelli- gence (AAAI), pp. 7432-7439. AAAI Press, 2020. doi: 10.1699/AAALV33115.....
Tom B. Brown, Benjamin Mann, Nick Ryder. Melanie Subbiah, Jared Kaplan, Prafulla Dhari- wal, Arvind Neclakantan, Pranav Shyam, Girish Sastry, Amanda Askell, Sandhini Agarwal, Ariel Herbert- Voss, Gretchen Krueger, Tom Henighan, Rewon Child, Aditya Ramesh, Daniel M. Ziegler, Jeffrey Wu, Clemens Winter, Christopher Hesse, Mark Chen, Eric Sigler, Mateusz Litwin, Scott Gray, Benjamin Chess, Jack Clark, Christopher Berner, Sam McCandlish, Alec Radford, Ilya Sutskever, and Dario Amodei. Language models are few-shot learners, 2020.
Sijia Chen, Yibo Wang, Yi-Feng Wu, Qing-Guo Chen, Zhao Xu, Weihua Luo, Kaifu Zhang, and Lijun Zhang. Advancing augl-nueeetted large language models: Integrating insights from errors in inference trees, 2025.
Yanfei Chen, Jinsung Yoon, Devendra Singh Sachan, Qingze Wang, Vincent Cohen-Addad, Mo- hammadhossein Bateni, Chen- Yu Lee, and Tomas Pfister. Re-Invoke: Tool invocation rewriting zero-shot tool retrieval, 2024.
Xize Cheng, Dongjie Fu, Xiaoda Yang, Minghui Fang, Ruofan Hu, Jingyu Lu, Bai Jionghao, Zehan Wang, Shengpeng Ji, Rongjie Huang, et al. Omnichat: Enhancing spoken dialogue systems with scalable synthetic data for diverse scenarios. arXiv preprint 2501::::00.0110000 2025.
Christopher Clark, Kenton Lee, Ming- Wei Chang, Tom Kwiatkowski, Michael Collins, and Kristina Toutanova. BoolQ: Exploring the surprising diffieulty of natural yes/no questions. In Jill Burstein, Christy Doran, and Thamar Solorio (eds.), Proc. of the Conf. of the North American Chapter of the Association for Computational Linguistics (NAACL-HLT)) pp. 2924-2936. Association for Computational Linguistics, 2019, doi: N..18653/V1/N11-111
Marco Cuturi. Sinkhorn distances: Lightspeed computation of optimal transport. Advances in Neural Information Processing Systems, 26, 2013.
Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Abhishek Kadian, Ahmad Al-Dahle, Aiesha Letman, Akhil Mathur, Alan Schelten, Amy Yang, Angela Fan, et al. The Llama 3 herd of models, 2024.
Leo Gao, Jonathan Tow, Baber Abbasi, Stella Biderman, Sid Black, Anthony DiPofi, Charles Fos- ter, Laurence Golding, Jeffrey Hsu, Alain Le Noac'h, Haonan Li, Kyle McDonell, Niklas Muen- nighoff, Chris Ociepa, Jason Phang, Laria Reynolds, Hailey Schoelkopf. Aviya Skowron, Lintang Sutawika, Eric Tang, Anish Thite, Ben Wang, Kevin Wang, and Andy Zou. The language model evaluation harness, 07 2024a. URL http:/tttss//aanc...rr///rr////s

---

Published as a conference paper at ICLR 2026
Shen Gao, Zhengliang Shi, Minghang Zhu, Bowen Fang, Xin Xin, Pengjie Ren, Zhumin Chen, Jun Ma, and Zhaochun Ren. Confucius: Iterative tool learning from introspection feedback by casy-to-diffieult curriculum. In Proceedings of the AAAI conference artificial intelligence, volume 38, pp. 18030-18038, 2024b.
Yunfan Gao, Yun Xiong, Xinyu Gao, Kangxiang Jia, Jinliu Pan, Yuxi Bi, Yi Dai, Jiawei Sun, Meng Wang, and Haofen Wang. Retrieval-augmentee generation for large language models: A survey, 2024c.
Zhong Guan, Likang Wu, Hongke Zhao, Ming He, and Jianpin Fan. Enhancing collaborative mantics of language model-driven recommendations via graph-aware learning, 2024.
Zhicheng Guo, Sijie Cheng, Hao Wang, Shihao Liang, Yujia Qin, Peng Li, Zhiyuan Liu, Maosong Sun, and Yang Liu. StablcToolBenchh Towards stable large-scale benchmarking on tool learning of large language models, 2024.
Shibo Hao, Tianyang Liu, Zhen Wang, and Zhiting Hu. Toolkengpt: Augmenting frozen language models with massive tools via tool embeddings. Advances in Neural Information Processing Systems, 36:45870-44555 2023.
Dan Hendrycks, Collin Burns, Steven Basart, Andy Zou, Mantas Mazeika, Dawn Song, and Jacob Steinhardt. Measuring massive multitask language understanding, In Proc. of the Int. Conf. on Learning Representations (ICLR), 2021. URL https: httts::/ net forum?id-
d7KB mmmm@
Kalervo Järvelin and Jaana Kekäläinen. Cumulated gain-based evaluation of IR techniques, ACM Transactions on Information Systems (TOIS), (0(4)):2224466 2002.
Vladimir Karpukhin, Barlas Oguz, Sewon Min, Patrick Lewis, Ledell Wu, Sergey Edunov, Danqi Chen, and Wen tau Yih. Dense passage retrieval for open-domain question answering, 2020.
Doyup Lee, Chiheon Kim, Saehoon Kim, Minsu Cho, and Wook-Shin Han. Autoregressive image generation using residual quantization. In Proc. of the IEEE/CVF Conf. Computer Vision and Pattern Recognition (CVPR), pp. 11523-15332, 2022.
Minghao Li, Yingxiu Zhao, Bowen Yu, Feifan Song, Hangyu Li, Haiyang Yu, Zhoujun Li, Fei Huang, and Yongbin Li. API-Bank: A comprehensive benchmark for tool-augmented LLMs, 2023.
Jianghao Lin, Xinyi Dai, Yunjia Xi, Weiwen Liu, Bo Chen, Hao Zhang, Yong Liu, Chuhan Wu, Xiangyang Li, Chenxu Zhu, et How can recommender systems benefit from large language models: A survey, ACM Transactions Information Systems, 43(2):1-47, 2025.
Qijiong Liu, Jieming Zhu, Yanting Yang, Quanyu Dai, Zhaocheng Du Xiao-Ming Wu, Zhou Zhao, Rui Zhang, and Zhenhua Dong. Multimodal pretraining, adaptation, and generation for recom- mendation: A survey, 2024.
Yanming Liu, Xinyue Peng, Jiannan Cao, Shi Bo, Yuwei Zhang, Xuhong Zhang, Sheng Cheng, Xun Wang, Jianwei Yin, and Tianyu Du. Tool-Planner: Task planning with clusters across multiple tools, 2025.
Stephen Merity, Caiming Xiong, James Bradbury, and Richard Socher. Pointer sentinel mixture models, 2016.
Grégoire Mialon, Roberto Dessi, Maria Lomeli, Christoforos Nalmpantis, Ram Pasunuru, Roberta Raileanu, Baptiste Rozière, Timo Schick, Jane Dwivedi- Yu, Asli Celikyilmaz, Edouard Grave, Yann LeCun, and Thomas Scialom. Augmented language models: a survey, 2023.
Todor Mihaylov, Peter Clark, Tushar Khot, and Ashish Sabharwal. Can suit of armor conduct electricity? a new dataset for open book question answering. In Proc. of the Conf. on Empirical Methods in Natural Language Processing (EMNLP), 2018.
12

---

Published as a conference paper at ICLR 2026
Reiichiro Nakano, Jacob Hilton, Suchir Balaji, Jeff Wu, Long Ouyang, Christina Kim, Christopher Hesse, Shantanu Jain, Vineet Kosaraju, William Saunders, Xu Jiang, Karl Cobbe, Tyna Eloun- dou, Gretchen Krueger, Kevin Button, Matthew Knight, Benjamin Chess, and John Schulman. WebGPT: Browser-assisted question-answering with human feedhack, 2022.
Shashi Narayan, Shay B. Cohen, and Mirella Lapata. Don't give me the details, just the summary! topic-aware convolutional neural networks for extreme summarization. ArXiv, abs/ 10//1808.000 808.08745, 2018.
Bhargavi Paranjape, Scott Lundberg, Sameer Singh, Hannanch Hajishirzi, Luke Zettlemoyer, and Marco Tulio Ribeiro. ART: Automatic multi-step reasoning and tool-use for large language mod- els, 2023.
Shishir G. Patil, Tianjun Zhang, Xin Wang, and Joseph E. Gonzalez. Gorilla: Large language model connected with massive APIs, 2023.
Yujia Qin, Shihao Liang, Yining Ye, Kunlun Zhu, Lan Yan, Yaxi Lu, Yankai Lin, Xin Cong, Xiangru Tang, Bill Qian, et al. Toolllm: Facilitating large language models to master 16000+ real-world APIs, 2023.
Yujia Qin, Shengding Hu, Yankai Lin, Weize Chen, Ning Ding, Ganqu Cui, Zheni Zeng, Yufei Huang. Chaojun Xiao, Chi Han, Yi Ren Fung, Yusheng Su, Huadong Wang, Cheng Qian, Runchu Tian, Kunlun Zhu, Shihao Liang, Xingyu Shen, Bokai Xu, Zhen Zhang, Yining Ye, Bowen Li, Ziwei Tang. Jing Yi, Yuzhang Zhu, Zhenning Dai, Lan Yan, Xin Cong, Yaxi Lu, Weilin Zhao, Yuxiang Huang. Junxi Yan, Xu Han, Xian Sun, Dahai Li, Jason Phang, Cheng Yang, Tongshuang Wu, Heng Ji, Zhiyuan Liu, and Maosong Sun. Tool learning with foundation models, 2024.
Stephen Robertson and Hugo Zaragoza. The probabilistic relevance framework: BM25 and beyond. Foundations and Trends in Information Retrieval, 3(4):333-389, 2009.
Keisuke Sakaguchi, Ronan Le Bras, Chandra Bhagavatula, and Yejin Choi. WinoGrande: An adver- sarial winograd schema challenge at scale. In Proc. of the AAAI Conf. on Artificial Intelligence (AAAI), 2020.
Timo Schick, Jane Dwivedi- Yu, Roberto Dessi, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. Toolformer: Language models can teach themselves to use tools, 2023.
Abigail See, Peter J. Liu, and Christopher D. Manning. Get to the point: Summarization with pointer-generator networks. In Proceedings of the 55th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pp. 1073-1083, Vancouver, Canada, July 2017. Association for Computational Linguistics. doi: 10. 10.18663/11/11--1099 URL https: 7/ www..w. ac web. www.or//aaa wwwp//aahologg////aa/.o.
Teng Shi, Jun Xu, Xiao Zhang, Xiaoxue Zang, Kai Zheng, Yang Song, and Han Li. Retrieval augmented generation with collaborative filtering for personalized text generation. In Proc. of the 48th Int. ACM SIGIR Conf. on Research and Development in Information Retrieval (SIGIR), pp. 1294-1304, 2025.
Yunyue Su, Jingshuai Zhang, Bowen Fang, Wen Ye, Jinghao Zhang, Bowen Song, Weiqiang Wang, Qiang Liu, and Liang Wang. Toolscaler: Scalable generative tool calling via structure-aware semantic tokenization. In Findings of the Association for Computational Linguistics: EMNLP 2025, pp. 556-578, 2025.
Liyuan Wang, Xingxing Zhang, Hang Su, and Jun Zhu. A comprehensive survey of continual learning: Theory, method and application. IEEE Transactions on Pattern Analysis and Machine Intelligence, 46(8):5362-55) 5383, 2024a.
Renxi Wang, Xudong Han, Lei Ji, Shu Wang, Timothy Baldwin, and Haonan Li. Toolgen: Unified tool retrieval and calling via generation, 2024b.
Zihan Wang, Jinghao Lin, Xiaocui Yang. Yongkang Liu, Shi Feng, Daling Wang, and Yifei Zhang. Enhancing LLM- based recommendation through semantic-aligned collaborative knowl- edge, 2025.
13

---

Published as a conference paper at ICLR 2026
Qinzhuo Wu, Wei Liu, Jian Luan, and Bin Wang. ToolPlanner: A tool augmented LLM for multi granularity instructions with path planning and feedback, 2024.
Lee Xiong, Chenyan Xiong, Ye Li, Kwok-Fung Tang, Jialin Liu, Paul Bennett, Junaid Ahmed, and Arnold Overwijk. Approximate nearest neighbor negative contrastive learning for dense text retrieval, 2020.
Qiancheng Xu, Yongqi Li, Heming Xia, and Wenjie Li. Enhancing tool retrieval with iterative feedback from large language models, 2024.
An Yang, Baosong Yang. Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chengyuan Li, Dayiheng Liu, Fei Huang, Haoran Wei, Huan Lin, Jian Yang, Jianhong Tu, Jianwei Zhang. Jianxin Yang. Jiaxi Yang. Jingren Zhou, Junyang Lin, Kai Dang, Keming Lu, Keqin Bao, Kexin Yang, Le Yu, Mei Li, Mingfeng Xue, Pei Zhang, Qin Zhu, Rui Men, Runji Lin, Tianhao Li, Tianyi Tang, Tingyu Xia, Xingzhang Ren, Xuancheng Ren, Yang Fan, Yang Su, Yichang Zhang, Yu Wan, Yuqiong Liu, Zeyu Cui, Zhenru Zhang, and Zihan Qiu. Qwen2.5 technical report, 2025.
Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. React: Synergizing reasoning and acting in language models. In Proc. of the Int. Conf. on Learn- ing Representations (ICLR), 2023.
Rowan Zellers, Ari Holtzman, Yonatan Bisk, Ali Farhadi, and Yejin Choi. HellaSwag: Can a machine really finish your sentence? In Proc. of the Annual Meeting of the Association for Computational Linguistics (ACL), 2019.
Wayne Xin Zhao, Kun Zhou, Junyi Li, Tianyi Tang, Xiaolei Wang, Yupeng Hou, Yingqian Min, Beichen Zhang, Junjie Zhang, Zican Dong, Yifan Du, Chen Yang, Yushuo Chen, Zhipeng Chen, Jinhao Jiang, Ruiyang Ren, Yifan Li, Xinyu Tang, Zikang Liu, Peiyu Liu, Jian Yun Nie, and Ji-Rong Wen. survey of large language models, 2025.
Bowen Zheng, Yupeng Hou, Hongyu Lu, Yu Chen, Wayne Xin Zhao, Ming Chen, and Ji- Ji-Rong Wen. Adapting large language models by integrating collaborative semantics for recommendation. In Proc. of the IEEE 40th Int. Conf. on Data Engineering (ICDE), pp. 1435- 1448. IEEE, 2024.
Minghang Zhu, Zhengliang Shi, Zhiwei Xu, Shiguang Wu, Lingjie Wang, Pengjie Ren, Zhaochun Ren, and Zhumin Chen. Bridging the capability gap: Joint alignment tuning for harmonizing LLM-based multi-agent systems. In Christos Christodoullpoulls, Tanmoy Chakraborty, Car- olyn Rose, and Violet Peng (eds.), Findings of the Association for Computational Linguistics: EMNLP 2025, pp. 21846-20 21861, Suzhou, China, November 2025. Association for Computational Linguistics. doi: 10. 118855/31122222 hww.22..n..........m.. org/
URL https: https://aclaatthooog..
1192/
Yuchen Zhuang, Xiang Chen, Tong Yu, Saayan Mitra, Victor Bursztyn, Ryan A. Rossi, Somdeb Sarkhel, and Chao Zhang. Too:Chain#; Efficient action space navigation in large language models with A search, 2023.
14

---

Published as a conference paper at ICLR 2026
APPENDIX
Experimental Setup Details
15
Dataset Details
15
Baseline Details
16
A.3
Implementation and Training Details
17
A.4 4
Evaluation Setting Details
17
B
Supplementary Experimental Results
18
B.
Extended Results on Main Experiments
18
B.2
Detailed Comparison of Tokenization Strategies
................................
18
B.3
Full Results on Qwen Models
20
Extended Analysis on General Language Capabilities
................................
20
B.5
Codebook Hyperparameter Sensitivity Analysis
................................
22
B.6
Sinkhorn-Knopp Efficiency and Stability Analysis
B.7
Inference Latency and Memory Analysis
25
B.8
Failure Analysis
26
Qualitative Analysis and Examples
26
Case Study: Analysis of Learned Tool Codes and Multi- Tool Coordination
26
C.2 Examples for Tools and APIs
28
Examples of Alignment Tuning Data
28
Real End-to-End End Inference Trajectory
D The Usage of LLMS
29
A EXPERIMENTAL SETUP DETAILS
A.1 DATASET DETAILS
Our experiments conducted the ToolBench benchmark (Qin al. 2023),
large-scale and
comprehensive dataset designed for evaluating tool-using agents. ToolBench is constructed upon vast collection of real-world, high-quality REST APIs sourced from RapidAPI, major API hub. This grounding in woaldworld services ensures that the tasks and tools reflect practical challenges faced by Al agents.
Overall Statistics. The full dataset encompasses 46,985 tools (APIs) organized into 129 tool col- lections. As mentioned in the main text, each tool is annotated with rich metadata, including human-assigned functional category. There are 49 distinct functional categories in total (e.g., Fi- nance, Travel, Sports, etc.), which provide semantic grouping for the tools.
Evaluation Scenarios. ToolBench defines standardized test comprising 641 queries, which are categorized into three levels of increasing difficulty based on the complexity of the required tool interactions. These scenarios are:
15

---

Published as a conference paper at ICLR 2026
Instruction 1 (II): Single-Tool Usage. These tasks require the agent to select and correctly use a single tool to answer the user's query. This scenario primarily tests the agent's 's ability for accurate tool retrieval and basic API execution.
Instruction (I2): Intra-Catega Category Multi-Tool Usage. These tasks involve solving
problem that requires composing a sequence of tools. Critically, all necessary tools belong to the same functional category. This tests the agent's ability to reason and plan within coherent semantic domain.
Instruction (I3): Intra-Collection Multi- Muoti-Tool Usage. This is the most challenging scenario. Tasks require the agent to orchestrate multiple tools that may come from dif- ferent functional categories but are part of the same broader tool collection (e.g., a "Trip Planning" collection might contain tools from "Flights", "Hotels", and "Maps" categories). This evaluates the agent's advanced planning and generalization capabilities across diverse tool functions.
Data Statistics for Alignment Tuning Stages. Our training methodology is structured into two main fine-tume tonint stages. We utilize the official splits and data provided by the ToolBench bench- mark (Qin al. 2023), processing them to fit our generative framework. The statisties for each stage are detailed below:
.
Tool Retrieval Alignment. The initial fine-tuning stage is designed to teach the model the crucial mapping between a user's intent and the appropriate tool. To achieve this, we fine-tune the model Query-Tool pairs extracted from ToolBench. In this super- vised task, the input is a natural language query, and the target output is the corresponding tool's structured semantic code sequence. Following the data processing approach of prior work (Wang et al. 2024b). we utilize a comprehensive set of 489,702 query-tool pairs, aggregated across the 11, 12. and 13 scenarios, to train robust retrieval capability.
Stage I:
Stage 2: Tool Usage Trajectory Alignment. After the model has learned to retrieve tools, the second stage trains it to function as a complete, autonomous agent. This is accom- plished by fine-tuning on full execution trajectories. Each trajectory provides complete, multi-step example of how to reason, plan, generate arguments, and invoke tools to solve a complex user query. We adapt the original ToolBench trajectories by replacing all tool names with our learned semantic codes. For this final and most complex training step, we use a total of 183,336 trajectories.
A.2 BASELINE DETAILS
In our experiments, we compare ToolWeaver against several representative retrieval and tool-use models. These baselines are chosen to cover a wide range of approaches, from classic unsupervised methods state-of-the-art generative agents.
BM25 (Robertson Zaragoza 2009 : An unsupervised, classical retrieval model that ranks documents based on query relevance, using normalized term frequency and docu- ment length. It serves as a strong lexical baseline.
Embedding Similarity (EmbSim): An unsupervised semantic retrieval method. We use OpenAl's powerful text -embediin (aongg3-aarge model to generate embeddings for both queries and tool documents, and rank tools based on the cosine similarity of their embeddings.
ToolRetriever (Qin et al. 2023): A supervised, BERT-based dense retriever specifically designed for tool retrieval. is trained using contrastive learning to distinguish between relevant and irrelevant tools by maximizing the similarity between queries and their corre- sponding ground-truth tools.
ToolGen WWang et al. 2024b); A state-of-the art generative model that unifies tool retrieval and calling. It represents each tool as a unique atomic token and is fine-tuned directly generate the tool's token and its arguments in response to a query.
ToolLlama-2 (Qin et al. 2023): version of the Llama-2 model fine-tuned for tool use. Unlike generative models like ToolGen and Tool it relies external retriever to
16

---

Published as a conference paper at ICLR 2026
first select set of candidate tools, which are then provided in the prompt context for the model to perform reasoning and task completion.
GPT-4o-mini: highly capable and efficient model from OpenAI. We use strong baseline for end-to-end task completion. Following the StableToollBent evaluation pro- tocol (Guo et al., (024), also serves as the reference model for calculating the Solvable Win Rate (SoWR) metric.
Re-Invoke (Chen et al. 2024): An advanced unsupervised retrieval method that enriches tool documents by generating synthetic queries. During inference, it uses an LLM ama- lyze user intent and employs a multi-view similarity ranking strategy to identify the most relevant tools.
IterFeedback (Xu 2024): A retrieval framework that enhances BERT-based re- triever by incorporating iterative feedback from large language model. The LLM is prompted analyze initial retrieval results and provide feedback refine the search, im- proving retrieval accuracy over multiple steps.
A.3 IMPLEMENTATION AND TRAINING DETAILS
This appendix provides a detailed description of the implementation specifies for the models and experiments presented in the main paper, ensuring full reproducibility.
The structured tokenization process begins with generating initial dense semantic embeddings for each tool. We process the textual documentation of each tool (including its name and description) model from the
using the a all-mpnet-ball a 168-ddimeniiona embedding. The core of our structured tokenization is a collaborative- residual quantization process. This process employs a multi-level scheme with L = 2 codebooks, Cj and C2, each containing K 1024 learnable vectors. This compositional structure represents the entire tool library with only x 1024 = 2048 new tokens added to the LLM's s vocabulary. The initial 768-dimensne dimensionnl embeddings first projected into a 64-dimensional space (D' 64) using a multi-layer perceptron (MLP) with sequential hidden layer dimensions of 1024, 512, 256, and 128.
library, which produces
The codebooks trained using the AdamW optimizer with a learning rate of 1e-5 and batch size of 5096, over 50 warmup epochs with no weight decay. For the main results, the collaborative regularization weight, X, was 1.0. We initialize the codebook centroids using k-means with a maximum of 100 iterations. For conflict mitigation, the Sinkhorn-Knopp algorithm is run for 50 iterations.
The integration of these learned codes into the LLM is achieved through a two-stage generative alignment process. In Stage the model is fine-tuned for epochs on query-tool pairs for retrieval alignment. In Stage 2, it is fine-tuned for an additional 2 epochs on full interaction trajectories to learn complex planning. For both stages, we employ cosine learning rate scheduler with 3% warmup ratio and a peak learning rate of 4 x 10-6, The input context length is truncated to 6,144 tokens. All experiments were conducted on NVIDIA A100 GPUs, and we leveraged the DeepSpeed ZeRO-3 optimization suite and FlashAttention-2 to enhance training efficiency.
A.4 EVALUATION SETTING DETAILS
Our experiments adopt two distinct retrieval settings from prior work (Wang et al. 2024b): In- Domain and Multi-Domain. The In-Domain setting restricts the search space to a fre-filtered tool category, while the more challenging Multi-Domain setting requires the model to select from the entire global corpus of nearly 47, ,,000 APIS for any given query. For primary experiments presented in the main body of this paper, we focus on the Multi-Domain setting as it provides a more realistic and rigorous test of model's ability to handle sure--ccale retrieval and disambiguate tool functions. A complete set of results for both settings, including the In- Domain evaluation, is provided for reference in Appendix B.1
17

---

Published as a conference paper at ICLR 2026
Table Tool retrieval evaluation across settings: In-domain and Multi-domain. * represents the results disclosed in Wang et al. (2024b). while the others are the results we re-implemented based on the open- open-source source checkpoints.
Model
NDOG@1
NDCG@3
NDCG@s
NDOG@1
NDCG@3
NDUG@s
NDCG@1
NDCG@3
NDCG@S
In-domain
BM25*
29.46
31.12
33.27
24.13
25.29
27.65
32.00
25,88
29.78
EmbSim*
53.00
Invoke*
69.47
61.10
$4.56
53.79
59.65
59.55
90.70
90.95
92.47
89.01
85.46
87.10
91.74
87.94
90.20
ToolRetrieve
80.50
79.55
71.18
64.81
70.35
70.00
60.44
64.70
ToolGen"
89.17
90.85
92.67
91
88,79
91.13
87.00
85.59
90.16
EmbSim
61.00
57.78
62.31
$4.00
45,31
49.54
$4.00
46.56
$2.91
ToolRetriover
83.50
66
72.00
70.00
70.01
ToolGen
91.00
92.15
94.11
87.50
88.52
90.81
87.00
85.35
90.08
TaplWeaver
93.76
94.80
95.69
91,91
93.07
95.63
$6.00
86.13
90.39
Mulli-domain
BM25*
22.77
22.64
25.61
18.29
20.74
22.18
10.00
10.08
12.33
EoiSSim
54.00
50.82
55.86
40.84
36,67
18.00
17.77
20.70
ToolRetriever*
72.31
70.30
74.99
64.54
$7.91
63.61
$2.00
39.89
42.92
ToolGen"
87.67
83.46
86.24
88.84
79.00
BM25
26.92
26.13
29.00
20.00
21.92
23.46
10.00
10.08
12.33
EmbSim
50.50
48.15
53.41
46.00
39.58
43.05
18.00
17.77
20,94
ToolReiriever
75.92
76.96
82.31
63,00
66.38
72.72
28.00
39.28
44.54
ToolGen
88.50
88.83
91.65
84.00
85.65
89.02
$1.00
80.83
85.83
ToolWeaver
91.16
89.76
$8.00
B SUPPLEMENTARY EXPERIMENTAL RESULTS
B. EXTENDED RESULTS ON MAIN EXPERIMENTS
This section provides more detailed and comprehensive view of our experimental results, supple- menting the key findings presented in the main paper. While the main text focused the most challenging Multi-Domain setting to rigorously evaluate ToolWeaver's 's performance realistic, large-scale environment, we present results for both In-Domain and Multi-Domain settings here for completeness and to facilitate a thorough comparison with prior work.
Tables offers complete breakdown of the tool retrieval evaluation. We include results reported by the original authors of baseline methods (*) alongside our own reproductions. The strong align- ment between our re-implemented results and those originally published for models like ToolGen validates the fairness and correctness of our experimental setup. Even in the In-Domain setting, where the search space is constrained, TovlWeaver demonstrates top-tier performance. larly noteworthy that Woaver, as single end endtt-ennd model, outperforms complex, multi-stage retrieval systems like IterFeedback in most scenarios, highlighting the efficiency of our generative approach.
particu-
In Ta we expand on the end-to-end task completion evaluation. For full transparency, this table includes results from prior work (*) alongside our own. It is important to note potential differences evaluation protocols. For example, some prior results were obtained using GPT-3.5 as the core agent and evaluator. Considering that GPT-3.5 is no longer state-of- the-art model and its usage be costly, we chose to standardize our evaluation using the more recent and capable GPT-4o-mini as both strong baseline and, for SoWR, the reference judge. This ensures consistent and modern benchmark for all models we tested. Despite these variations, Teaver consistently demonstrates superior highly competitive performance. Its significant lead in complex multi-step tasks (I3) and generalization scenarios remains evident, underscoring the benefits of its collaborative-awar tokenization for robust task planning and execution. We also include the SoWR results for GPT- 4o-mini in this table for completeness; however, similar to observations in other studies, we noted tendency for the model to favor own solutions, which why we focused on comparing the fine-tuned models in the main text to ensure fair assessment.
B.2 DETAILED COMPARISON OF TOKENIZATION STRATEGIES
To provide a comprehensive evaluation of our tokenization strategy, we implemented and compared it against several representative baseline methods. This section describes these alternatives. For all
18

---

Published as a conference paper at ICLR 2026
Table 5: Tool calling evaluation performance on unseen instructions and unseen tools under two settings. Bold values denote the highest performance, considering only the results reproduced in our experimental setting.
SoPR
Model
Setting
11
12
13
11-Tool.
I1-Cat.
12-Cat.
11
12
13
11-Tool.
I1-Cat.
12-Cat.
GPT-3.5*
Retrieval
51.43
41.19
34.43
57.59
53.05
46.51
53.37
53.77
37.70
46.20
54.25
54.81
ToolL
Retrieval
56.13
49.21
34.70
50.92
53.77
21.31
ToolLlama*
Retrieval
54,60
49.96
51.37
57.70
61,76
45.43
49.08
61.32
31.15
48.73
50.98
44.35
ToolGen
GPT-4o-mini
Retrieval
52.25
40.41
24.86
53.16
50.11
39.38
47.24
52.83
44.26
49.37
50.33
42.74
Toall lama-2
Retrieval
28.94
24.69
10.93
28.48
36.93
19.09
25.15
30.19
24.59
26.58
27.45
20.16
ToolGen
52.97
45.13
36.34
45.36
55.56
45.56
36.20
42.45
49.18
32.91
42.48
37.90
ToolWaaver
83.17
44.03
52.19
54,85
57.41
46.24
40.49
48.11
59.02
36.08
43.14
35.48
methods, we follow the same two-stage generative alignment tuning process described in Section 3.3 ensure fair comparison of the representation strategies themselves.
The detailed performance results for tool retrieval and end-to-end task completion are presented in Table and Table[7 respectively. These tables provide the underlying data for the summary chart in Figure of the main paper.
Table 6: Retrieval performance (NDCG@K) of different tokenization methods. Tooleeaver's ap- proach of integrating collaborative semantics into a structured representation yields the best perfor- mance, especially in complex multi-tool scenarios (12, 13).
Tokenization NDCG@1
I1
NDCG@3
NDCG@5
NDCG@1
NDCG@3
NDCG@5 5
NDCG@1
NDCG@3
NDCG@5
Numerical
83.61
76.93
77.02
71.88
79.45
Hicrarchical
86.72
85.93
89.14
77.50
78.82
83.11
78.21
80.56
86.73
Semantic
89.13
90.82
92.15
84.01
83.15
86.99
Atomic
87.67
88.84
91.54
83.46
86.24
88.84
79.00
79.80
84,79
Tool 91.16
91.14
89.76
91.80
88.00
90.12
Table End-to-end task completion performance (SoPR/SoWR) for different tokenization methods. All methods shown generate tool tokens directly, without the need for a retriever. The superior retrieval accuracy of Weaver translates directly into higher task success rates.
SoPR I1-Tool.
SoWR 11-Tool.
Tokenization
11
12
I1-Cat.
12-Cat.
I1
12
13
I1-Cat.
12-Cat.
Numerical
21.98
9.12
11.20
20.68
26. 14
17.20
16.56
16.04
16.39
20.89
23.53
14.52
Hicrarchical
39.16
20.28
17.49
36,29
31.81
14.92
29.45
28.30
26.23
29.11
24.83
14.52
Semantic
50.20
28.91
16.39
33.02
51.42
27.02
39.26
29.24
32.79
29.11
43.79
22.58
Atomic
52.97
45.13
36.34
45.36
55.56
45.56
36.20
42.45
49.18
32.91
42.48
37.90
ToolWeaver
53.17
44.03
52.19
54.85
57.41
46.24
40.49
48.11
59.02
36.08
43.14
35.48
Atomic Tokenization. This is widely-used baseline in generative tool-use models (Wang et al, 2024b). Each tool represented by single, unique special token. Specifically, the API function "compress" from the RESTful API "IMAGON" is tokenized into a single composite token like <<IMAGON& compress>>> These tokens added the LLM's vocabulary. While simple, this approach suffers from linear growth in vocabulary size and fails to capture any semantic or collaborative relationships between tools, as their representations are learned independently. The results for this bascline are adopted from our ToolGen implementation.
Numerical Tokenization. This serves as a simple, non con-semantic baseline. Each tool is mapped unique numeric string of fixed length. For library of 47,000 tools, a five-digit string is used. For example, the 3rd tool in the corpus is represented as 0 0 0 0 3. This method creates a very small vocabulary overhead (only 10 digit tokens) but provides no semantic or structural priors the model, forcing it to learn tool meanings from scratch.
Hierarchical Tokenization. This method adopts the hierarchical coding scheme from prior work Wang al. 2024b). Each tool is represented by path in pre-defined hierarchical structure,
19

---

Published as a conference paper at ICLR 2026
resulting in sequence of numerical codes (e.g., 10 0).. This approach provides structural prior by grouping related tools. However, since the hierarchy is based on static features, it may not fully capture the dynamic, collaborative relationships required for complex downstream tasks.
Semantic Tokenization. This approach uses human-readable, semantically meaningful parts of the tool's name or function its representation. Instead of creating abstract IDs, it directly tokenizes the API's function name. For instance, an API function named compress sarressfor.... por_imagon would be represented by the sequence of its natural language tokens. This method leverages the LLM's existing linguistic knowledge but may struggle with APIs that have non non-descriptive or ambiguous names, also does not explicitly model the relationships between different tools.
B.3 FULL RESULTS ON QWEN MODELS
To demonstrate the generalizability and robustness of the ToolWeaver framework beyond a single model architecture, we conducted supplementary experiments using the Qwen-2.5 model family, with the 1.5B, 3B, 7B and 14B parameter versions. We replicated our tool retrieval evaluation, comparing ToolWeave directly against the strong generative baseline, ToolGen, which employs the "one-token-per toooken-per-toor per-toor""ttreteeooo paradigm.
The comprehensive results are presented in Table The findings consistently show that ToolWeaver outperforms ToolGen across all tested model sizes and evaluation settings. Notably, the performance advantage of ToolWeaver is most pronounced in the more complex, multi-tool scenarios (12 and 13), reinforcing
claim that the collaborative-awee soning. This trend holds across different model scales. While the performance gap narrows slightly model size increases, ToolWeaver maintains consistent edge, highlighting the fundamental effi- ciency of its structured, collaborative-awaz tokenization.
tokenization is crucial for sophisticated rea-
Table Tool retrieval evaluation performance comparison between ToolGen and Tool across different Qwen-2.5 model sizes. Performance is measured by NDCG@K across different query complexities (I1, 12, 13).
Method
11 3DCG@3
13
NDCG@1
NDCG@s
NDCG@1
NDCG@3
NDCG@5
NDCG@1
NDCG@3
NDCG@5
Qwen-2.5-1.5B
ToolGen
88.00
89.55
91.98
84.96
84.40
88.15 15
69.00
71.15
80,82
Tool Weaver
89.67
89,99
91.71
88.22
87.73
89.34
87.00
87.58
Qwen-2.5-3B
ToolGen Weaver
90.32
85.21
90.67
91.66
92,99
88.47
89.08
90.28
88.00
87.63
90.95
Qwen-2.5.7B
ToolGen 91.83 92.50
92.31
94.38
89.22
88.22
91.74
80.00
82.98
86.58
92.89
91.23
91.89
88.52
Qwen-2.5.14BB
ToolGen 90.66
91.55
89.22
88.56
91.36
81.79
88.28
Tool Weaver
91.00
91.97
93.22
91.23
90.34
91.97
85.00
83.16
88.46
B.4 EXTENDED ANALYSIS ON GENERAL LANGUAGE CAPABILITIES
To investigate the impact of large-scale vocabulary expansion on an LLM's foundational abilities, we evaluated model performance on a suite of general NLP benchmarks. Integrating a vast toolset of nearly 47,000 APIs presents critical trade-off between task-specific specialization and the preser- vation of an LLM's general language capabilities. We assessed this impact across three dimensions: general understanding, language modeling distribution, and text generation quality.
B.4.1 EVALUATION SETUP
All evaluations conducted using the open-source Language Model Evaluation Hamess (Gao ct al.) (0244)), version 0.4.3, ensuring standardized prompting and scoring. For Language Mod- eling. employed sliding window approach with window size and stride of 2,048 tokens
20

---

Published as a conference paper at ICLR 2026
(non-overlapping) using the base model's tokenizer. For Text Summarization. to ensure efficiency, we evaluated a random subset of 500 samples for each task. We report ROUGE scores for n n-gram overlap and BERTScore (F1) using "roberta-larye for semantic similarity.
B.4.2 BENCIIMAR DESCRIPTIONS
We used a diverse set of benchmarks to evaluate the models:
MMLU (Massive Multitask Language Understanding) (Hendrycks et al. 2021): com-
prehensive benchmark covering 57 subjects test world knowledge and problem-solving
ability.
BoolQ (Boolean Questions) (Clark et al. 2019: : A reading comprehension dataset consist- ing of yes/no questions.
PIQA (Physical Interaction Question Answering) (Bisk et al. 2020): A commonsense reasoning benchmark testing understanding of everyday physical situations.
HellaSwag (Zellers al. 2019): commonsense inference task that challenges models to choose the most plausible completion for given text context.
2018): A science question-answering dataset requiring reasoning with small set of common knowledge facts. For this benchmark, report normalized accuracy.
OpenBookQA (Mihaylov et al.
WinoGrande (Sakaguchi et al. 2020): A commonsense reasoning dataset focused on pro- noun resolution, designed to be robust against statistical biases.
WikiText-2 (Merity et al.)
2016 : A standard language modeling benchmark. We use the
validation split to measure Perplexity (PPL) and Negative Log-Likelihood (NLL).
CNN/DailyMail (See et al.
2017) An abstractive summarization dataset consisting of
news articles.
XSum Narayan et al. 2018): dataset requiring highly abstractive, single-sentence sum- maries from BBC articles.
B.4.3 FULL EXPERIMENTAL RESULTS
General Understanding Benchmarks.
The results for tasks such as MMLU, BoolQ, and PIQA are presented Table 9 The data shows that the "one-token becken-per-tol""" approach, embodied by Tool- Gen, comes catastrophic cost to the model'ss core competencies. Its average performance plum- mets by nearly points (from 66.81% to 43.87%) compared to the original Llama-3-8B model. In stark contrast, ToolWeaver demonstrates far more effective management of this trade-off. While specialization still incurs a cost, our logarithmically scaled vocabulary results in much more con- tained degradation of only 8.4 points. Crucially, this means ToolWe mitigates over 63% of the performance loss seen with the naive generative approach.
Table 9: Performance general NLP benchmarks. Scores are accuracy (%). For OpenBookQA, the score represents normalized accuracy.
Model
MMLU
BoolQ
PIQA
HellaSwag
OpenBookQA*
WinoGrande
Avg.
Llama-3-8B (Base)
62.19
81.10
79.43
60.07
45.00
73.09
66.81
ToolGen
23.52
62.17
60.07
31.60
31.00
54.85
43.87
ToolWeaver
41.93
78.20
74.54
51.19
38.40
65.98
58.37
Language Modeling Distribution. To evaluate the integrity of the model's probability distribu- tion, we report the perplexity on WikiText-2 in Table I0] ToolGen exhibits severe explosion in perplexity, reaching 104.54, which indicates significant disruption to the natural language distribu- tion likely caused by the massive injection initialized tokens. Conversely, ToolWeaver maintains much lower perplexity of 25.36. This result suggests that our structured, collaborative aware codes integrate more harmoniously with the pre-trained weights, preserving the model's ability to predict natural language sequences.
21

---

Published as a conference paper at ICLR 2026
Table 10: Language modeling evaluation on WikiText-2 (Validation Split).
Model
Avg NLL
Perplexity
Llama-3-8B (Base)
1.847
6.34
ToolWeaver
3.233
25.36
ToolGen
4.650
104.54
Text Generation Quality. We assessed generation capabilities via zero-shot summarization, as detailed in Table II On the CNN//aiilMaiil dataset, ToolWeaver performs nearly on par with the Base LLM (BERTScore 0.8507 vs. 0.8535). On the more challenging XSum dataset, which requires high-level abstraction, ToolGen suffers a notable drop in precision (ROUGE-2 drops to 0.0175). In comparison, ToolWeaver retains robust generation capabilities (ROUGE-2 0.0261). These results confirm that Weaver not only preserves understanding but also maintains the ability to gener- coherent and accurate text, capability that is often compromised in standard generative tool learning methods.
Table 11: sero-shot summarization performance (Means over 500 samples).
CNN/DailyMaiil
XSum R-1
Model
BERTScore
R-1
R-2
R-I.
BERTScore
R-2
R-L
Llama-3-8B (Base)
0.8535
0.2107
0.0856
0.1501
0.8505
0.1494
0.0376
0.1060
ToolGen
0.8293
0.1541
0.0535
0,1127
0.8253
0.0969
0.0175
0.0702
ToolWeaver
0.8507
0.2021
0.0813
0.1461
0.8418
0.1240
0.0261
0.0872
B.5 CODEBOOK HYPERPARAMETES SENSITIVITY ANALYSIS
To empirically validate the design choices of Tool we conduct a sensitivity analysis on two critical hyperparameters governing the structured tokenization: the total size of the added vocabulary and the depth of the hierarchical code (code length).
Impact of Vocabulary Size. We first investigate how the total number of added tokens affects this experiment, we maintain a fixed code length of 2 while varying the size K of the codebooks at each layer. We specifically evaluated configurations with equal layer sizes of K E {512, 1024, 2048, 5096), which correspond total added vocabulary sizes of 1,024, 2,048, 4,096, and 10,192 tokens, respectively. As illustrated in Figure 5]a), the Average NDCG exhibits an inverted U-shape, peaking the 1024 x 2 configuration (2,048 tokens). When the codebook is too small (512 x 2), performance is suboptimal, likely due to code collision where functionally distinct tools are forced to map to the same identifiers. Crucially, as we increase the size to 2048 x 2 and further to 5096 2 (totaling 10,192 tokens), observe significant performance drop. This decline confirms our hypothesis regarding the sparsity of collaborative signals: as the vocabulary grows towards the "one-token "one-token-per-too"" extreme, the probability of related tools sharing a common code decreases. This dilutes the dense co-occurrence patterns ToolWe relies on. Consequently, our default setting of 1024 x 2 strikes the optimal balance between representational capacity and signal density.
retrieval performance.
Impact of Code Length. Next, we evaluate the effect of the code sequence length L, which cor- responds to the depth of the quantization hierarchy. We fix the codebook size per layer at K 1024 and vary L from 2 to 6. Figure((lb) shows that performance improves significantly as the hierarchy deepens, reaching a peak at T. This trend suggests that a deeper hierarchy captures finer-grained semantic nuances, aiding in precise tool disambiguation. However, performance begins to degrade as the length extends beyond 4 layers, dropping to 90.82 at L = 6. We attribute this degradation primarily to the increased difficulty of autoregressive generation, where longer sequences heighten the risk of error propagation during decoding, and potentially to the diminishing returns of residual quantization at deeper layers. Although L 4 offers the highest theoretical performance, utilize 2 in our main experiments to maintain a favorable trade-off between retrieval accuracy and inference efficiency.
22

---

Published as a conference paper at ICLR 2026
(a) Performance Vocabulary Size
(b) Performance Code Length
89.25
92
Average NDCG
NDCG
88.75
91
88.00
89
1024
2048
4006
10192
Volsons (Vocabulary
Length (Hierarchy Lovels)
Figure 5: Hyperparameter sensitivity analysis. (a) Performance vs. Vocabulary Size: Evaluated with fixed code length L 2. Performance peaks at 2.048 tokens, confirming that compact vocabulary fosters better collaborative learning than a sparse, large one. (b) Performance vs. Code Length: Evaluated with fixed codebook size K 1024. While deeper hierarchies (I. 4) improve semantic resolution, excessively long sequences (L 6) degrade performance due to generation complexity.
B.6 SINKIIORNKNNOP EFFICIENCY AND STABILITY ANALYSIS
To ensure that the conflict mitigation mechanism via uniform mapping does introduce computa- tional bottlenecks or numerical instability, we conducted comprehensive profiling analysis of the Sinkhorn-Knopp algorithm during the training of Weaver.
B.6.1 EXPERIMENTAL SETUP
We profiled the training process on a single NVIDIA LL00-SXM4-80GB GPU, using the full Tool- Bench embedding matrix (46, 984 x 768) and batch size of B = 5, 096, consistent with our main experiments described in Appendix A.3 The model employs two codebooks (L 2) with 1,024 codes each. In this configuration, the Sinkhorn-Knnn Knopp algorithm is invoked exactly twice per opti- mizer step (once for each codebook's assignment) to enforce uniformity constraints. To analyze the trade-off between stability and cost, we fixed the number of Sinkhorn iterations at 50 and swept the entropy regularization parameter e across values of {0.005, 0.01, 0.02).
B.6.2 RESULTS AND DISCUSSION
Computational Cost Analysis. We analyzed the steady-state training time per step after the initial warm-up phase. The average total time per training step is 0.161 seconds. Of this, the two Sinkhorn solves consume a combined average of 0.0283 0.0002 seconds (approximately 14.15 ms per call). This corresponds to computational overhead of only 17.6 % of the total step time. The vast majority of the computation (~~ 82%) dedicated to the encoder/decoder MLP layers and the backward pass. These results empirically verify that the Sinkhorn integration is computationally efficient and does not constitute a bottleneck for training scalability.
Stability and Uniformity. Numerical stability is critical for optimal transport algorithms. Throughout our profiling of 20 consecutive batches, we observed no NaN or Inf values, confirm- ing the numerical robustness of our implementation. Regarding uniformity, with our chosen setting of = 0.01, the final residual assignments remain highly balanced. The standard deviation of tool counts per code is 1.38 (against a theoretical target of 4.97 tools per code), with 95% of codes receiv- ing between 3 and 7 assigmments per batch. This indicates that the algorithm successfully mitigates index collapse without enforcing an overly rigid permutation.
Ablation on Entropy Regularization (e). We further analyzed the impact of performance. As summarized in Table = 0.01 provides the optimal balance. Strict regularization (c = 0.005) sharpens the distribution (Rel. Std 0.19) but increases overhead to 20.3% due slower convergence. Conversely, loose regularization (e = 0.02) degrades uniformity (Rel. Std 0.47) without improving runtime. This justifies our choice of 0.01 for the main experiments.
23

---

Published as a conference paper at ICLR 2026
Table 12: Profiling results for Sinkhorn- Knopp varying entropy regularization levels (e). The chosen setting (c = 0.01) provides the best trade-off between runtime overhead and uniformity.
Setting
Step Overhead (%)
Time per Call (ms)
Uniformity (Rel. Std)
Conclusion
0.005 (Strict)
20.3%
18.9
0.19
Slower convergence
0.01 (Ours)
17.6%
14.2
0.28
Optimal balance
0.02 (Loose)
17.5%
14.1
0.47
Degraded unifrmity
"product, it". "sol 2e3toree dee 4001 08tb orL7ccBeftug
"tool "tool_desc wld.essciinn dws.driiiinn"" iprion"
"Entrcct the information on Thai dilier's license and return text results such as diiver's license number and personal infomation.. "hama, urf hnspac/haicspp..om wericappcomm/aeee cow.tttrraantttem.m.mmm stam-bra rbonapplpp th divens koetse-oo))
"name"" "Thai Urivers Licmue oci:
"uxie: "Tha Drivers uconse OCt"
"pricig" "RREMMUM
"tool seme" "Thal Brivers License OCR?,
"eaae"" null
"tha--hhee www.eccoooor..ppeeeeee....
"ap.
"name"" Ucorset
pet.ereeoooopppppddeeeeee "mathed""
"onde" import requeesinnourt Vhitas www.ettteeeileeeeerrrr.. repidapi comdspiaa Jnw-ionneeeeeariiieie "yrlynhedeenn -In
ran-urri" ("MeBeptf6iiiieeel" Inaiddeen---ee weweeeee--ooeesrrrrr cupttap zami Nelpreepense pontturt pendereteeadeeepppp///eee (oon)/hn"
"somwrrt code" "Import requitilyinul e www.eeaneee------eee woa----o-----raee httpapp.m///////////ma/o///// poors//ammddeee "elehwadees
1SSDN-U ie
V'x-tapdk'shatt Vhhh--rrrrraa posp.mp map.aapppppccoo comil"
Tylyessconse requetts postlur)
"hest endpoinst
"extosodee" 200. "chhema::)
Categgry pame"" "mages"
Figure 6: A real RESTful API example for extracting information from Thai driver's license, including details like the API's endpoint, parameters, and code snippet for implementation.
"boel come 1URR GJCCade AP
"tael description: "The calee URL return Code image"
"bst"""" ciicode AP?".
"prcing" RESSIUMM.
"score"auu aull
"home unf ""ottt //op dapi "hoe""""rta Purt-to-ppossee-maaee
repidapi
"ap Jat"(
"noae"" "OR Code Image":
Tuetf http:///w--oppeerrrigaaaae repidap comly?".
"deuntation"" endppme taken requent shring as parmmeeer and return 13t image'
"meehhd ""L."
paroosttttss""" EL
"optionnll parsmeteer""
"Ixpe"""5
"desoriation"
google
"code" "amport rezusss/viyuull /Thttooc//rrl //rl grtode imae p-appdap .om lor Tinuerystring- (Vunk utflyryttedess (e V'Allapido--app"" VISIGN UP FOR Ain 1'X kapidAPi Heat Yurila ancode image spi rap comt. comit" "nvloorspponse requests gesjurt, hoades-heades, paromoequer wttpoeuguuostttgglllliio wwg.tttnlllllliiiiiiiion.oo httpa///hooooiittspcossseeiiiioo
"soousoode" 111.
body
fore "chhmmat"""
Figure 7: real tool example. shows details of the "URL to QRCode Image API", including its description, endpoint, method, parameters, and code snippet for implementation.
24

---

Published as a conference paper at ICLR 2026
B.7 INFERENCE LATENCY AND MEMORY ANALYSIS
While ToolWeaver achieves logarithmic scalability regarding vocabulary size, representing a single tool as a sequence of L codes naturally introduces more decoding steps compared to the atomic "one-token-per" peeeen-er-too""" approach used in baselines like ToolGen. To rigorous assess the practical cost of this design, we conducted a systematic evaluation of decoding latency, throughput, and memory consumption.
B.7.1 EXPERIMENTAL SETUP
We measured the inference performance on single NVIDIA A100-80GB GPU. To ensure fair comparison. we evaluated both ToolGen (Atomic) and Weaver with varying codebook depths (L E {2, 3, 4J4 and fixed codebook size of K 1024. The metries were averaged across the I1, 12, and retrieval tasks to cover varying query complexities. We report:
Avg Latency (ms): The average wall-clock time required to decode the tool identifier(s)
for single query.
P95 Latency (ms): The 95th percentile latency, reflecting worst-case performance.
Avg Throughput (Tok/s): The number of tokens generated per second during the decoding phase.
Peak GPU Memory (GB): The maximum GPU memory allocated during inference.
B.7.2
RESULTS AND DISCUSSION
The results are summarized in Table 13 We observe the following trends:
Table 13: Inference efficiency comparison. We compare the atomic baseline (ToolGen) against ToolWeaver with increasing codebook depths (L). While latency increases linearly with depth due to longer sequence generation, the absolute overhead is minimal (~ 20-75ms). Crucially, ToolWeaver maintains lower and constant memory footprint.
Model Configuration
Representation Structure
Avg Latency (ms)
P95 Latency (ms)
Throughput (Tok/s)
Peak Memory (GB)
ToolGen (Baselinc)
Atomic (1-level)
108.16
111.98
19.54
15.77
ToolWeaver (L = 2)
1024, 1024] 1024, 1024, 1024
128.21
132.43
24.53
15.08
ToolWeaver (I. 3)
157.65
165.73
26.34
15.10
ToolWeaver 4)
1024,, 1024, 1024, 1024)
183.14
189.11
28.26
15.11
Latency Trade-off is Acceptable. As expected, latency increases linearly with the number of codebook layers. Comparing the standard 2 setting of ToolWeaver to ToolGen, the overhead per query is approximately 20ms (108. 16ms vs. 128. 2 mms). Even with deeper hierarchy (L 4), the total latency remains under 200ms. In the context of tool-augmented agents, where executing an external API call typically consumes hundreds of milliseconds to seconds, this decoding overhead is negligible. This confirms that the trie-constrained decoding over a hierarchical code space is highly efficient for online deployment.
Higher Token Throughput. Interestingly, Tevvee exhibits higher token throughput (Tok/s) as L increases. This is natural consequence of the hierarchical representation: decoding a single logical tool requires generating L simpler code tokens. Since the computational cost per step is dom- inated by the transformer's ' forward pass (which remains constant), generating a sequence of cached code-tokens allows the system to amortize the overhead, resulting in higher apparent throughput (19.54 vs. 28.26 Tok/s). This indicates that the model's generation speed is not bottlenecked by the codebook lookup.
Memory Efficiency. A significant advantage of ToolWeaver is its memory efficiency. ToolGen requires maintaining massive embedding table and LM head for nearly 47,000 atomic tool tokens, resulting in a peak memory usage of 155.7 GB. In contrast, Weaver reduces the vocabulary
25

---

Published as a conference paper at ICLR 2026
expansion logarithmic scale (e.g., 2 x 1024 tokens), keeping the peak memory stable at ~15.10 GB across all settings. This saving of approximately 0.67 GB substantial for deploying LLMs on memory-consttranng edge devices, validating claim that ToolWeaver is more scalable solution for massive tool libraries.
B.8 FAILURE ANALYSIS
To investigate the limitations of Wevvee we analyzed error cases the end-to-end evaluation. in trajectory using strict hierarchical logic: First,
We categorize the first occurring check Process Consistency; if the predicted step index exceeds or falls short of the ground truth length, it labeled Redundant or Incomplete Process, respectively. Second, if the length is valid but the predicted identifier mismatches the ground truth. it is marked as Wrong Tool. Finally, if the tool correct but fails due to parsing errors, missing fields, runtime exceptions, it categorized as Wrong Parameters. Figure & iillustrates the distribution of these errors.
11-Tool.
[1-Cal.
20.5%
72 25
71.4%
86.5%
12
12-Cat
13
4:34
10. 1%
9%
BR.74
85.15
Wrong tool
Incomplate procees process
Wrung parameters
Figure 8: Distribution of failure types ToolBench scenarios (11-13) and generalization splits
(Tool/Cat).
The distribution reveals clear shift in failure modes across difffrrnnt stages of complexity. Wrong Tool (Blue) is the dominant error, increasing significantly from I1 (71%) to 13 95%). This indicates that as the reasoning chain grows longer and more complex (I3), the primary bottleneck becomes the precise retrieval of the correct API from the massive 47k corpus, rather than planning length. Consequently, Wrong Parameters (Pink) shows a stable presence (10-20%) in simpler scenarios (11/12), suggesting that once the model successfully locates the correct tool, its ability comprehend API schemas and generate valid arguments is relatively robust. However, in I3, the parameter error rate drops artificially (4.9% simply because the model rarely passes the initial tool selection check. Similarly, Incomplete/Reduuee confirming that in multi-step scenarios, the agent struggles primarily with semantic discrimination of tools before it can even exhibit planning or formatting faults.
processes are visible simpler tasks but vanish in complex ones,
C QUALITATIVE ANALYSIS AND EXAMPLES
C.1 CASE STUDY: ANALYSIS OF LEARNED TOOL CODES AND MULTI-TOOL COORDINATION
This section provides a detailed qualitative analysis of the hierarchical codes learned by Teavee By examining the tool clusters formed under specific high-level codes, interpret their emergent semantic meaning. Furthermore, we analyze a real execution trajectory to illustrate how these shared parent codes facilitate complex multi-tool coordination.
26

---

Published as a conference paper at ICLR 2026
C.1.1 DETAILED ANALYSIS OF LEARNED STRUCTURES
We observe that the model learns meaningful abstractions ranging from service encapsulation to functional decomposition. Below we detail three specific cases:
Case Clear Service Encapsulation (<T1 747>). This high-level code has learned to cleanly encapsulate tools related to the video game "Guild Wars 2". An analysis of the 97 tools sharing this primary code confirms this, showing perfect 100% alignment with the ground-truth Gaming category. Representative tools include:
Get Account Info (from the "Guild Wars 2 service)
Get Achievements (from the "Guild Wars 2" service)
Get Character Hero Points (from the "Guild Wars 2" service)
Get
Pvp Stats (from the "Guild Wars 2" service)
While this grouping alone demonstrates strong semantic clustering, its true value lies in creating the prerequisite for learning collaboration. By sharing the parent code <T1-747>, these tools provide a dense, shared signal during training. This allows the model to efficiently learn that these tools are often co-utilized to answer complex queries about the game, overcoming the signal sparsity issue inherent in methods that use monolithic, independent tool IDs.
Case 2: Hierarchical Functional Decomposition (<T1_184>). This case highlights the model's ability to perform functional decomposition, grouping tools related to Billboard music charts. All 92 tools under this code correctly belong to the Music category. The model correctly groups tools like Hot 100 (from the "Billboard" service) and New Zealan and Songs (from the "Billboard API service) under a single high-level code, demonstrating that learns a true functional hierarchy that transcends superficial metadata. Representative tools include:
Hot 100 (from the "Billboard" service)
New Zealand Songs (from the "Billboard API" service)
Billboard Japan Hot 100 (from the "Billboard APP" service)
Artist 100 (from the "Billboard" service)
This learned structure provides a robust foundation for complex reasoning. The shared parent code <T1 <T1_184> acts as a strong collaborative prior, signaling the model that these distinct chart APIs can be orchestrated to fulfill multifaceted request (e.g.. comparing charts across regions). This is a clear example of how our collaborative-aware tokenization creates a meaningful structure that essential for enabling complex, multi-step planning.
Case 3: Coherent Semantic Grouping for Coordination (<T1.996>). We further observe that successfully aggregates distinct tools related to Health & Fimess Metrics. This parent code clusters various metabolic calculation tools by function. Representative tools include:
BMI Calculator v2 (for standard BMI calculation)
BMI v2 (handling specific inputs like metric imperial units)
BMR TMR (for metabolic rate calculations)
By organizing these functionally similar but operationally distinct tools under coherent "Health Metrics" family, the model establishes stable semantic anchor in the latent space. This shared parent code serves as critical navigational aid, allowing the model to effectively pivot between related tool variations when specific input requirements (e.g., units of measurement) change during a task.
C.1.2 MULTI-TOOL COORDINATION TRAJECTORIES
To explicitly demonstrate how the coherent grouping described in Case facilitates actual task execution, Figure presents real execution trajectory.
27

---

Published as a conference paper at ICLR 2026
In this scenario, the user requests comprehensive integration guide for BMI app, requir- ing the use of multiple distinct BMI calculators. The trajectory reveals that the model consis- tently utilizes tools within the <T1 996> family defined above. It first invokes the standard BMI tool (<T1 996><T2 258>). Realizing the need for versatile inputs, seamlessly piv- metric-specifie endpoint (<T1_99 (<T1_996><T2_66 <062) and then to an imperial-unit endpoint (9>xT2232))) This behavior demonstrates that the shared parent code acts as a collab- orative bridge, allowing the model to effectively "explore" related sub-functions (the child codes) without losing the high-level context of the task.
Multi-Tool Coordination Trajectory (BMI Integration Task)
User Query
I'm designing mobile app tracking body mass index, and need integrate the BMI calculation API. Could you provide me with the necessary API endpoints and parameters?
Step I: Retrieve Standard Calculator
Thought
The user needs BMI endpoints. will start by retrieving standard calculator cover the basic use case.
Action
Tool:
Code:
<T1.996><12.258 (Family: Health Metrics)
Args: ("weight": 70, "htight": 170}
Step 2: Explore Metric-Specific Variation
Thought
To provide comprchensive guide, I should also check for endpoints that specifically accept explicit metric units to ensure precision.
Action
Tool:
g ves the bmi when you input values ues in metric a un
Code: <T1. <T..990>>22006>>>> (Same Parent Code)
Args: ("beight incm": 1700, "weightinkg": 700
Step 3: Explore Imperial-Unit Variation
Thought
Finally, I need to cover users who prefer imperial units (feet and inches) to make the app integration guide complete.
Action
Tool:
Lograms
Code: <T1.996><11.323-+
(Same Parent Code)
Args:
{ ("weightinkg": 70, "heightfeet": 5, "heightin
10)
Answer
Here are the necessary API endpoints for your BMI app: 1. Standard: bmi.... .. 2. Metric: g gives the bmi.... 3. Imperial: he ght in feet...
Figure 9: real execution trajectory demonstrating intra-family coordination. The model leverages the shared parent code <T1_996> (Health Metries) to coherently navigate between three distinct but functionally related BMI tools (Standard, Metric, Imperial) to fulfill a complex user request.
C.2 EXAMPLES FOR TOOLS AND APIS
To illustrate the diversity and realism of the tools and APIs used in our experiments, we present two representative examples from the ToolBench dataset. As shown in Figure 6 the first example demonstrates a real-world RESTful API for extracting information from a Thai driver's license, in- cluding its endpoint, required parameters, and sample implementation snippet. Figure showcases Ssowaasss functional tool that converts URLs into QR code images, highlighting its usage description, sup- ported parameters, and implementation code. These examples reflect the practical and executable nature of the APIs included in ToolBench.
C.3 EXAMPLES OF ALIGNMENT TUNING DATA
We also present examples for our two-stage generative alignment process. [Ugure[Ushowe a training instance for tool retrieval alignment, where the model learns to generate tool's symbolic identifier
28

---

Published as a conference paper at ICLR 2026
Retrieval Training
User:
My friend big fan of TV shows and wants to know the most popular TV shows right now. Can you fetch the list of most popular TV shows? Also, provide the overview details of these shows, such as their running time and number of episodes.
Assistant:
[Tool Identifier for "Title Get Overview Details")
Dataset example for tool selection in retrieval training. We use user role to repre- sent queries and assistant role to represent the chosen tool invocation. The placeholder (Tool identifier ...} represents the target output, whose format varies depending on the specific tokenization method being trained.
Figure 10:
from query. Figure II demonstrates training instance for tool usage trajectory alignment. It shows a multi-step interaction where the agent reasons, invokes tools, and recovers from failures to complete the task.
C.4 REAL END-TO-END INFERENCE TRAJECTORY
To further illustrate how ToolWeaver behaves at inference time, Figure 12 presents real end-to- end tool-use trajectory on complex, multi-part ToolBench-style query. The user asks the agent to design treasure hunt game that uses QR codes embedding riddles, per-clue identifiers, and a global UUID for the entire game session. For clarity, we omit the verbose system prompt and only show the user and assistant turns, well the intermediate action and argument tokens generated by the model.
D THE USAGE OF LLMS
LLMs were used as an assistive tool to improve the grammar and clarity of the manuscript, help summarize related literature, and refine concepts for figures. The core research ideas, experimental
design, and conclusions were developed entirely by the human authors, who take full responsibility for the final content of this paper.
29

---

Published as a conference paper at ICLR 2026
End-to-Ead Agent-Tuning
System:
You are AutoGPT, you can use many tools (lunctions) to following task.
First will give you task description, and your task start.
actually execule your give your thought analyze the now and what next, with function call
step, you
After the call, you will get the call result, and you are now new state.
Then you analyze your status now, thea decide what to next...
After many (Thought-call) pairs, you linally perform
then you can give your final answer.
Remember:
The state change is irreversible, you can't back one the former states. want restart the task, say
give up and resturt".
the thought is short, at most in 5 sentences.
do
one try. your plan continuously try some conditions, you do of the
conditiions per
Let's Begin!
Task description:
You should use functions to help handle the real time user queries. Remember:
ALWAYS siinish function to show to the user.
of the task. And the linal should enough information
If' you can't handle the task, you find that function calls always fail (the function is not valid now), use function Finá ch->givve ve.ppp and.restarrs.
Only generate actions and inputs.
User:
Are you able help sanitize text that has profanity? I'm looking for way automatically any had words. Can you clean up this sentence 'this is some damn good text that noeds cleaning, Clearly its pretty crap." Begin!
User:
This is the first time you try this all previous trails failed.
Before you generale my thought for this state, will first show you your previous actions for this state, and then you must generate actions that different from all of them.
Here are some previous actions candidates:
["name": "frcol Identifier
Remove Profanity]", "azguments": "|a
V "ttexx \ "thiis 1s aome damn good text that needs cleaning. clearly its pretty crap, 13"", "funct.io..uupput: Vi" message': Remember you ure now in the intermediate state of a trail, you will first analyze the now state and previous action candidates, then make
"M""ezror\"" M**,, "response":
W "API doesn't exists\ "iists\""\\"">
previous.
Assistant:
previcus action, P Profanity) failed because the API does not exist.
function
(Toal Tdent ffer for Remove
To bandle the profanity in the text, will use diffcrent approach. Instead of relying on an extemal API, I will manually create
profanity My new action will replace the profanity words
replace them asterisks.
with asterisks.
User:
Generate the action.
Assistant:
<i sh>>
User:
Please give the input. Here is the documentation:
(' "requized" U.. "opal'na''s L('name"; 'give.anewer', ddeccript lon": "Output the answer', "type" "string', ("name': "grve.p.and.essaar" 'description:: "Un- able handle the task from this step'. 'type': 'saring' H1}}
Assistaut:
rrturrn type": igive.snswert.
*ina Lanswer"; *this is some **** good text that needs cleaning, Clearly pretty
Figure 11: An example for end-to-end agent-tuning The placeholder [Tool Identifier ...} represents the target output, whose format varies depending on the specific tokenization method being trained.
30

---

Published as a conference paper at ICLR 2026
End-to-Ead Usol-Use Trajectory
System:
Standard AutoGPT-style tool-using instructions (omitted here for brevity).
User:
QR codes provide elucs. Generate QR codes with riddles as the data parameter for each clue. Additionally, include random string of characters as QR code. Finally, generate UUID for the treasure hunt game ensure the uniqueness
planning
game my family reunion
unique identifier the game session.
Assistant:
To penerate QR codes with riddles as the datn parameter for each clue, I first decide to call the function, which correspends to the Seroddegeen.or..gee.. verts URL into code image, and will use to quickly verify that generate basic code for one the clues.
"<71.12<><<T>
tool. tool con-
User:
Generate the action.
Assistant:
qr-code.gen. orr.eggg..........p....
User:
Please give the input. Here the documentation: {' ('name": 'OR Code API (Neb URL)', "description': 'Call the API Endpoin: /er and in the url parameser...'
'required" rec' [['name's "url", "typer: 'STRING' ) "opt tonal'; [....]
Assisaat::
{"url*: "https://cxample" wttpm/pplccommmlllll""
Assistat::
The busic URL to-Qu-QQQR API works, hut anly accepts simple URL string and cannot directly encode richer structured
data such "riddle text per-clue identifier". To embed hoth the riddle and random string QR paylond, need a more flexible QR code generator that allows arbitrary data content and styling. For this, will use the
"<11.93> 33223>21111>>
function.
User:
Generate the
Assistant:
oceale.gr.oode Coo.ee.ooo.llooodde
User:
Please give the input. Here the documentation: (" ('name": "I "Canerate Advance Direct Image', "description "Generates a CR code as direet image with addit
settings.', 'requirrd': [['neme's 'data', 'type' 'STRINE' } 'optional'; [...]]
Assistant:
BALLLY-RSINNU8-200 clueid: 270x9M; Riddle: What is the capital city of France?", "imageType": "png", *style": "defoule", "moduleShape": "circle", "rinTextTop": *Clue 1", "rinTextBottom": "Sean to reveal the siddle!")
["data": "Gamesession:
Assistant:
To generate a UUID the overall teasure hont game session (distinet from the per-clue radom string em- bediedd in each code). need call the "<T1,621>> (211_621<<200 <22 2> function. This corresponds the wttp:uuudddforreaaaaaa
lea_ 1 ities tool, which returss a UUID vá that can use
a unique game identifier.
User:
Generate the
Assistant:
random_uuid d_oiddforr.....oooo forooroe verbira les_ www.saandoomttt.. lifies
User:
Please give the input. Here is the documentation: ('name" GGneratee UUTDY ddesor iptiorrtttion
'Generate USID v4 with dash oz not.", 'reuuired;; U), "optionall
[..,]}
Assistant:
Assistant:
The UUID tool has returned a unique identifier for the treasure hunt game session, which will associate with all generated QR codes, Each QR code embeds session-level UUID serves as a global game identifier for tracking and management.
ClueId (e.g., 27CX9M) inside the field, while the
User:
Generate the action.
Assistant:
<<F inishsi
User:
Please give the inpur, Here is the docunentation: (' ('zeuiice';; [I, 'optional'; It' name" 'give_answer', , 'description's "Cutput the answer', 'type': 'string') ('name': sive..upand.rressart.. "description': 'Unable to handle the task this stap', 'typa': 'string' }}]
Assistant:
"ceturn.Lype":
"give_answe:",
"I have generated treasure hunt QR code clue that embeds both a riddle and a per-clue identifier, and also created a UVID for the whola sassion, Concretely, the advanced QR 20000-22UNL clueld: 270894; Riddle:
called with data
payload like "GameSession: capital city France?', and renéared as circular modules, top rim text rclue 1', and bottom rim text "Sean reveal the riddle!', Separalely, the UUID tool returna game level identifier such which uniquely tags this treasure
What
image
27077-22228-111----------2- hunt seasion."
Figure 12: real end-to-end inference trajectory of ToolWeaver handling complex, multi-part user query. The system prompt is omitted for brevity. The agent successfully reasons, selects multiple tools via hierarchical codes, adapts its tool choice after an initial limitation, and synthesizes the final answer.
31


Reviews:
[{"review_id": "MPubK4A8Xh", "reviewer": "Reviewer_uGA8", "summary": "This paper proposes ToolWeaver, a framework for scalable tool use with LLMs in large tool libraries. Instead of assigning each tool a dedicated special token (“one tool, one token”), ToolWeaver represents each tool as a multi-level sequence of discrete codes learned by a collaboration-aware residual quantization module (RQ-VAE). Tool documentation is first encoded into continuous embeddings, which are then quantized into several code levels; a tool–tool similarity matrix derived from usage logs regularizes the quantization so that semantically related and frequently co-used tools share parts of their codes. These codes are added as new vocabulary tokens to an LLM, and ToolWeaver aligns the model to generate tool codes via a two-stage process: (1) query → tool-code generation, and (2) full trajectory alignment with trie-constrained decoding to ensure only valid code sequences are produced. Experiments on ToolBench/StableToolBench with roughly 47K tools show that ToolWeaver improves tool retrieval quality (NDCG) and task metrics (SoPR/SoWR) over BM25, ToolRetriever, ToolGen, and other baselines, while reducing vocabulary growth from O(N) to O(log N).", "questions": "1.Construction of the collaboration matrix.\nHow exactly is the tool–tool similarity matrix defined in the main experiments? Is it purely based on co-occurrence within the same usage trajectory, within the same collection, or do you incorporate additional signals (e.g., category information)? How are extremely sparse tools (few or no co-usage records) handled, and have you compared different construction strategies?\n\n2.Impact of noisy or biased co-usage.\nIn realistic logs, there may be templated trajectories, heavy-tailed “head” tools, or other biases. Have you studied whether ToolWeaver over-binds such tools in code space? Did you try thresholding, smoothing, or otherwise denoising the collaboration matrix, and how did that affect performance and robustness?\n\n3.Efficiency and scalability in practice.\nCan you provide more concrete numbers on resource usage? For example, in the I3 multi-tool setting, how does end-to-end inference latency and GPU memory consumption compare to ToolGen or a strong retrieval pipeline? Is Sinkhorn-based uniform mapping a bottleneck during training?\n\n4.Impact on general language capabilities.\nYou argue that one-tool-one-token can hurt language performance, and that ToolWeaver mitigates this via a smaller vocabulary. Could you show a more systematic comparison between ToolWeaver, ToolGen, and a no-tool baseline on standard NLP benchmarks, even if only on a small set, and ideally summarize those results in the main text?", "limitations": "", "rating": 6, "confidence": 3, "soundness": 3, "presentation": 3, "contribution": 2, "strengths": "1.Well-motivated problem setting.\nThe paper clearly articulates the limitations of the “one-tool-one-token” paradigm in terms of vocabulary explosion and lack of expressivity for tool co-usage patterns, especially in multi-tool scenarios. This is a realistic pain point for large API/tool ecosystems.\n\n2.Coherent end-to-end design.\nThe framework is not just a better embedding scheme but a full pipeline: collaboration-aware RQ-VAE for code learning, a uniform mapping step to resolve code collisions, and constrained generation over a code trie to plug the representation into LLM-based agents. The components fit together in a reasonably principled way.\n\n3.Empirical gains are consistent and meaningful.\nOn multiple settings of ToolBench (I1/I2/I3, unseen tools, unseen categories), ToolWeaver shows consistent improvements in both retrieval metrics and downstream task performance compared to strong retrieval-based and generative baselines, with the gains being particularly noticeable in the more complex I3 multi-tool regime.\n\n4.Clear scalability benefits.\nEncoding tools as compositional codes with L×K tokens supports KL tools and keeps vocabulary growth logarithmic in the number of tools. At the reported scale (~47K tools), this yields a much smaller vocabulary than assigning one special token per tool, which is practically useful when one wants to preserve general language capabilities.\n\n5.Some ablations and qualitative analysis.\nThe paper includes ablations on the collaboration regularization weight, comparisons against alternative tokenization schemes (numeric / hierarchical / purely semantic / atomic), and some qualitative visualizations of shared codes, which help justify key design choices.", "weaknesses": "1.Evaluation scope is narrow.\nAll core experiments are conducted on the ToolBench / StableToolBench family. While this is a large benchmark, the tool distributions and usage patterns are specific. It remains unclear how well ToolWeaver transfers to very different tool ecosystems (e.g., enterprise APIs, programmatic or mathematical tools), or to highly dynamic tool catalogs.\n\n2.Construction and impact of the collaboration signal are under-analyzed.\nThe tool–tool similarity matrix is central to the method, but its construction (exact signal, sparsity, preprocessing) and the sensitivity of performance to its quality are not analyzed in depth. It is hard to tell how much of the gain comes from genuine collaborative structure vs. idiosyncrasies or bias in the usage logs.\n\n3.Cost and deployability are not quantified.\nCompared to a simple “one-token-per-tool + retriever” baseline, ToolWeaver adds RQ-VAE training, Sinkhorn-based uniform mapping, and trie-constrained decoding at inference. The paper does not provide concrete numbers for memory, throughput, or latency, making it difficult for practitioners to assess the cost–benefit trade-off.\n\n4.Incremental relative to prior collaboration-aware quantization.\nMethodologically, the approach is closely related to existing work on collaboration-aware residual quantization in recommender systems / generative retrieval. The main novelty is applying such ideas to tool representation and plugging them into LLM-based tool use. This is a solid extension, but conceptually more incremental than transformative.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "QEKtFx7Jc4", "reviewer": "Reviewer_1JHk", "summary": "This paper tackles the challenge of the scalability, generalization, and semantic limitations of the “one-token-per-tool” tool learning paradigm by introducing a collaborative-aware tokenization process to generate tool representation. Specifically, the proposed ToolWeaver framework uses an RQ-VAE to learn a compositional sequence for tool documentation, enabling structured representation of tool semantics beyond simple one-token identifiers. Experiments on ToolBench demonstrate the strong performance of the ToolWeaver.", "questions": "1. For W1, the authors should acknowledge these earlier solutions and clarify where ToolWeaver provides new conceptual or empirical value beyond ToolGen.\n\n2. For W2, the collaborative regularization relies critically on A_{uv}, but the paper does not explain how it is computed in detail. Whether it’s based on tool co-occurrence, textual semantic similarity, functional metadata, or learned jointly? Without this, the interpretability of the collaborative signal is limited.\n\n3. For W3, the paper should clarify the mechanism enabling ToolWeaver to handle unseen tools (i.e., “Tool.” and “Cat.” testing set). Are their representations derived compositionally from previously learned tool components? Furthermore, how is ToolGen, a token-based model, evaluated under this “unseen tool” setting where it seemingly cannot generalize by design?", "limitations": "", "rating": 4, "confidence": 4, "soundness": 3, "presentation": 2, "contribution": 3, "strengths": "1. The hierarchical quantization of tool semantics is novel and well-motivated. It offers a theoretically scalable alternative for tool representation.\n\n2. Introducing inter-tool similarity via a Laplacian regularization term is an interesting way to infuse functional relationships into discrete token learning.\n\n3. The experimental results show that ToolWeaver outperforms existing baselines significantly.", "weaknesses": "1. The paper states that generative methods suffer from a semantic bottleneck for complex reasoning and that the “one-token-per-tool” paradigm faces critical scalability and generalization challenges. However, prior work, such as ToolGen, has already implemented semantic and hierarchical indexing for tools, addressing these challenges. Thus, while these are valid drawbacks of the basic one-token paradigm, presenting them as new challenges motivating ToolWeaver seems overstated. \n\n2. The paper is missing details on constructing the tool-tool similarity matrix, though it is central to the proposed Collaborative-Aware regularization.\n\n3. It remains conceptually ambiguous how ToolWeaver achieves the retrieval and usage of tools that were unseen during training.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "kFlYzrZU4W", "reviewer": "Reviewer_brZq", "summary": "This paper proposes ToolWeaver, which changes the approach of \"each tool having a new, unique token\" to \"encoding tools into a structured code\" (like zip code/hierarchical barcode). This allows large models to scalably add many tools while learning how to use them collaboratively. It mainly replaces the one-token-per-tool mapping with a hierarchical, compositional code per tool, learned via collaborative-aware residual quantization (RQ-VAE), which is very interesting and well-motivated. On a dataset containing nearly 47,000 APIs, it is more accurate and better at handling multi-tool tasks than existing methods, without compromising the model's generalizability.", "questions": "The paper states **A** reflects “collaborative potential or functional similarity,” but does not fully specify data sources or preprocessing (e.g., co-usage in training trajectories vs. category metadata vs. external logs).\n\nCan you report retrieval/E2E vs. (i) total tokens added, (ii) code length, and (iii) decode latency? How close are you to capacity in your 47k-tool setting?\n\nWhat is the computational overhead of the Sinkhorn-Knopp algorithm per batch at your stated batch sizes (you have 50 batches, right?) ? Any instability observed (e.g., oscillations) and how it was controlled (entropy regularization, temperature)?", "limitations": "", "rating": 6, "confidence": 4, "soundness": 3, "presentation": 4, "contribution": 4, "strengths": "1. Scalability. Demonstrates logarithmic vocabulary growth with better or comparable accuracy vs. state-of-the-art while degrading general NLP ability far less than one-token approaches—highly relevant as tool libraries scale, new conrtibution based on the old trie-like data structures.\n\n2. Refactor tool IDs as structured codes learned with collaborative semantics, rather than flat special tokens; this work addresses vocabulary blow-up and enables shared structure across related tools. \n\n3. The pipeline (tokenization -> alignment tuning ->  constrained decoding) is well explained with equations and an overview figure; training/inference procedures are specified.", "weaknesses": "1. The per-batch optimal-transport uniformity reduces collisions, but the stability, or compute overhead, and behavior under streaming addition of new tools (without retraining codebooks) are unclear. How do codes evolve when tools are added/removed?\n\n2. The eval isn't super crisp when GPT-4o-mini is the judge. ToolBench is the primary testbed; API-Bank is mentioned in related work but not evaluated. Given SoWR uses GPT-4o-mini as the judge (which can bias toward itself), the adjustment is noted but still leaves some concerns—showing human evals or diverse judges would help. \n\n3. Web-scale tools or so. Since this work focuses on tool management for LLM agents, trie-constrained decoding ensures valid IDs but implicitly relies on maintaining a global registry of code sequences, akin to a catalog or lookup table. Discussing memory/latency overhead and listing the anticipated cost would be more interesting.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "OEcVE8BCT7", "reviewer": "Reviewer_sXtZ", "summary": "This paper introduces ToolWeaver. The key idea is to replace the traditional “one-token-per-tool” mapping with a hierarchical, compositional code representation derived via a collaborative-aware residual quantization (RQ-VAE) process. This allows logarithmic vocabulary growth with respect to the number of tools and enables shared subcodes among semantically related tools. Experiments on ToolBench show strong improvements over both retrieval-based (BM25, ToolRetriever) and generative (ToolGen) baselines across all settings, particularly in multi-tool reasoning and generalization to unseen tools and categories.", "questions": "1. Regarding results in table 1, I am a bit confused on the reported results. The author mentions that \"I1 Tool., I1 Cat., and I2 Cat., where 'Tool.' and “Cat.” denote tools and categories, respectively, that are unseen during training\". Intuitively, if the tools are not seen during training, the model performance will be lower. But the reported results are comparable even higher (for some columns) on unseen tools. Could author help me understand what is going on here?\n2. While ToolWeaver scales logarithmically in vocabulary size, there is a potential possibility for the total number of code combinations leading to combinatorial explosion at training and inference time. How would the author address this?", "limitations": "", "rating": 4, "confidence": 3, "soundness": 3, "presentation": 3, "contribution": 3, "strengths": "1. The idea of using hierarchical compositional code representation for tools are interesting and well-motivated.", "weaknesses": "1. It seems the current pipeline requires retraining for each newly-added tools, which raises concerns on the generalizability side.\n2. ToolBench is a widely-used dataset in the community. The authors should include more baselines in the paper.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "EclAY9XcnL", "reviewer": "Reviewer_grmY", "summary": "The paper addresses the problem of enabling LLMs to scale in their use of external tools (APIs). Prior generative tool‐invocation methods map each tool to a unique special token, which (a) scales poorly (very large vocabularies as number of tools grows) and (b) fails to capture collaborative semantics between tools (i.e., when combinations of tools often co‐occur). To address this, the authors propose ToolWeaver, which encodes each tool as a hierarchical sequence of discrete codes derived via vector quantisation (RQ‐VAE) plus a collaborative‐aware regulariser on tool–tool similarity. These code sequences map to new vocabulary tokens (but many fewer than tools) and the LLM is then fine‐tuned to generate these sequences when selecting tools. They conduct large‐scale experiments on a benchmark of 46,985 tools (from ToolBench) showing improved tool retrieval (NDCG) and end‐to‐end task completion (SoPR, SoWR) compared to retrieval‐based and other generative baselines.", "questions": "(1) Can you pls provide qualitative examples of the hierarchical codes (e.g., show codes for 5–10 tools, especially ones that share parent codes) and how the model uses them in a multi‐tool task?\n\n(2) Can you pls evaluate (or report) the impact on general text generation (e.g., on standard NLP tasks) to show the LLM’s base linguistic capacity remains unaffected?\n\n(3) Pls consider adding a failure analysis: tasks where the model fails, error types (e.g., wrong tool selection, wrong parameter generation, missing tool collaborations) would be useful for the community.", "limitations": "", "rating": 6, "confidence": 3, "soundness": 3, "presentation": 3, "contribution": 3, "strengths": "(1) Problem importance: As tool‐augmented LLMs become more capable and more tools/APIs become available, scalability of tool invocation and generalisation to new tools is a genuine bottleneck. The paper motivates this well.\n\n(2) Novel method: The hierarchical code approach is a fresh take. The use of collaborative signals between tools (via a similarity matrix and graph‐Laplacian regulariser) is a nice idea to capture co‐usage semantics.\n\n(3) Large experimental scale: Using a very large tool corpus (~47k tools) and multiple generalisation splits (unseen tools, unseen categories) strengthens the empirical claims.\n\n(4) Empirical improvements: The reported gains in retrieval metric (NDCG) and end‐to‐end task performance (SoPR, SoWR) are compelling (e.g., in Table 1 the proposed method outperforms baselines across splits).", "weaknesses": "(1) Generality beyond benchmark: The tool corpus and benchmark are large, but it is unclear how well the method would generalise to very different tool‐spaces (e.g., domains with little documentation, highly dynamic APIs, or tools with very rare co‐usage statistics). The approach relies on a pre‐computed tool–tool similarity matrix; in practice this may be hard to build for many novel tools. The authors should discuss limitations and robustness to sparse co‐usage data.\n\n(2) New vocabulary tokens & effect on base LLM: The method still adds new vocabulary tokens (the code‐tokens). Although they argue that the vocabulary expansion grows logarithmically rather than linearly, there is a cost: random initialization of embeddings, fine‐tuning, and potential interference with the LLM’s linguistic knowledge. While they mention that they evaluate on general-capability NLP benchmarks, this is lightly treated. More analysis would strengthen the claim that general language capabilities are preserved.\n\n(3) Interpretability of codes & collaborative semantics: It is claimed that tools sharing parent codes capture collaboration. But the paper does not show concrete examples of what the hierarchical codes look like in practice (e.g., clusters of tools that share code prefix) and how the model uses them in multi‐tool reasoning (I3 tasks). Some qualitative analyses of code structure and usage patterns would strengthen the contribution.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "Q4ytWr2dd1", "reviewer": "Reviewer_fdct", "summary": "The paper proposes ToolWeaver, a novel generative tool retrieval framework that encodes tools into hierarchical sequences with collaborative signals between tools. The collaborative-aware tokenization process allows the framework to weave tools' intrinsic semantics with their extrinsic co-usage patterns, encouraging functionally related tools to share codes. Experiments on the ToolBench benchmark demonstrate that the framework significantly outperforms state-of-the-art methods on tool retrieval and end-to-end performance.", "questions": "- Please use parentheses for in-line citations (\\citep). \n- It would be helpful to show a full trajectory end-to-end for better understanding", "limitations": "", "rating": 4, "confidence": 4, "soundness": 3, "presentation": 3, "contribution": 2, "strengths": "- Collaborative-aware tokenization process enables it to learn robust collaborative patterns from the dense co-occurrence of shared codes \n- It outperforms other SOTA methods on tool retrieval and usage", "weaknesses": "- Extending the vocabulary might require extensive training. In the appendix, it seems that about 2000 tool tokens are added. I wonder if all the tool tokens are being evaluated. \n- The vector quantization method is mostly borrowed from another work [1], which is the core idea of this work. Though it is interesting to see the method applied to tool learning\n- While the authros claim the work contributes to both tool retrieval and usage, it seems that the work is more focused on the tool retrieval side. I don't see any novelty in the tool usage side, such as generating correct tool parameters according to the API documentation. \n\n\n[1] Lee et al, Autoregressive Image Generation Using Residual Quantization, CVPR 2022", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}]

Author rebuttal:

Decision: Accept (Poster)