GTool: Graph Enhanced Tool Planning with Large Language Model
Authors: Wenjie Chen
Di Yao
Wenbin Li
Xuying Meng
Chang Gong
Jingping Bi
Venue: ICLR 2026 Poster (2026)
Keywords: Tool Learning
Large Language Model
Graph Data Mining
Primary area: foundation or frontier models, including LLMs
TL;DR: We propose GTool, which is the first work aiming to enhance the tool planning ability of LLMs under incomplete tool dependencies.

Abstract: Tool planning with large language models (LLMs), referring to selecting, organizing, and preparing the tools necessary to complete a user request, bridges the gap between natural language understanding and task execution. However, current works treat different tools as isolated components and fail to leverage the inherent dependencies of tools, leading to invalid planning results. Since tool dependencies are often incomplete, it becomes challenging for LLMs to accurately identify the appropriate tools required by a user request, especially when confronted with a large toolset. To solve this challenge, we propose GTool, which is the first work aiming to enhance the tool planning ability of LLMs under incomplete dependencies. GTool constructs a request-specific tool graph to select tools efficiently and generate the \<graph token\> which provides sufficient dependency information understandable by LLMs. Moreover, a missing dependency prediction task is designed to improve the reliability of GTool with incomplete dependencies. Without trimming LLMs, GTool can be seamlessly integrated with various LLM backbones without extensive retraining. Extensive experiments show that GTool achieves more than 29.6% performance improvements compared with the state-of-the-art (SOTA) baselines with a light-weight (7B) LLM backbone.

Published as a conference paper at ICLR 2026
GTOOL: GRAPH ENHANCED TOOL PLANNING WITH LARGE LANGUAGE MODEL
Wenjie Chen Di Yao 12, Wenbin Li Xuying Meng' Chang Gong Jingping Bi!
State Key Laboratory of AI Safety, Institute of Computing Technology,
Chinese Academy of Sciences, Beijing, China
Universityy of Chinese Academy of Sciences, Beijing, China
{ [chenwenjie23s] , yaodi, l liwenbin20.. mengxuying gonschangg22,
ABSTRACT
Tool planning with large language models (LLMs), referring selecting, orga- nizing, and preparing the tools necessary to complete a user request, bridges the gap between natural language understanding and task execution. However, current works treat different tools as isolated components and fail to leverage the inherent dependencies of tools, leading invalid planning results. Since tool dependencies are often incomplete, it becomes challenging for LLMs to accurately identify the appropriate tools required by a user request, especially when confronted with a large toolset. To solve this challenge, we propose GTool, which is the first work aiming to enhance the tool planning ability of LLMs under incomplete dependen- cies. GTool constructs request-specife tool graph to select tools efficiently and generate the <graph token> which provides sufficient dependency informa- tion understandable by LLMs. Moreover, missing dependency prediction task is designed to improve the reliability of GTool with incomplete dependencies. Without trimming L.Mss, GTool 1 be seamlessly integrated with various LLM backbones without extensive retraining. Extensive experiments show that GTool achieves more than 29.6% performance improvements compared with the state- of-the-art (SOTA) baselines with a light-weight (7B) LLM backbone.
INTRODUCTION
Current large language models (LLMs) have achieved significant breakthroughs in range of natural language processing tasks, but often struggle with numeric computations and delivering accurate, timely information for solving complex problems. Tool planning Qu et al. (2025), enabling LLMs to dynamically interact with external tools, such as APIs and algorithms, is the fundamental ability improve the problem-solving capability of L.MMs Qin et al. (2024a). However, tools are independent each other. The input of one tool may depend on the results of other tools, forming plan would only improve the
the complex tool dependencies. Generating dependency-coree reliability of LLMs, but also shed light on many applications, from general Al systems to industrial applications Huang al. (2024a).
To capture tool dependencies, existing works can be categorized into two groups: tuning-free meth- ods and uuning-based methods. Tuning-free free approaches Paranjape al. (2023); Schick et al. (2023); Shen et al. (2023): Liu et al.) (2024b); [Sog et al.) (2023) focus on prompt design to encode useful tool information as the context of LLM input. Various techniques, e.g., few-shot learning Paranjape et al. (2023), coarse-to-fine strategy [Snng et al. (2023) and searching on decision tree /Zhuang et al. (2023) are designed to combine the user requests, tool descriptions and dependencies for improving the tool planning ability. Without any parameter optimization, tuning-free free methods may fail in un- derstanding the user intentions and the context lengths are usually too long to be captured, leading to suboptimal planning performance. On the other hand, tuning- based methods methods[Lumer Lumer et al. 2025
Yin et al. (025); Zhang et al.] (2025) either introduce new trainable modules or construct special ized corpora fine-tune existing LLMs. LLMs are fine-tuned with LoRA Yang al. 2024b
Corresponniig author.

---

Published as a conference paper at ICLR 2026
User Request:
Tool Description:
Tool Trajectories: T1 4 L2 03 12t t - 22 t T3
Given "1g drawing an wvent, want: no know what. happened the image.
Pley specific music by sitle
Large Language Models 284
relevant
Tool Planning:
C 1z C33
Es
missing edge
Tool Dependences
Figure 1: The motivation and challenges of GTool.
Reinforcement Learning from Human Feedback (RLHF) Liang et al. 2024), to achieve better plan- ning performance. Nevertheless, these methods rely on predefined dependency structures, which are often impractical to obtain in real-world scenarios. Moreover, high computational resources are required by these methods and the construction of tuning corpus is labor-intensive.
Thus, tool planning is still in the experimental stage and not yet ready to fully meet real-world demands. Both tuning-free and tuning-based approaches ignore the incompleteness of tool depen- dencies, resulting in invalid and suboptimal plans. The tool dependencies are usually collected by the invoking tool trajectories. As shown in Figure according to and 72, we can observe that ts and t4 must be executed subsequent to tz. The dependency between ty and t4 is missing. is intractable collect sufficient tool trajectory to cover all tool dependencies. In practice, tool de- pendencies can be naturally represented as a graph, where each node corresponds to a distinct tool, believe and each edge indicates valid dependency between tools. Inspired by this observation, that the tool dependency graph is critical for tool planning and suitable for modeling the missing tool dependencies, as massive existing graph learning works & Welling (2016); Zhang & Chen 20188: Chami et al. (019) can be used for handling the incomplete dependencies.
However, integrating the tool dependency graph into tool planning is not trivial. It presents the following two challenges: (1) Request-speciffed planning. A notable characteristic of tool depen- dencies is that they are request-specific, i.e., the related tools vary significantly depending on the tasks described in the user request. How to construct build request-specified tool graph remains a challenge and would be more apparent in large-scale tool sets. (2) Modality gap of tool graph. ILMMs are designed to take textual input. Effectively aligning the tool dependency graph and ensur- ing that its dependencies are properly understood by LLMs remain critical challenges.
To overcome these challenges, we introduce GTool which is the first work specifically designed to model the incomplete tool dependencies and enhance the tool planning performance of LLMs. For request-specified planning, GTool generates request-specific tool graph which involves the user-request as a request-specific node connecting with all existing tools. The tool descriptions and request context treated the features of the dependency graph. Subsequently, GNN- based module designed to obtain the <graph token> which provides almost all dependency information. GTool introduces a missing dependency prediction strategy using LLMs, which does not assume that the tool graphs are complete. Additionally, GTool aligns the semantic space of graph representations with tool planning through supervised instruction tuning, while leveraging graph-based dependency to be understood by LLMs.
We conduct comprehensive experiments on four public datasets and summarize the key findings as follows: (1) Accurate. GTool significantly outperforms the state-of-the-ae tool planning methods, achieving over 29, performance improvements with light-weight (7B) L.M backbone. (2) Ro- bust. GTool is robust to missing tool dependencies and can effectively handle sparse tool graphs. Even the missing 90% tool dependencies, GTool can also achieve remarkable performance. (3) Efficient. GTool integrates tool descriptions into the <grpah token>, which reduces over 95% pre-task tokens processed by LLMs compared with methods encoding them in prompts. During in- ference, the time cost of GTool is only one-tenth of SOTA baselines. (4) Generalizable. We freeze all parameters of LLMs and only train GNN encoder. Thus, GTool can be seamlessly integrated with various I.LMs backbones without extensive retraining.
2

---

Published as a conference paper at ICLR 2026
Request-Tool Graph Construction
Incomplete Tool Dependence Modeling
EARE
R
Tools Description
Tool Trajectory H (f), Fgi on Fmn
GNN
Unadli and
Prompt
Pre-trained
LLM
Fj (a(t))
Pr++1
(Q)
Graph-Enhanced Planning
An-1
Request
G(4)
Request
NWS
4
(rnnpi)....
Tool Graph C
Request- Tool Graph
Description on
Prompt for Tool Planning
4TL
Figure 2: Overview of GTool.
PROBLEM FORMULATION
DEFINITION (Tool): A tool is defined as an entity, e.g., an API, designed achieve a specific functionality, Each tool t is accompanied by document d(t), which provides detailed and formal description of capabilities, input-output specifications, and operational constraints.
DEFINITION (Tool Trajectory): A tool trajectory refers to an ordered sequence of tools invoked by the an agent user fulfill user request. Formally, tool trajectory can be represented as T ft..... 4/r1 where each t; denotes a tool invoked at step i.
DEFINITION 3 (Tool Graph): Given a tool set T, a tool graph G =V, represent the dependencies among these tools. In this graph, each node 1; V corresponds tool t, E T, and a directed edge (vi, Uz) E E indicates dependency relationship between tools t; and 1.. Specifically, the presence of edge (vi, U2) signifies that the functionality output of tool t; is required as an input or precondition for the execution of tool t--
(V,E) constructed to
DEFINITION 4 (Graph- Enhhaced Tool Planning): Given collection of tools T (t1..... t a set of historical user requests and corresponding tool trajectories Q {qı.... qm and H ( T. graph-enhanced tool planning first infers interdependencies among tools and construct a tool graph G. Subsequently, for each new user request d'. graph-enhanced tool planning generates sequence of tool invocations T' leveraging the tool graph G.
METHODOLOGY
GTool consists of three modules, i.e., request-specified tool graph construction, tool dependency modeling, and graph-enhanced planning.
As illustrated in the overview in Figure 2
3.1
REQUEST-SPECIFIED TooL GRAPH CONSTRUCTION
3.1.1 TOOL GRAPH
The tool graph captures inter-dependencies between tools, enabling LLM to comprehend the com- plex interactions among large number of tools in real-world applications, thereby facilitating curate tool planning. Whereas such a tool graph is often unavailable in practice, we propose to construct tool graph G = (V, E} for given set of tools T (t1,...,f t. based historical tool trajectories H {TI,... ... }. Formally, the node set V is defined as: V {u; = (4,, a;)li 1,...,n), n). where denotes the associated tool and a; represents the node's attributes.
To initialize the attribute BERT, and utilize the generated embedding as the value of a; i.e., a; = f(d(t,)). This approach leverages the semantic richness of the tool descriptions encode meaningful attributes into the graph structure, enhancing the model's ability to capture functional and contextual relationships among tools.
input the document d(t;) of tool t; into a language model f. e.g.,

---

Published as a conference paper at ICLR 2026
The edge set E is constructed through iterative analysis of historical tool trajectories. Specifically, we initialize the edge set E as an empty set, and for each trajectory Tę = {te, t......). we add following edges to the edge set E:
E E ((U)) "ig "ig4 S |m -1
The orders of tools in historical trajectories does not fully represent the dependency relationships among them. Therefore, the constructed graph is bound contain both erroneous and missing edges, which is is an unavoidable compromise in the absence of groundtruth. Nevertheless, our method remains applicable in scenarios where groundtruth is available.
3.1.2 REQUEST-SPECIFEED TOOL GRAPH.
The constructed tool graph G' encodes both the semantic representations of tools and the inter- dependencies among them, providing valuable structural context for tool planning. However, the number of tools required for given request is significantly smaller than the overall size of the tool graph. Indiscriminately modeling the entire tool graph directly may introduce substantial irrelevant information from unrelated nodes and fails to capture the task-specific nature of tool dependencies, which can hinder the agent's decision-making accuracy.
To address this limitation, for each (V))), F( Specifically, we augment the node set ( by introducing a request-specific node 2n+1 to represent the user request q. The text of q then processed through the language model and the output is assigned as the node attribute for un+1 (gg) = U (ua+1 = (g, aa+1)) an }.))
request g. we generate request-tool graph G(q)
Subsequently, we connect directed edges from all other nodes (q)) to the request-specific node Un+1: E(q) = E u [1;, Pn+1))e; E Vgg). 0 * Un+1]. This structural configuration facilitates the propagation of tool semantic information and dependency relationships critical to the user request g along these edges to 1 during subsequent modeling. As result, the graph enables the model to aggregate and consolidate request-specific key information, thus enhancing tool planning.
3.2
TOOL DEPENDENCE MODELING
3.2. 1
GRAPH ENCODING
For given user request g, construct request-tool graph G(g), and employ GNN-based en- coder with parameters to model both the structural and semantic information embedded within the graph:
[hi,..., /nn. ())())
(1)
where h; represents the learned representation node v; derived by the model.
As every node v; < i S in the graph G(q) is connected to en+1 via directed edges, critical information relevant to the user request g can propagate along these edges to Un+ Consequently, we designate the representation hn+1 of the request-specife node un+1 as the graph representation hg in the context of user request q, i.e. he hn+1-
3.2.2 MISSING DEPENDENCY PREDICTION
The quality of the constructed graph significantly impacts the performance of tool planning. How- ever, the deeendeependences among tools may be only partially captured from historical tool trajecto- ries, potentially resulting in the tool graph G and its request-specific variant G(g) being incomplete. To address this issue, we propose missing dependency prediction with LLMs (MDPL) to improve the LLM-based agent's robustness missing edges in the graph. By explicitly modeling the edge incompleteness, MDPL ensures robust tool planning with partially observed or incomplete depen- dencies.
Specifically, the missing dependency prediction consists of the following three steps. Firstly, for any pair of nodes v; dy V, ; # 0y, if there is an edge i.e., (v,, 02) E E, we mask it with the probability of p, simultancously masking the corresponding edge (us, Uj) E E(q). and add (va, uy = 'yes')
the set of positive candidate edges + Otherwise, if (ve, my) $ F,, we add (v,, uj. = 'no')
4

---

Published as a conference paper at ICLR 2026
[/node] (node ) [/node] and [/node] (node, ambedd)) [/node] two node vectors eencaddd by the graph neural network, and detarmines whether the two nodes have edge: cconncctins, and only answers yes or no.
Given a tool graph [/graph) (grapl_emed)) [/graph] and list tools (tool, Jtst). (user, request). Please use the provided lools to salve the problem. Just answer the tool in the order they are provided.
Figure 3: The prompt instructions of GTool. (a) missing dependency prediction; (2): graph- enhanced tool planning.
to the set of negative candidate edges -- Secondly, for (Us; vy. E (É+ we generate a text corpus following the prompt template illustrated in Figure a)), where (node_embed,,) w (node_embedg) = U/. The token [/node] is used as special marker to indicate representation boundaries during LLM-based text generation. Thirdly, train the model with predicting the existence of edges in É based the learned node representations. Moreover, the text corpus is fed into a large language model M to perform autoregressive supervised fine-tuning, thereby optimizing the parameters 0 of GNN encoder.
This introduces a critical scalability challenge: tool graphs with substantial edge cardinality, direct computation of autoregressive loss over all edges incurs prohibitive computational overhead. To resolve this bottleneck, we sample from positive and negative edge sets in a balanced way:
5 = :SRS .a) . UR)EE,
(2)
where RS denotes the sampling function and hypermeter denotes the sampling size. For U5.4) E S the loss function is computed exclusively over the sampled edge set S:
LMDPL=
Σ (1)z))
(3)
|S|
where PM represents the token prediction loss computed by the language model M over the input and label.
3.3 GRAAH-ENHANCER PLANNING
After modeling the request-specifi dependencies among tools through graph learning, we employ large language model to perform tool planning for the request 9. We construct a prompt for the large language model M by integrating the user request q, the available tools T, the ground truth Te, and the representations of G(g) hg. Figure Bb) illustrates the design of the prompt template employed in GTool, where (lool_list) denotes the list encompassing the names of all tools in T. (user -querr) denotes the request 9. [/graph] serves as a special token identifier for the graph representation within the LLM generating. Notably, we assign the (graph_embed with hg- This strategic implementation enables the large model's reasoning process to effectively integrate both the request and the graph structure, thereby minimizing the influence of irrelevant tools on the performance. We input w into the large language model M and optimize 0 via the following loss:
LTL = PM (Ta/w).
(4)
The two kinds of losses are summarized with hyperparameter À balance the loss scales. Based on B3and Eq. we added them to obtain the final loss: == t This joint training approach allows GTool effectively learn both tool dependency by tool dependency prediction via LMDPL and tool planning via LTL, enhancing its overall performance. For a new request q', we perform graph-enhanced tool planning to generate tool trajectory r' for it. Specifically, we input the request q into the language model for its embedding and construct the request-tool graph G(g')) as stated in Section 3.1.2 Then, we generate the graph embedding h/2 to summarize request- specific tool inter-dependencies via the GNN-based encoder shown in Eq. [ After that, the graph embedding h/g list of tool names, and user request q are all input into the LLM M the format depicted in Figure 3b), enabling the model to perform tool planning based on the tool dependencies. Finally, we extract the tool trajectory r' from the autoregressively generated response of the large language model.
4 EXPERIMENTAL SETUP
Datasets. We conducted comprehensive experiments on two publicly available datasets, i.e., Bask SSlaughter et al. (2020) and ToolE Huang al. (2023). TaskBench comprises three
5

---

Published as a conference paper at ICLR 2026
HuggingFace
Daily Life
Multimedin
ToolF
LLMs
Methods
R.P
NED
D.FT
NED
R.FT
LFTT
NED.
NED
BM255
0.4310
0.0442
0.6654
0,5186
0.0679
0.6162
0.3625
0.0283
0.6983
0.2771
0.0169
0,7550
0.3292
0.0263
0.3404
0.0255
0.2015
0.3321
0.0233
0.7247
0.5605
0.1481
0.5568
GRTF
0.3526
0.0295
0.7193
0.2460
0.0021
0.7922
0.2675
0.0236
0.7543
0.4004
0.0221
0.6519
laskBench
0.4055
0.1584
0.6033
0.2529
0.1359
0.7605
0.3130
0.0800
0.6997
0.0808
0.0063
0,9344
HugeingGPT
0.4457
0.1192
0.5897
0,6229
0.3103
0.3930
0.3399
0.0519
0.6893
0.6184
0.2180
0.4336
Ilama
GNN4Plan
048833
0.2418
0.5267
0,3588
0.1940
0.6502
0.4593
0.2311
0.5534
0.5069
0.1870
0.5480
ToolNet
0.2140
0.0096
0.8062
196
0.0020
0.8869
0.1454
0.0057
0.8593
0.2597
0.0139
0.7434
Tool Planner
0,2690
0.0315
0.7726
0.2022
0.0190
0.8153
0.2307
0.0301
0,8040
0.3501
0,0448
0.7638
GTool
0,7913
0,5403
0,2537
0.9458
0.8375
0.0756
0.8001
0,5K55
0.2254
0.8017
0.3800
0.3167
TaskBench
0.2181
0.5226
0.7069
0,48000
0.1176
0.1069
0.7655
0.7044
0.3038
0.1769
HugeingGPT
0.5079
0.196 1965
0.5127
0.7449
0,5342
0.2725
0
1.19
0.5127
0.7500
0.3740
0.3374
Vicuna
GNN4Plan
0.5776
0.4378
0.7872
0.56.7
0.2386
0.6364
0.4021
0.3777
0.7209
0.3132
0,3650
ToolNet
0.3441
0.0423
0.7322
0,3412
0.0330
0.7237
0.3273
0.0568
0.7143
0.4415
0.0423
0.69%6
Tool Planner
0.3990
0.0830
0.3139
0.0584
0.7108
0.2756
0.0370
0.7542
0.4440
0.1071
0.6427
GTool
0.8029
0,5816
0,2153
0.9612
0.8638
0.0581
0.7905
0,5694
0.2363
0.7833
0.3500
0.3392
TaskBench
0.7682
0.5645
0.2627
0,9414
0.31
D,0855
0.7079
0.5586
0.3191
0,4227
0.36
HuggingGPP
0.7408
0.5126
0.2727
0,9252
0.8272
0.0944
0.7089
0,5421
0.3055
D.7656
0.3776
0.2946
Qwen3
GNN4Plan
0.7602
0.5347
0.2481
0,90124
0,7428
0.1207
0.8269
0.6563
0.1854
0.7639
0,4089
0.3186
ToolNet
0.3543
0.0916
0.6837
0,3197
0,0220
0.693%
0.3154
0.0765
0.7190
0.4111
0.0274
0.7282
Tool-Planner
0.6150
0.2755
0,4280
0,3229
0,0255
0.6808
0.4222
0,0989
0.5834
0.5957
0.1258
0.4809
GTool
0.8053
0.5905
0,2136
0.9668
0.8837
0.0521
0.8543
0.6749
0,1642
0.7749
0.4090
0.3013
Table 1: The planning performance of GTool and baselines on benchmark datasets. "GRTF" refers to Graph RAG-Tool Fusion.
distinct datasets, where HuggingFace encompasses a collection of Al models serving as tools, Daily Life focuses on real-life scenarios and Multimedia includes user-centric multimedia tools. ToolE covers a diverse range of tools spanning multiple domains and request types. The detailed statistics of the datasets are summarized in the Appendix A.
Baselines. Three categories of baselines, i.e., naive methods, tuning-fres methods and tuning- based methods, are employed in our experiments. Without using LLMss, naive methods includ- ing BM25 Robeetson et af. (2009). COLT Qu et al. (2024) retrieves the most similar tools of requests based on the tool descriptions. Graph RAG-Tool Fusion Lumer et al. (2025) takes into account inter-tool dependencies by planning the tool invocation sequence via a depth-first traversal over the dependency graph. Tuning-fir -fre methods, such as HuggingGPT [hhen et al. (2023) and TaskBench SSauggher et al. (2020), integrate tool descriptions into prompts and carry out plannings without any parameter optimization. For suning-baser methods, we choose the latest GNN4Plan Wu et al. 2024)) ToolNet Liu et al. (2024a) and Tool-Planner Liu et al. (2025) that learn an alignment module for boosting the planning performance of L.Mss. Note that GTool I only interact with LLMs once for one request. We do not compare works that require multiple LLM interactions, such as STE Wang et al. (2024b). Toolink Qian et al.) (2023a) and TooILLaMA QQn et al.] (2024)). These works may further improve the performance of GTool and we leave them as future work. More details of the compared baselines are in Appendix [.22
LLM Backbones. We evaluate the performance of GTool ten open-sourced LLMs. For all the baselines, we report their performance on three representative backbones in Table 1 ie., LLaMA- 2-7B Touvron et al. (2023), Vicuna-13B Zheng et al. (2024) and Qwen3-14B Team (022)). Addi- tionally, we validate the effectiveness of GTool on other LLMs. Due to space limitations, detailed results are provided in Appendix [.]
Evaluation Metries. We utilize three metrics for experimental evaluation: Node FI-Score (n-FI), Link F1-Score (1-11), and Normalized Edit Distance (NED). The n-Fl checks whether the generated plans select the right tools and I-F1 tests whether the plans preserve the topological information of the tool dependency graph. Furthermore, NED is employed to assess the correctness of the invoking order. Note the performance metrics focus primarily on the quality of the overall tool plan rather than the correctness of individual tool calls, whereas GTool's strength lies in its ability to generate coherent and effective tool plans by leveraging tool dependency modeling.
Experiment Settings All experiments are conducted on two NVIDIA A100-80G GPUs with CUDA compatibility. The total GPU occupation of all experiments is about 200 hours. The key hyperpa- rameters of our model include: the number of layers in the graph neural network ni, the number of edge pairs utilized during graph completion a, the proportion of edges masked during the graph completion process p. and the weighting coefficients for the total loss computation A. Based on ex- tensive parameter experimentation and considering model efficiency, we empirically established the
6

---

Published as a conference paper at ICLR 2026
1.0
Taskbench GNNoPan
Gloel
1.0
Tasibench CNNéPann
STool
Taskbench
Glaal
0.4
NED
NED
0.5
0.5
0.2
0.1
0.3
0.5
0.9
0.3
0.5
0.7
0.9
0.1
0.3
0.7
0.9
Llama-2-78
Vicuna-138
Qwen-14B
Figure 4: Performance comparison with different missing ratio of tool dependency graph.
optimal parameter configuration that demonstrates superior computational efficiency: (i) ny = 3, (ii 4, (iii) م 0.1. (iv) À 0.1. For all baseline methods, we have maintained their de- fault configurations to ensure a fair and consistent comparison. In the experiments, we employed TransformerCon al. (020) as the graph neural network architecture.
EXPERIMENTAL RESULTS
We conduct extensive experiments to evaluate the performance and effectiveness of GTool. Due to the space limit, we only present the main results, performance Large-scale toolset, performance of incomplete dependencies, effective experiments and ablation studies. Detailed results and anal- yses missing dependency prediction, hyperparameter studies, and case studies can be found in Appendix B.3 Appendix B.4 and Appendix C respectively.
5.1 OVERALL PERFORMANCE COMPARISON
The performances of baselines and GTool are presented in Table I According to the results, the following observations can be made: (1) Performance of GTool. GTool outperforms all baselines across almost all datasets and LLMs. The performance improvements are remarkable, egg. 26.7% growth n-F1 compared with GNN4Plan. The superior performance of GTool be attributed to the effective integration of graph neural networks and L.Mss, which enables the model to capture the topological information of tool dependency graphs and generate optimal tool sequences. Among the baselines, GNN4Plan achieves the best performance, followed by HuggingGPT. Although the align- ment module of GNN4Plan is effective in enhancing planning performance, it requires additional inference to generate textual steps, which is not required in GTool. HuggingGPT also performs better than other baselines, proving the effectiveness of prompt design. When using Vicuna- 13B and Qwen3-14BB as the backbone, HuggingGPT slightly outperforms GTool in I-F1 and NED on ToolE dataset, while underperforming in n-F1. This occurs because ToolE's ' short tool sequences (eess than 3 steps) align with HuggingGPT's concise reasoning, optimizing its short-chain predic- tions. (2) Different LLM backbones. Comparing the results of different LLM backbones, the performance of LLaMA-2-7B is slightly worse than Vieuna-13B and Qwen3-145 14B, which indicates that the capacity of LLMs has an impact on planning performance. With different LLM backbones, the performance of GTool 1 is consistently better than the compared baselines. This reveals that GTool is generalizable and robust. To assess generalizability, we further evaluate GTool on seven diverse backbone models. The results show that GTool maintains strong and stable performance across different model architectures. Full results are presented in Appendix B. due to space con- straints. (3) Different datasets. For different datasets, the results on the ToolE dataset are slightly worse than the Besk dataset. The tools in ToolE are obtained in different domains, suggest- ing that the complexity of tools has an impact on the planning performance. Nevertheless, GTool achieves better performance. 11.7% n-Fl improvement, compared with other baselines the ToolE dataset. (4) Different metrics. The performance of GTool is consistent across different metrics, demonstrating its effectiveness in selecting appropriate tools, generating optimal usage sequences, and preserving the topological information of tool dependency graphs. The performance on NED slightly worse than on n-F1 and I-F1, suggesting that the correctness of invoking order is more challenging than selecting appropriate tools and generating optimal usage sequences.
5.2 PERFORMANCE ON LARGE-SCALE TOOLSET
To evaluate the scalability of GTool, we introduce the ToolBench dataset, which contains over 16,000 RESTful APIs along with tool invocation chains generated by ChatGPT. In this extended
7

---

Published as a conference paper at ICLR 2026
Results of Planning Time
Avg Token (x102)
HuggingGPP
GNN4PPan
Tool Planner
Method
Time/R
80
ToolNet
2.53
7.01
60-
20
HuggingFace Daily Life
timedia
ToolE
Figure 5: Efficiency results. Time is measured in seconds.
setting, we use Qwen3-14B as the backbone model and compare GTool with representative tuning- free and tuning-based baselines. Detailed experimental configurations provided in Appendix A.4
ToolBench
Method n-Fl
I-FI
NED
Time/R.
TaskBench
0,3649
0.1499
0.6036
47.24
HuggingGPT
0.5989
0.2290
0,5300
12.77
GNN4Plan
0.3274
0.2757
0.6773
47.58
Tool-Planner
0.5288
0.2222
0.5333
6.67
GTool
0.6126
0,3018
0.5412
2.02
Table 2:
The planning performance comparation on ToolBench. Time measured in seconds.
The results are presented in Table 2 Compared with existing baselines, GTool achieves an im- provement of 2.28% in n-F1 and 9.46% in I-F1 under scenarios with a larger number of tools and more complex dependency structures. These results demonstrate that GTool maintains robust per- formance the scale of the toolset increases.
terms of efficiency, GTool also outperforms the baselines on large-scale datasets. This efficiency gain can be attributed to the structural characteristics of the tool graph: unlike general graphs, each tool typically depends on only a limited number of other tools. As result, the number of tool edges grows approximately linearly with the number of tools.
5.3 PERFORMANCE WITH INCOMPLETE GRAPH
To verify the performance of GTool in incomplete tool dependency graphs, we compare GTool with tuning- based methods and report the performance with different missing ratios of tool de- pendency graphs in Figure 4 As shown, the performance of GTool is consistently better than base- lines across different missing ratios, evidencing that GTool is robust incomplete tool dependency graphs. The performance of GTool is slightly worse with the increase missing ratio. It proves that the completeness of tool dependency graphs has an impact the planning performance. When the missing ratio reaches 90%, GTool underperforms the baselines on the Qwen3-14h model. This because, under such extreme sparsity, the tool dependency information is severely missing, leav- ing GTool to rely solely on the input prompt for reasoning. In contrast to the baselines, GTool uses relatively simple prompt that includes only tool names and brief instructions, which is insufficient for effective reasoning. More comprehensive results are provided in Appendix B.2
5.4 EFFICIENCY STUDIES
During model inference, the computational cost of GTool consists of two folds: (1) the token consumption of LLMs, and (2) the time consumption of graph neural networks. Regarding token efficiency, Figure presents the per-request token consumption of our method comparison with other LLM-based approaches. As illustrated, GTool achieves over 80% reduction in token con- sumption compared to HuggingGPT and Taskbench. The reason is that GTool employs request-tool graph to encode the tool descriptions instead of integrating them in prompt. For the time consump- tion of GNN, we compare the inference time of GTool with other basclines. As shown, GTool achieves approximately one-tenth the inference time, demonstrating the high efficiency of GTool.
8

---

Published as a conference paper at ICLR 2026
LJama-2-7B
Vicuna- 13B
Backbone
D-FTT
[-FT
NED
n-FTT
1-FT
NED 0
wo All
0.1566
0.0243
0.8611
0.1626
0.0394
0.8442
w/o Both
0.6131
0.3469
0.4072
0.7370
0.4831
0.2762
w/o
0.7128
0.4433
0.3108
0.7589
0.5103
0.2561
MDPL
0.7650
0.5196
0.2541
0.7707
0.5229
0.2474
LLMIp
0.7602
0.4869
0.2676
0.7784
0.5283
0.2676
G/ooo
0.7913
0,5403
0.2537
0.8029
0.5816
0.2153
Table 3: Ablation results of GTool.
5.5 ABLATION STUDIES
In this section, compare GTool with four ablations, Le., w/o All, w/o Both, w/o RS, w/o MDPL. w/o RS and w/o MDPL remove the proposed request-specific node and missing dependency predic- tion with LLMs respectively. w/o Both removes both techniques but undergoes a training process to obtain the graph token for completing tool graphs. w/o All removes the tool graph and uses only the instruction and tool names as input to the language model. w/ LLMIp denotes that we remove the MDPL module and predict the tool dependencies with LLMs directly. For detailed experimental design, please refer Appendix A.3
As shown in Table 3 without the request-specific node, the performance decreases significantly, e.g. 9.92% in n-F1, 17.9% in I-F1 and 22.5% in NED on Llama-2-78 backbone. When the MDPL strategy is omitted, GTool exhibits a decrease of 3.32% in n-F1 and 3.83% in I-F1 and an increase of O. 15% in NED on Llama-2-7B. Replacing the MDPL strategy with a LLM, Replacing the MDPL module with large language model led to similar performance decline. This demonstrates that tool dependency completion based directly on an LLM fails to match the effectiveness of the dedi- cated MDPL module. When both modules are simultancously ablated, the n-F1 decreases by 22.5%, the I-F1 score drops by 35.7%, and the NED increases by 60.5%. Note that w/o Both still achieves performance significantly higher than that of the baseline. The graph token in w/o Both contains sufficient information to enhance the performance of tool learning. The results of w/o All are very poor. This is because GTool employs very simple prompt template which only contains the tool name and a brief instruction. These results demonstrate the effectiveness of the request-specific node and the missing dependency prediction with LLMs.
When replacing the base model with Vicuna-132 13B in ablation studies, performance still dropped, though lesser extent than with LLaMA-2-7B. This likely due to Vicuna-13B's larger size and greater robustness, which help mitigate architectural changes. These results suggest that GTool yields larger improvements on weaker base models.
5.6 ROBUSTNESS STUDY
To assess the robustness of our approach, we designed and performed cold-start and transfer learn- ing experiments. Cold-start experiments test the model's performance in an extreme setting with no historical trajectories, where edges in the graph are entirely absent, necessitating reliance on large language models for edge completion. Transfer experiments evaluate the model's generalization ability through applying it to unseen datasets for tool planning.
The results of cold-start experiments are presented in Table 4 The experimental findings demon- strate that the performance degradation in cold-start settings varies across different large language models. Models with greater capability, i.e., Vicuna-13B, are demonstrably more successful ferring dependency relationships from the tool descriptions within the dataset, whereas less capable models struggle considerably. Moreover, the quality of the dataset itself exerts a considerable in- fluence on the performance. Clearer descriptions in datasets substantially aid the inference process, leading to a smaller performance drop in cold-start scenarios. For instance, the tool description for ToolE is overly simplistic. leading to more significant performance drop on this dataset compared to the Daily life dataset.
In the transfer learning experiments, GTool was trained on the HuggingFace and Multimedia datasets, respectively, and then directly transferred to other datasets without any fine-tuning. The experimental results are presented in Table 5 Although models trained both datasets exhibit performance degradation when transferred to other datasets, the model trained on the HuggingFace dataset demonstrates superior generalization capability compared to the one trained on the Multime-

---

Published as a conference paper at ICLR 2026
Llama-2-7B
Vicuna-I.33
Datasct
n-FIT
[-FTT
NED 4
n-FTT
[-FT
NED 4
Huge
0.7374
0.4684
0.2855
0.7649
0.5225
0.2538
Daily life
0.9103
0.7711
0.1106
0.9808
0,8835
0.0477
Multimedia
0.7789
0.5453
0.2454
0.7910
0.5743
0.2286
ToolE
0.7180
0.3200
0.3850
0.6955
0.3044
0.3926
Table 4: Results of cold-start experiments.
Pretrained on HaggingFace
Pretrained on Multimedia
Datasct
D-FI
IFFT NED
D-FT
IFFT
NED
Hace
0.5934
0.2835
0.4245
Daily life
0.8479
0.6699
0.1831
0.8365
0.6538
0.2005
Multimedia
0.6964
0.4511
0.3303
ToolE
0.7252
0,3366
0.3445
0.7049
0.3091
0.3785
Table 5: Results of transfer learning experiments.
dia dataset. This can be attributed the greater diversity and richness of tool types in HuggingFace, whereas Multimedia is confined to tools related to multimedia applications. This finding suggests promising direction: large-scale tool-based pre-training may endow CTool with stronger general- ization abilities.
6 RELATED WORKS
Tool Learning. Current tool learning works Qin et al. (2024a); Qu et al. (2025) enable foundation
models to use tools like humans, involving tool planning Qin al. (2024b); Liu al. (2024c)
and parameter completion Hao ct al. (2023); Wang al. (2024a). Advances include training
paradigms Park et al. (2023): Liu et al. (2024b) and generalization strategies Qin ct al. (002a))
Gao et al. 2024). Tool planning focuses
selecting and sequencing tools Qin et al. (2024b); Yuan
et al. (022); Liu et al.
2024a) or task decomposition Liang et al. (2024): Qian et al. (023a): Kong
al. 2024 Liu al.
(2024c). Parameter completion sequence-to-seve to-uuuenccee models struc-
tured prediction to map instructions to executable parameters Yang et al. (2024b); Hao et al. (2023)
Wang et al. (2024a). Recent advancements include supervised learning. trial-and-eroor, and graph- informed supervision Park et al.] (2023): Qian et al. (2023b); Liu et al. (2024b), as well as meta and curriculum tool learning Qin al. (2024a): Gao et al. (2024). 4. However, these efforts often neglect tool trajectory information and struggle with incomplete tool interaction knowledge.
Large Language Models on Graphs. Prior work integrates LLMs with graph-structured knowl- edge Jin et al.] (2024), enhancing planning tasks. Approaches include graph sequence Tian et al. ; et al. (0024b), graph-empowered LLM Jin et al. (2023), and graph-aware LLM fine- tnning Zhu et al. (2024). Graph as sequence methods encode graph structures into sequential in- puts Ye al. (023); [Tag et al. (2024), but suffer from structural information loss and increased computational burden. Graph-empowered LLMs modify Transformer architectures to encode text and graphs via hybrid attention mechanisms Zhang et al. (2022); Jin et al. (2023). but face high adaptation costs. Graph-aware fine-tuning injects graph knowledge by fine-tuning LLMs graph- derived objectives /Zhu et al.; (2024), but relies on complete underlying graphs, which is often unmet in real-world tool ecosystems. In addition, massive graph mining works Kipf & Welling (2016); Zhang & Chen (2018) Chami et al. (2019) learn to extract node representations for estimating miss- ing links of graph. Without considering the modality gap, these works cannot directly used in tool planning.
7 CONCLUSION
GTool is proposed to improve the performance of tool planning by integrating tool dependencies. It employs missing edge prediction enhance the reliability of incomplete tool dependency scenarios. The user requests are integrated into the dependency graph for efficient tool planning. Extensive experiments demonstrate that GTool not not only achieves state-of-the-arr performance but also reduces the planning time significantly. Moreover, GTool is robust to missing dependencies and can be easily generalized to different LLM backbones. In the future, we plan to evaluate the effectiveness of GTool on more powerful LLMs and its scalability to large-scale tool collections. Moreover, plan to explore more advanced techniques to improve the quality of the tool graph, such as retrieval- augmented generation and reinforcement learning.
10

---

Published as a conference paper at ICLR 2026
ACKNOWLEDGMENTS
This work has been supported by the National Natural Science Foundation of China(NSFC) under Grant No. 62472405 and No. 62372429, This work is partially supported by Alibaba Innovative Research.
REFERENCES
Ines Chami, Zhitao Ying, Christopher Ré, and Jure Leskovec. Hyperbolic graph convolutional neural networks. Advances in neural information processing systems, 32, 2019.
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 easy-to-difficult curriculum. In Proceedings of the AAAI Conference on Artificial Intelligence, volume 38, pp. 18030-18038, 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 sys- tems, 45894, 2023.
Xu Huang, Weiwen Liu, Xiaolong Chen, Xingmei Wang, Hao Wang, Defu Lian, Yasheng Wang, Ruiming Tang, and Enhong Chen. Understanding the planning of I1m agents: A survey. arXiv preprint ar arXiv:2402.02776. 2024a.
Xuanwen Huang, Kaiqiao Han, Yang Yang, Dezheng Bao, Quanjin Tao, Ziwei Chai, and Qi Zhu. Can gnn be good adapter for llms? In Proceedings of the ACM on Web Conference 2024, pp- 893-904, 2024b.
Yue Huang, Jiawen Shi, Yuan Li, Chenrui Fan, Siyuan Wu, Qihui Zhang, Yixin Liu, Pan Zhou, Yao Wan, Neil Zhenqiang Gong, et al. Metatool benchmark for large language models: Deciding whether to use tools and which to use. arXiv preprint 2rXiv:2310.0312. 2023.
Albert Q Jiang, Alexandre Sablayrolles, Arthur Mensch, Chris Bamford, Devendra Singh Chaplot, Diego de las Casas, Florian Bressand, Gianna Lengyel, Guillaume Lample, Lucile Saulnier, et al. Mistral 7b. arXiv preprint arXiv:2310.0682. 2023.
Bowen Jin, Wentao Zhang, Yu Zhang, Yu Meng, Xinyang Zhang, Qi Zhu, and Jiawei Han. Patton: Language model pretraining text-rich networks. In Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics (Volume Long Papers), pp. 7005-7020, 2023.
Bowen Jin, Gang Liu, Chi Han, Meng Jiang, Heng Ji, and Jiawei Han. Large language models on
graphs: A comprehensive survey. IEEE Transactions Knowledge and Data Engineering, 2024.
Thomas N Kipf and Max Welling. arXiv:1611.07308, 2016.
Variational graph auto-encoders.
arXiv preprint
Yilun Kong. Jingqing Ruan, Yihong Chen, Bin Zhang, Tianpeng Bao, Shi Shiwei, Du Qing, Xiaoru Hu, Hangyu Mao, Ziyue Li, al. Tptu-v2: Boosting task planning and tool usage of large lan- guage model-basee agents in real-world industry systems. In Proceedings of the 2024 Conference on Empirical Methods Natural Language Processing: Industry Track, pp. 371-385, 2024.
Yaobo Liang, Chenfei Wu, Ting Song, Wenshan Wu, Yan Xia. Yu Liu, Yang Ou, Shuai Lu, Lei Ji, Shaoguang Mao, et al. Taskmatrix. ai: Completing tasks by connecting foundation models with millions apis. Intelligent Computing, 3:0063, 2024.
Xukun Liu, Zhiyuan Peng. Xiaoyuan Yi, Xing Xie, Lirong Xiang, Yuchen Liu, and Dongkuan Xu. Toolnet: Connecting large language models with massive tools via tool graph. arXiv preprint arXiv:2403.008.. 2024a.
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. The Thirteenth International Conference on Learning Representations, 2025. URL htttps://ppenrevie hwtp:/wwwwwweeeeeeeeee.ee.eeeeee h

---

Published as a conference paper at ICLR 2026
Zhaoyang Liu, Zeqiang Lai, Zhangwei Gao, Erfei Cui, Ziheng Li, Xizhou Zhu, Lewei Lu, Qifeng Chen, Yu Qiao, Jifeng Dai, et al. Controllim: Augment language models with tools by searching graphs. In European Conference Computer Vision, pp. 89-105. Springer, 2024b.
Zuxin Liu, Thai Hoang, Jianguo Zhang, Ming Zhu, Tian Lan, Shirley Kokane, Juntao Tan, Weiran Yao. Zhiwei Liu, Yihao Feng, et al. Apigen: Automated pipeline for generating verifiable and diverse function-calling datasets. arXiv preprint arXiv:2406. 18518, 2024c.
Elias Lumer, Pradeep Honaganahalli Basavaraju, Myles Mason, James A Burke, and Vamse Kumar Subbiah. Graph rag-tool fusion. arXiv preprint arXiv:2502.07223, 2025.
Bhargavi Paranjape, Scott Lundberg, Sameer Singh, Hannaneh Hajishirzi, Luke Zettlemyer, and Marco Tulio Ribeiro. Art: Automatic multi-step reasoning and cool-use for large language models. arXiv preprint arXiv 2023.
Joon Sung Park, Joseph O'Brien, Carrie Jun Cai, Meredith Ringel Morris, Percy Liang, and Michael S Bernstein. Generative agents: Interactive simulacra of human behavior. In Proceedings of the 36th annual acm symposium on user interface software and technology, pp. 1-22, 2023.
Cheng Qian, Chenyan Xiong, Zhenghao Liu, and Zhiyuan Liu. Toolink: Linking toolkit creation and using through chain-of-sone -o-lving on open-source model. arXiv preprint a5Xiv:2310.05/555 2023a.
Cheng Qian, Xinran Zhao, and Sherry Tongshuang Wu. meerge conflicts!" exploring the impacts of external distractors parametric knowledge graphs. arXiv preprint arXiv:2309.085944 2023b.
Yujia Qin, Shengding Hu, Yankai Lin, Weize Chen, Ning Ding, Ganqu Cui, Zheni Zeng. Xuanhe Zhou, Yufci Huang, Chaojun Xiao, et al. Tool learning with foundation models. ACM Computing Surveys, 57(4): 400 2024a.
Yujia Qin, Shihao Liang, Yining Ye, Kunlun Zhu, Lan Yan, Yaxi Lu, Yankai Lin, Xin Cong, Xi- angru Tang, Bill Qian, Sihan Zhao, Lauren Hong, Runchu Tian. Ruobing Xie, Jie Zhou, Mark Gerstein, Dahai Li, Zhiyuan Liu, and Maosong Sun. Toolllm: Facilitating large language mod- els to master 16000+ real-world apis. In The Twelfth International Conference Learning Representations, ICLR 2024, Vienna, Austria, May 7-11, 2024. OpenReview.net, 2024b. URL https://openrevili
net (errummiddHHHgg2000
Changle Qu, Sunhao Dai, Xiaochi Wei, Hengyi Cai, Shuaiqiang Wang, Dawei Yin, Jun Xu, and Ji- Rong Wen. Colt: Towards completeness-oriente tool retrieval for large language models. arXiv preprint arXiv:2405. 1..4005.6608. 16089, 2024.
Changle Qu, Sunhao Dai, Xiaochi Wei, Hengyi Cai, Shuaiqiang Wang, Dawei Yin, Jun Xu, and Ji- Rong Wen. Tool learning with large language models: A survey. Frontiers of Computer Science, 1988):198343, 2025.
Stephen Robertson, Hugo Zaragoza, et al. The probabilistic relevance framework: Bm25 and be- yond. Foundations and Trends@ in Information Retrieval, 3(4):333-383) 2009.
Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi. Jingyu Liu, Romain Sauvestre, Tal Remez, et al. Code Ilama: Open foundation models for code. arXiv preprint arXiv:2308.1240 2023.
Timo Schick, Jane Dwivedi-YY Yu, Roberto Dessi, Roberta Raileanu, Maria Lomeli, Eric Hambro, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. Toolformer: Language models can teach themselves to use tools. Advances in Neural Information Processing Systems, 36:68539- 68551, 2023.
Yongliang Shen, Kaitao Song, Xu Tan, Dongsheng Li, Weiming Lu, and Yueting Zhuang, Hugging- gpt: Solving tasks with chatgpt and its friends in hugging face. Advances Neural Information Processing Systems, 36:381 1088115455 34-38880. 2023.
Yunsheng Shi, Zhengjie Huang, Shikun Feng. Hui Zhong, Wenjin Wang, and Yu Sun. Masked label prediction: Unified message passing model for semi-supervised classification. arXiv preprint arXiv:2009.03509 2020.
12

---

Published as a conference paper at ICLR 2026
Elliott Slaughter, Wei Wu, Yuankun Fu, Legend Brandenburg, Nicolai Garcia, Wilhem Kautz, Emily Marx, Kaleb S Morris, Qinglei Cao, George Bosilca, et al. Task bench: A parameterized bench- mark for evaluating parallel runtime performance. In SC20: International Conference for High Performance Computing, Networking, Storage and Analysis, pp- 1-15. IEFE, 2020.
Yifan Song, Weimin Xiong, Dawei Zhu, Wenhao Wu, Han Qian, Mingbo Song, Hailiang Huang, Cheng Li, Ke Wang, Rong Yao, et al. Restgpt: Connecting large language models with real-world 2023.
restful apis. arXiv preprint arXiv:2306.066:
Jiabin Tang, Yuhao Yang, Wei Wei, Lei Shi, Lixin Su, Suqi Cheng, Dawei Yin, and Chao Huang. Graphgpt: Graph instruction tuning for large language models. In Proceedings of the 47th In- lernational ACM SIGIR Conference Research and Development in Information Retrieval, pp. 491-500, 2024.
Qwen Team. Qwen3, April 2025. Ut/httsps///weenn......b.b.b
/wen3//
Yijun Tian, Huan Song, Zichen Wang, Haozhu Wang, Ziqing Hu, Fang Wang, Nitesh Chawla, and panpan Xu. Graph neural prompting with large language models. In Proceedings of the AAAI Conference on Artificial Intelligence, volume 38, pp. 19080-19088, 2024.
Hugo Touvron, Louis Martin, Kevin Stone, Peter Albert, Amjad Almahairi, Yasmine Babaei, Niko- lay Bashlykow. Soumya Batra, Prajjwal Bhargava, Shruti Bhosale, et al. Llama 2: Open founda- tion and fine-tuned chat models. arXiv preprint arXiv:2307.09288 2023.
Boshi Wang, Hao Fang, Jason Eisner, Benjamin Van Durme, and Yu Su. Lims in the imaginarium: Tool learning through simulated trial and error. Lun-Wei Ku, Andre Martins, and Vivek Sriku- mar (eds.). Proceedings of the 62nd Annual Meeting of the Association for Computational Lin- guistics (Volume I: Long Papers), ACI. 2024, Bangkok, Thailand, August 1-16, 2024, pp. 10583- 10604. Association for Computational Linguistics. 2024a. doi: 10.18653/V 1/0LLLLLL 570. URL httphhttts:/ott
org/ 100 10. 001665/////2220 acl 1ocec-loon..5500 acnngg 570
Boshi Wang, Hao Fang, Jason Eisner, Benjamin Van Durme, and Yu Su. Llms in the imaginarium: Tool learning through simulated trial and error, 2024b. URL htttps://rrxi..or///d /
2403. pdF
Xixi Wu, Yifei Shen, Caihua Shan, Kaitao Song, Siwei Wang, Bohang Zhang, Jiarui Feng, Hong Cheng, Wei Chen, Yun Xiong, al. Can graph learning improve task planning? arXiv preprint 0rXiv:2405.191199 2024.
An Yang, Baosong Yang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Zhou, Chengpeng Li, Chengyuan Li, Dayiheng Liu, Fei Huang, Guanting Dong, Haoran Wei, Huan Lin, Jialong Tang. Jialin Wang, Jian Yang. Jianhong Tu, Jianwei Zhang. Jianxin Ma, Jin Xu, Jingren Zhou, Jinze Bai, Jinzheng He, Junyang Lin, Kai Dang, Keming Lu,, Keqin Chen, Kexin Yang, Mei Li, Mingfeng Xue, Na Ni, Pei Zhang, Peng Wang, Ru Peng, Rui Men, Ruize Gao, Runji Lin. Shijie Wang. Shuai Bai, Sinan Tan, Tianhang Zhu, Tianhao Li, Tianyu Liu, Wenbin Ge, Xiaodong Deng, Xiaohuan Zhou, Xingzhang Ren, Xinyu Zhang, Xipin Wei, Xuancheng Ren, Yang Fan, Yang Yao, Yichang Zhang, Yu Wan, Yunfei Chu, Yuqiong Liu, Zeyu Cui, Zhenru Zhang, and Zhihao Fan. Qwen2 technical report, arXiv preprint Xrxiv:2407. 10671, 2024a.
Rui Yang. Lin Song, Yanwei Li, Sijie Zhao, Yixiao Ge. Xiu Li, and Ying Shan. Gpt4tools: Teaching large language model to use tools via self-instruction. Advances in Neural Information Processing Systems, 36, 2024b.
Ruosong Ye, Caiqi Zhang, Runhui Wang, Shuyuan Xu, Yongfeng Zhang, et al. Natural language is all graph needs. arXiv preprint 230.::23008.71344 4(5):7, 2023.
Fan Yin, Zifeng Wang, I Hsu, Jun Yan, Ke Jiang, Yanfei Chen, Jindong Gu, Long T Le, Kai- Wei Chang, Chen Yu Lec, et al. Magnet: Multi-turn tool-use data synthesis and distillation via graph translation. arXiv preprint arXiv:2503.0 07826, 2025.
Siyu Yuan, Kaitao Song, Jiangjie Chen, Xu Tan, Yongliang Shen, Ren Kan, Dongsheng Li, and Deqing Yang. Easytool: Enhancing llmebased agents with concise tool instruction. arXiv preprint arXiv:2401. 066011 2024.
13

---

Published as a conference paper at ICLR 2026
Muhan Zhang and Yixin Chen. Link prediction based graph neural networks, Advances in neural information processing systems, 31, 2018.
Shiqi Zhang, Xinbei Ma, Zouying Cao, Zhuosheng Zhang, and Hai Zhao. Plan-over-graph: Towards parallelable I1m agent schedule. arXiv preprint arXiv:2502. 14556,,..553, 2025.
Xikun Zhang, Antoine Bosselut, Michihiro Yasunaga, Hongyu Ren, Perey Liang, Christopher D Manning, and Jure Leskovec. Greaselm: Graph reasoning enhanced language models. In Inter- national Conference on Learning Representations, 2022.
Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, Siyuan Zhuang, Zhanghao Wu, Yonghao Zhuang, Zi Lin, Zhuohan Li, Dacheng Li, Eric Xing, et al. Judging Ilm-as-a-judge with mt-bench and chatbot arena. Advances in Neural Information Processing Systems, 36, 2024.
Jing Zhu, Xiang Song, Vassilis Ioannidis, Danai Koutra, and Christos Faloutsos. Touchup-g: Im- proving feature representation through graph-centric finetuning. In Proceedings of the 47th In- ternational ACM SIGIR Conference on Research and Development in Information Retrieval, pp. 2662-2666, 2024.
Yuchen Zhuang, Xiang Chen, Tong Yu, Saayan Mitra, Victor Bursztyn, Ryan Rossi, Somdeb Sarkhel, and Chao Zhang. Toolchain Efficient action space navigation in large language models with a search. arXiv preprint arXiv:2310.13227, 2023.
14

---

Published as a conference paper at ICLR 2026
APPENDIX
A EXPERIMENT CONFIGURATIONS
In this section, we provide detailed information on the experimental configurations, including the details of baselines and ablation settings.
A.1 DETAILS OF DATASETS
Detailed information regarding these four datasets is presented in Table
Table 6: Statistics datasets.
Dataset
#too!
#edge
#train
#eail
#test
HuggingFace
23
225
2178
726
726
Multimedia
40
449
1788
596
S97
Daily Life
40
1560
1672
57
558
ToolE
15
298
99
100
We further analyze the number of tools required per request within the dataset, and the distribution is shown in Figure((a) be observed that cases requiring more than two tools are fairly common.
25:0
2.03
Number of Requests
Toel
25:00
2:07
2200
Number of Edges
1300
1000
2.00
560
1000
1000
2006
2006
2006
Number of Tools per Request
Number of Nodes in the Tool Graph (b)
(a)
Figure 6: Statistics of dataset characteristics. (a) shows the distribution of the number of requests grouped by the number of tools involved each request. (b) shows the distribution the number of nodes and edges in tool graphs.
A.2 DETAILS OF BASELINES
Eight baselines are implemented Section 5.1 with the following technical specifications:
BM25. Employed as our lexical retrieval baseline, this probabilistic model calculates query- document relevance scores through term frequency-inverse document frequency (TF-IDF) statis- tical analysis. The top-5 most relevant documents are selected based on cosine similarity ranking to construct action plans.
This approach enhances tool planning by establishing dual bipartite graphs to retrieve opti- mal tools: 1) request-scenan graph and 2) scenario-tool graph. We utilize GPT-4o for automated scenario generation. The top-5 most similar tools aggregated through similarity sorting.
COLT.
Graph RAG-Tool Fusion. This method combines vector- vector-based retrieval with graph traversal to effi- ciently construct tool planning chain from predefined tool dependency graph. In our experiments, we set the top-k value for similarity- based retrieval 3, and constrain the depth of the depth-first first search maximum of 3.
15

---

Published as a conference paper at ICLR 2026
HuggingGPT. This method adopts a sophisticated chain-of-thought prompting strategy for multi- stage task planning. The number few-shot demonstrations is set to 1, following the default con- figuration of the original article.
TaskBench. We adopt the authors' proposed template engineering methodology for cross-LLM evaluation. To ensure fair comparison, we maintain identical few-shot settings (k=1) across all baseline implementations.
GNN4Plan. This graph-enhance, planner addresses the biases of LLMs, such attention and auto-regressive loss, in structured reasoning using graph neural networks. We freeze the backbone language model parameters and choose SGC GNN encoder.
ToolNet. This work structures tools as directed graph, where each node represents a tool and weighted edges indicate possible transitions between them. Starting from an initial node, a large language model navigates the graph by iteratively selecting the next tool from the successors, con- tinuing this process until the task is completed.
Tool-Planner. Tool-Planner groups tools with the same function into a toolkit and allows LLMs implement planning across the various toolkits. The number of toolkit is set to 10 during the experimental phase to evaluate the model's performance.
HuggingFace
Daily Life
Backbone
n-F1
I-F1
NED
n-F1 1
[-F1 1
NED
Llama-2-13B
0.7933
0.5685
0.2244
0,9657
0,8718
0.0578
CodeLlama-133B 133-h
0.8082
0.5895
0.2082
0.9631
0.8683
0.0598
PeepSeek-R1-Distiiee 8B
0.7706
0.5321
0.2439
0.9637
0.8545
0.0635
Mistral-7B-v0.1
0.8043
0.5834
0.2107
0.9656
0.8717
0.0578
Qwen2-7B
0.7792
0.5542
0.2367
0.9620
0.8643
0.0633
Vicuna-7B
0.7616
0.4987
0.2645
0.9274
0.8097
0.0976
Yi-6B
0.7465
0.4749
0.2812
0.9305
0.8003
0.0913
Table 7: Result of extended model architecture experiment on HuggingFace and Daily Life datasets.
Multimedia
ToolE
Backbone
n-FI
I-1
NED +
n-Fl 1
[-1 1
NED +
Llama-2-13B
0.8154
0.6247
0.2058
0.7550
0.320
0.365
CodeLlama-133B 13B-hf
0.8506
0.6765
0.1689
0.7150
0.3200
0.3650
0.8024
0.5758
0.2203
0.6631
0.2400
0.4435
Mistral-7B-v0.1
0.8126
0.6201
0.2099
0.7586
0.3522
0.3514
Qwen2-7B
0.8069
0.6108
0.2126
0.7043
0.3382
0.3797
Vicuna-7B
0.7320
0.4674
0.2927
0.6582
0.2533
0.4361
Yi-6B
0.7558
0,5054
0.2737
0.6990
0.2933
0.3950
Table 8: Result of extended model architecture experiment on Multimedia and ToolE datasets.
A.3 ABLATION SETTINGS
To validate the effectiveness of our design, we conduct the following four ablation studies:
Without request-specific node (w/o RS Node): Here, we remove the request-specific node from the tool graph. Instead of utilizing the request-specific node's embedding, we com- pute the graph vector by applying average pooling to the embeddings of all nodes. This experiment designed to assess the significance the request-specift node in capturing graph-level information.
Without missing dependency prediction with LLMS (w/o MDPL): In this scenario, we omit the optimization step described in Section 3.2.2 The tool graph obtained directly from (ectioo[3.1.21 is used for training without any further refinement.
Without request-speciff node and missing dependency prediction with LLMs (w/o Both): The removal both the RS Node and the MDPL process is conducted following the same methodology described above.
16

---

Published as a conference paper at ICLR 2026
Without all additional modules (w/o All): We conduct inference without encoding any graph information, relying solely on the prompt that does not include graph tokens.
A.4 EXPERIMENTS ON LARGER-SCALE DATASET
This experiment is conducted on the ToolBench dataset, which covers multiple instruction sce- narios, including single-tool instructions (II); intra-category multi-tool instructions (12), and intra- collection multi-tool instructions (I3). Since the II scenario involves only single-tool usage, it does align with GTool 's multi-tool planning setting and is therefore excluded from our evaluation.
For the 12 and 13 scenarios, we follow the original paper's ' retrieval strategy to select relevant tool nodes. Low-quality tools with inaccurate or missing descriptions filtered out. Based the existing tool invocation chains in the dataset, we construct tool dependency graphs by extracting directed edges among the retrieved tools.
During the graph construction process, we observe that the number of edges grows approximately linearly with the number of nodes. The detailed statistics are shown in Figure (()). This linear growth reflects the bounded nature of tool dependencies each tool typically depends on only a few others. While this sparsity less apparent small-scale datasets such as TaskBench and ToolE, becomes increasingly significant as the tool set grows, resulting in progressively sparser tool graphs.
B MORE EXPERIMENTAL RESULTS
In this section, we provide additional experimental results further validate the effectiveness of GTool. Specifically, we present the performance of GTool on more LLM backbones and provide a comprehensive robustness analysis across extended evaluation metrics.
B. PERFORMANCE ON MORE LLM BACKBONES
To systematically validate the cross- coossaachitecctuall robustness of GTool, we conduct comprehen- sive ablation studies across 6 foundational language models ranging from 7B 13B parameters,
including Llama-2-4 2--3---111uoooo et al. (2023), CodeLlama- 1-ta-111-hhhoiieee et al. (2023), Mistral-7B- v0. QTinnann et al. (2023), Qwen2-7B Yang
(2024a), Vicuna-7IB Vicuna-7BZheng et al. (2024) and Yi-6B. As
evidenced in Table 7 and Table. 8 GTcol demonstrates remarkable consistency with 0.081 perfor-
mance standard deviation across heterogeneous model architectures, while maintaining progressive scaling characteristics. Three critical observations emerge:
(1) Consistent with neural scaling laws, GTool demonstrates significant performance gains when scaling from 6B to 13B model sizes, as measured by our unified evaluation protocol.
No)abl,,,,, Mistral-7B-vO.J outperforms LLaMA-2-13B across all evaluation metrics, despite hav- ing 46% fewer parameters, which can be attributed to its optimized architectural design.
B.2 PERFORMANCE OTHER METRICS WITH INCOMPLETE GRAPH
Due to space constraints in the main manuscript, Section 5.3 primarily presents the NED evaluation metric outcomes. For comprehensive documentation, we hereby provide complete experimental results across all evaluation metrics in Figure
Consistent with the n-F1 evaluation pattern, experimental results on n-F1 and I-F1 metrics demon- strate GTool's 's robust performance characteristics.
B.3 ACCURACY OF MISSING DEPENDENCY PREDICTION
To quantitatively evaluate the missing dependency prediction approach, conduct link prediction experiments using the edge set S defined in Equation [ with frozen trained models.
As shown Table 9 the experimental results obtained from HuggingFace datasets demonstrate that all three base models achieve prediction accuracy rates exceeding 82%, which validates the model's effectiveness in predicting dependency relationships among tools.
17

---

Published as a conference paper at ICLR 2026
06-
0.8
0.6-
84
02
01
3.5
611
0.5
0.1
03
(e) Uama-2276
08
1.0
1.0
0.-
0.-
0.8-
0.0
04
0:30
6.1
(4) Qwen3-148 148
Figure 7: Performance comparison with different mask ratio with extended metrics: n-F1, I-F1 and NED.
Backbone
Accuracy
Llama-2- 2-7B
0.8471
Vicuna- 13B
0.8529
Qwen-1444
0.8221
Table 9: Experimental evaluation of missing dependency prediction accuracy.
B.4 HYPERPARAMETER ANALYSIS
GTool introduces three critical hyperparameters: the sample size of missing dependency prediction with LLMs a, balance factor À and the number of GNN layers ny. To investigate their impacts, test the performance of GTool under different settings. Figure presents the experimental results, based which we make the following observations.
Influence of a. According to the results, a exhibits diminishing returns beyond a=4. While larger a values marginally improve representation diversity (0.13% gain from a=4 a=6). The performance-stabilit trade-off analysis justifies our selection of a=4 as the best configuration.
Influence of The performance demonstrates distinct bell-shaped curve relative to values, peaking at A=0.1 before subsequent degradation. This non-monotonic relationship suggests that moderate regularization strength through À effectively balances model capacity and generalization. We find 1 is the optimal configuration.
Influence of ny. With the increase of ny, the performance of GTool initially improves and then declines. It proves that GTool suffers from overfitting problem when is large. In our experiments, we choose n, which is suitable setting for driving optimal planning performance.
C CASE STUDIES
This section presents visualizations of representative dataset instances and examines how tool de- pendencies influence tool learning, reflected in the model's outputs.
18

---

Published as a conference paper at ICLR 2026
1.00
1.00
IF1
NEO
1.00
IFI
0.75
0.75
0.75
0.50
0.50
0.50
0.25
0.25
0.25
12
6.001
0.003
Sample size EARE
(c) Number GNN layers ?)
(b) Loss weight
Figure 8: Results of hyperparameter analysis: (a) the effect of the sample size in MDPL a a (b) the influence of loss weight A; (3) the impact of the number of GNN layers ny,.
Image-to-Video
Video-to-Image
Audio-to-lmage
0.9188
0.9101
0.9013
want to create video that presents the history of cinema. For 'example..ee mpp text as voiceover: 'The history of cinema can be traced back the 19th century, when moving images were first introduced through magic lanter and zoetrope.' Additionally, could please extract a black and white still image from the synchronized video, and then colorize it to make it more captivating?
following
0.5505
0.5601
Keyword Extractor
Text Translator
Text-to-lmage
Figure 9: Cosine similarities between the Graph Token and nodes in the tool dependency graph.
C.1 SEMANTIC ANALYSIS OF THE GRAPH TOKEN
To further examine the semantics encoded in the Graph Token, compute the cosine similarity between the Graph Token representation and the node embeddings in the trained tool-dependency graph. As shown in Figure in the given request, the user asks to extract image from video based on its content. The three nodes with the highest cosine similarity are "Image-to- Video," "Video-to-Imagge" and "Audiooto-Imaae"" "meat- and "Keyword Extractor." These results suggest that the Graph Token indeed cap- tures meaningful semantic information that aligns closely with the user's intent.
while the three least similar nodes "Text Translator,"
C.2 VISUAL CASE ANALYSIS TOOL DEPENDENCY
Tool dependency, as a topology defined over tools, has a unique characteristie. highly task- dependent. In the absence of a specific task, such dependencies remain implicit. When tools exist independently, they can invoked separately without any ordering constraints. However, once task is specified
context, topological structure emerges among the tools. As illustrated in Figure 10 there exists an implicit dependency graph among the three tools shown. Request 1 and Request 2 involve similar tasks, but Request 2 includes an additional requirement audio. As result, the input to the speech classification tool becomes dependent on the output of the speech-to-speech tool. Consequently, the tool trajectory changes due to the altered task context.
enhance the
19

---

Published as a conference paper at ICLR 2026
Text-t-- Speach
Dependency graph
Audio-to- Audio
want know the emotion conveyed the following text messoge: 'Thot fontostic game yesterday, totally convert quality, cleasify speech.
user Request:
Con you please convert the Text HHlllo, how assist you today?' speech and classify the resulting oudio?
Audio
Clussificttin
GTool
Stepl: Text to Speach Step2: Audio Classification
Stepl: Text-to- Seet-to-Speech
Step2: Audio-to-Audie
Step3: Audio Classification
Figure 10: The figure illustrates two similar requests and their respective tool planning outcomes, along with the corresponding tool dependency graphs. A change in the request leads to shift in tool dependencies, ultimately resulting in different planning trajectories.
C.3 VISUAL CASE ANALYSIS OF USER REQUEST
The user's request equally crucial for tool-planning outcomes. Even with identical tool depen- dencies, slight differences in instructions can lead to entirely different plans. As shown in Figure [T] although the dependency graphs are exactly the same, User requires "classification before translation," whereas User requests "translation before classification," resulting in distinct planning outputs.
Depandency graph
Translation
Audio Claseifcation
Takes Chaxsicetoe
Request:
have oudio file named 'exomple.oov" idantify spesker, transcript, French, convert sparch
Teat-i-- Spench
I hove on outis fill 'exomple woy in forsigs lnggage, need understanding
Please
English, finally, generate English speach file.
GTool
Stepl: Classification
Shepl: Audio Classification
Step2: Classification Step3:
Step2:
Stop3: Clussification
Stap4: Text Speech
Step4: Speach
Figure 11: The figure shows two user requests that share identical tool dependency graphs but yield different tool toll-niannin results. Although the dependencies remain unchanged, subtle differences in the user instructions requusstinggggggggggggggo. classification before translation versus translation before classifi- cation leao to distinct planning trajectories.
C.4 VISUAL CASE ANALYSIS OF TOOL PLANNING OUTPUTS
Through comparative studies in Table 10 Table II and Table 12 we dissect planning outcomes from tor-perforning baselines (BM25, TaskBench, HuggingGPTY and GTool, revealing critical methodological limitations:
20

---

Published as a conference paper at ICLR 2026
User Request
Tool list
I have example.jpg image of with multiple objects. need to segment the objects in the image, estimate their depth, and classify them in tabular format.
token classification translation
summarization
Ground Truth
question answering
Tooll: Image Segmentation
conversational
Tool2: Depth Estimation
text generation
Tool3: Tabular Classification
sentence similarity
HuggingGPT
text-to-image
Tool1: Image Segmentation
text-to-video
Tool2: Depth Estimation
visual question answering
Tool3: Object Detection
document question answering
Tool4: Tabular Classification
text-to-speech
Taskbench
image editing
Tool1: Image Segmentation
tabular classification
Tool2: Depth Estimation
object detection
Tool3: Image Classification
image classification
GNN4Plan
image-to-image
Tooll: Image Segmentation
image-to-text
Tool2: Depth Estimation
image segmentation
Tool3: Image Segmentation
depth estimation
GTool
automatic speech recognition
Tool1: Image Segmentation
audio-to-audio
Tool2: Depth Estimation
audio classification
Tool3: Tabular Classification
Dependency graph
Image Segmentation
Tabular Classification
Object Detection
Image Classification
Depth Estimation
Table 10: The figure demonstrates concrete case study comprising the original user request, generated planning sequence and the corresponding tool dependency graph. Erroneous planning steps annotated in red, while missing dependencies explicitly denoted by dashed lines with cross markers.
Dependency Neglect. Table 10 illustrates a representative case study comprising a user request, planning outcomes from baseline methods, and their corresponding tool dependency graphs. The results reveal that HuggingGPT's planning sequence incorporates an additional "image segmenta- tion" step. Although this operation demonstrates semantic relevance the user's objective, the tool graph exhibits a critical structural deficiency- the absence of directed dependency edge from "image segmentation" to "text classification". This observation indicates that model prioritizes semantic associations while neglecting mandatory tool dependencies, thereby violating workflow integrity constraints.
Precision deficiency. As demonstrated in Table II all baseline methods erroneously initiate with "Image-to-Texx despite ground
truth requiring "Visual Question Answering". The observed errors stem from the semantic proximity between tool functionalities, which exceeds baseline methods' discrimination capabilities.
Limitations in processing complex dependency information. This limitation is empirically evi- denced by the erroneous tool edges generated TaskBench (Table where even explicit textual input of complete graph structures fails to guarantee accurate reasoning. Such observations sug-
21

---

Published as a conference paper at ICLR 2026
User Request
Tool list
Convert the following text: 'Rainy clouds forming in the sky.' into an audio file, enhance the audio quality, then transcribe it back text. Use the transcribed text change example- more relevant image. Answer this question based on the edited image: 'What is the weather like in the image?'. Finally, generate video based on the answer.
token classification translation
summarization
question answering
conversational
text generation
Ground Truth
sentence similarity
Tooll: Text-to-Speech
text-to-image
Tool2: Audio-to-Audio
text-to-video
Tool3: Automatic Speech Recognition
visual question answering
Tool4: Image Editing
document question answering
Tool5: Visual Question Answering
text-to-speech
Tool6: Text-to- Video
image editing
Hug
tabular classification
Tool1: Text-to-Speech
object detection
Tool2: Image Classification
image classification
TaskBench
image-to-image
Tool1: Texl-to-Speech
image-to-text
Tool2: Audio-to-Audio
image segmentation
Tool3: Automatic Speech Recognition
depth estimation
Tool4: Image-to-lmage
automatic speech recognition
Tool5: Visual Question Answering
audio-to-audio
GNN4Plan
audio classification
Tool1: Text-to-Speech
Tool2: Audio-to-Audio
Tool3: Automatic Speech Recognition
Tool4: Text-to-Image
Tool5: Visual Question Answering
GTool
Tool1: Text-to-Speech
Tool2: Audio-to-Audio
Tool3: Automatic Speech Recognition
Tool4: Image Editing
Tool5: Visual Question Answering
Tool6: Text-to-Video
Common failure patterns in baseline methods, including incorrect tool selection (high- lighted in red) and tool omission.
Table II:
gest that LLMs inherently lack the capacity to parse dense topological dependencies through purely sequential text prompts. challenge exacerbated by the models' context window limitations.
C.5 BAD CASE ANALYSIS
Many existing tools have overlapping functionalities and similar descriptions, which poses signif- icant challenges for GTool's planning, as illustrated in Figure T2 In this task, the correct tool is "Document Question Answering," but the presence to incorrect planning by GTool. Such cases are common in real-world scenarios, highlighting the need for mechanisms correct planning outputs. While this is beyond the scope of the current work, we plan to address it in future research. One potential approach is to leverage multi-turn interactions with an LLM to refine the planning results.
similar tool, "Question Answering," leads
D THE USE OF LARGE LANGUAGE MODELS
In this work, we only used large language models for manuscript polishing and word choice re- finement, as well for checking grammar and typographical errors. We explicitly state that the
22

---

Published as a conference paper at ICLR 2026
User Request
Tool list token classification translation
I have image "example.jpg containing scene of an event, and want to know what is happening the image. Then, generate short related text with the answer, convert the text to speech, and classify the audio content.
summarization
question answering
Ground Truth
conversational
Tool1: Visual Question Answering
text generation
Tool2: Text Generation
sentence similarity
Tool3: Text-to-Speech
text-to-image
Tool4: Audio Classification
text-to-video
HuggingGPT
visual question answering
Tool1: Image-to-Text
document question answering
Tool2: Text Summarization
text-to-speech
Tool3: Text-to-Speech
image editing
Tool4: Audio Classification
tabular classification
TaskBench
object detection
Tooll: Image-to-Text
image classification
Tool2: Text Classification
image-to-image
Tool3: Text Summarization
image-to-text
Tool4: Text-to-Speech
image segmentation
Tool5: Audio Classification
depth estimation
GNN4Plan
automatic speech recognition
Tool1: Image-to-Text
audio-to-audee
Tool2: Text Generation
audio classification
Tool3: Summarization
Tool4: Textt-o-Speech
Tool5: Audio Classification
GTool
Tool1: Visual Question Answering
Tool2: Text Generation
Tool3: Text-to-Speech
Tool4: Audio Classification
Table 12: Common failure patterns in baseline methods, including incorrect tool selection (high-
lighted red) and tool redundancy.
Step1: Image-to to Text Step2: Document Question Answering
have a document as an image 'example, jpg'. Can you tell the main topic of the
the extracted main topic mentioned in the document image?
GTool
Step1: Image-to- Text Step2: Question Answering
Figure 12: Bad case planned by GTool
conceptualization the ideas, the design of the models, and the implementation of the code were entirely performed without any assistance from large language models.
23


Reviews:
[{"review_id": "m5QtxxYiKF", "reviewer": "Reviewer_XZ2t", "summary": "This paper investigates the problem of tool planning with LLMs, which involves selecting and organizing the appropriate tools to fulfill a user’s request. The authors propose GTool, a framework designed to enhance LLMs’ tool planning capabilities under incomplete dependency settings. GTool constructs a request-specific tool graph that captures the relationships among tools and generates a corresponding graph token to represent dependency information in a format interpretable by LLMs. In addition, the authors introduce a missing dependency prediction task to improve the robustness of the model when faced with incomplete or partially observed tool dependencies. The method can be integrated with various LLM backbones without additional fine-tuning or retraining.", "questions": "1. The statement “leading to invalid planning results” (Line 015) is overly strong and lacks empirical support. Could the authors provide specific evidence or examples?\n\n2. The use of annotations and notations throughout the paper is inconsistent and confusing (e.g., 𝜏𝑖, 𝑡𝑖, 𝑡𝑖∈𝜏). Please clarify the notation and maintain consistency across sections.\n\n3. Could the author provide some tool dependency graphs with the same tool list but different user queries?", "limitations": "", "rating": 4, "confidence": 4, "soundness": 2, "presentation": 2, "contribution": 3, "strengths": "1. The paper addresses a practical and important problem in tool planning — how to model and utilize dependencies among tools. The issue of accurate dependency localization is indeed a real challenge in real-world tool-using scenarios.\n\n2. The experiments are extensive and cover multiple evaluation settings, demonstrating the authors' efforts to comprehensively assess the proposed approach.", "weaknesses": "1. The construction of the tool graph appears problematic. The authors assume that the use of 𝑣𝑖(𝑗+1), depends on 𝑣𝑖𝑗, which cannot be guaranteed. The order of tools in a trajectory does not necessarily imply dependency between them. This assumption weakens the validity of the proposed graph-based representation.\n\n2. The method section is difficult to follow due to inconsistent and overloaded notations. In addition, the mixed use of symbols such as \n𝜏𝑖, 𝑡𝑖1, 𝑡𝑖∈𝜏, ti∈τ, and 𝑡𝑛∈𝑇 leads to unnecessary confusion and makes the methodology harder to understand.\n\n3. The claim that multiple LLM interactions further improve the performance of GTool may not hold. While the multiple-interaction setup indeed improves tool planning, it remains unclear whether GTool truly mitigates the inherent limitations of multi-interaction settings or merely benefits from them.\n\n4. The generalization ability of GTool is questionable. Given that the dataset seems to involve a large number of tools, it is unclear whether GTool genuinely learns transferable tool dependencies—as claimed—or merely memorizes the tool usage patterns within the dataset. If the latter is true, static tool dependency graphs could achieve comparable results without additional model training or inference.\n\n5. Two critical ablation studies are missing:\n(a) Using static tool dependencies to verify that GTool performs reasoning rather than memorization.\n(b) Using an LLM to directly predict tool dependencies to demonstrate the additional effectiveness of MDPL.\nThese analyses are essential to support the paper’s claims.", "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": "VP6lyQzu2Q", "reviewer": "Reviewer_Cq2C", "summary": "This paper addresses the practical challenge of tool planning for LLMs when tool dependencies are incomplete. The proposed framework, GTool, represents tools and their relationships as a graph, which is dynamically contextualized for each user request. Its core novelty lies in a two-part approach: a GNN encoder is trained with an auxiliary Missing Dependency Prediction task, enabling it to robustly infer latent tool relationships from incomplete data, and this learned structural knowledge is efficiently injected into a pre-trained LLM via a single, compact graph token. Extensive experiments demonstrate that GTool significantly outperforms baseline methods in accuracy, robustness to missing dependencies, and computational efficiency without requiring LLM fine-tuning.", "questions": "Refer to Weaknesses.", "limitations": "", "rating": 6, "confidence": 4, "soundness": 3, "presentation": 2, "contribution": 3, "strengths": "1. The paper introduces an efficient method for the real-world problem of incomplete tool dependencies. It effectively uses a Graph Neural Network to learn the underlying tool structure and then injects this complex information into any frozen LLM using just a single, compact token.\n2. The approach is validated by extensive experiments, showing it consistently outperforms existing methods. Critically, it does not require fine-tuning the LLM, which makes it highly practical, efficient, and easy to apply across different models.", "weaknesses": "1. The method's performance depends on having good historical data to build the initial tool graph. The paper doesn't explore how well it works in 'cold-start' scenarios where such data is scarce or unavailable.\n2. The training process, which involves predicting missing links in the graph, could become a bottleneck for extremely large-scale toolsets. The paper does not fully address how the method scales when the number of tools becomes massive.\n3. The use of a single 'graph token' to represent the entire tool structure is a black box. The paper offers no insight into what specific dependency information is captured by this token or how the LLM interprets it, making the reasoning process difficult to understand.", "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": "RNtOkOcvVc", "reviewer": "Reviewer_6pZ4", "summary": "This paper proposes GTool, a graph-enhanced framework for tool planning with large language models. It constructs a request-specific tool graph to model dependencies among tools, encodes this structure with a graph neural network, and injects the resulting <graph token> into the LLM to guide tool selection and ordering. A missing-dependency prediction task allows GTool to handle incomplete graphs, and only the lightweight GNN is trained while the LLM remains frozen. Experiments show that GTool improves planning accuracy by over 29%, maintains robustness under missing dependencies, and greatly reduces inference cost.", "questions": "1. If the size of the tool graph becomes very large, can the model still maintain good inference performance when reasoning over multiple tools?\n\n2. If there are multiple similar tools, how does the paper address the resulting conflicts?\n\n3. Moreover, in the case of erroneous tool invocations, is there a proposed mechanism to resolve such issues and overcome the bottlenecks in the overall tool-calling process?", "limitations": "", "rating": 6, "confidence": 4, "soundness": 3, "presentation": 3, "contribution": 3, "strengths": "1. The paper proposes a genuinely novel and well-motivated idea — representing tool dependencies explicitly as a graph and integrating it with LLMs through a GNN encoder. This design feels natural yet surprisingly underexplored in prior work, and the authors manage to make it both elegant and technically grounded. I particularly appreciate how the paper bridges symbolic structure (graph reasoning) and LLM-based semantic planning in a coherent way.\n2. One of the most impressive aspects is the robustness under incomplete or noisy dependency graphs. The “Missing Dependency Prediction” component is not only clever but also practical — it addresses a real pain point in existing methods that assume full dependency knowledge. The fact that GTool still performs well when 90% of edges are missing is very compelling.\n3. I like that the model does not fine-tune the LLM itself — only the GNN encoder is trained. This is a huge advantage in terms of scalability and reproducibility. The reported reduction of 95% in token length and 10× faster inference time makes the method appealing not just conceptually but also computationally.\n4. The experiments are thorough and consistent. The improvement (around +30% F1 on average) is significant and holds across multiple datasets and backbones (LLaMA, Vicuna, Qwen). The ablation studies are also well-designed, showing the clear contribution of each component.\n5. The paper is well-structured and easy to follow. Figures and equations are clean, and the intuition behind each design choice (e.g., why a <graph token> is needed) is clearly articulated. The work feels mature — not just a proof of concept, but something that could realistically be integrated into production-level systems.", "weaknesses": "1. The paper provides basic ablations (e.g., removing <graph token> or MDPL), but it would be interesting to see more analysis of what the GNN actually learns — for example, visualizing attention weights or node embeddings to illustrate that it truly captures tool relationships rather than acting as a generic feature compressor.\n\n2. While the writing is overall clear, the training description could be elaborated — e.g., how the <graph token> is injected into the LLM embedding space in practice, and whether this alignment requires any additional projection layer.\n\n3. The construction of the initial tool dependency graph relies on observed invocation trajectories. In domains where such history is sparse or noisy, the method might struggle to bootstrap meaningful structure. It would strengthen the paper if the authors could discuss how GTool performs in zero-history or cold-start scenarios.", "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": "rbiqg7QATu", "reviewer": "Reviewer_eanv", "summary": "The paper presents GTool, a novel graph-enhanced framework for tool planning with large language models (LLMs). Existing tool-using systems (e.g., HuggingGPT, ToolNet) typically treat tools as independent modules and fail to model the latent dependency structure among them, leading to suboptimal planning. GTool addresses this limitation by explicitly encoding tool dependencies as a graph and integrating graph neural networks (GNNs) with frozen LLMs to perform structured reasoning.", "questions": "I remain open to further discussion from the authors. If they can address these issues more thoroughly or provide additional analysis or experiments, I would be willing to raise my original score.", "limitations": "", "rating": 4, "confidence": 4, "soundness": 3, "presentation": 4, "contribution": 3, "strengths": "1.This paper presents a very interesting perspective. Unlike traditional approaches such as ToolNet, it does not mechanically learn and plan tool invocation patterns. Instead, it systematically performs graph neural network–assisted learning based on historical tool dependencies and invocation paradigms. The theoretical foundation is strong, and the relationships between dependencies and corresponding tool-handling strategies are clearly and directly defined.\n\n2.GTool introduces a novel direction for tool invocation schemes. While traditional methods focus more on handling the current state, this work emphasizes the dependency relationships among tools. It provides detailed analysis on potential issues in planning and decomposing a problem, especially in the formalization of multi-dependency iterative invocations. Traditional tool-calling frameworks tend to be linear, but this approach can address deeper, multi-layered problems more effectively.\n\n3.Another strength of this paper lies in its impressive experimental results. Considering the complexity of tool invocation, the authors conducted experiments across multiple datasets and demonstrated the superiority of their method in terms of invocation time and performance. In particular, the proposed lightweight GNN architecture showed strong optimization capability compared to traditional long-CoT–based tool learning approaches.", "weaknesses": "1. My biggest concern is that the authors did not provide any examples or analysis of incorrect tool calls—they only examined incomplete graphs. Compared to the results on incomplete graphs, I would like to see whether the framework has the capability to adjust tool invocations after extraction through GTool. Put more simply, if we find that a certain dependency extracted by GTool fails to satisfy the basic task requirements, how does the framework adapt or adjust? Or does this paper simply not cover such adaptive capability? If the proposed method is to be applied to broader tool-use scenarios, then the ability to identify and adjust tools is even more important than fast inference.\n\n2. Following the previous point, we know that methods such as Tool-Planner and ToolNet mainly focus on handling problematic tool calls—their performance improvements often come from repairing or re-planning calls when errors occur. If GTool merely produces a plan without further revising its correctness, then I think the reported performance gains are somewhat unfair. After all, in traditional approaches like Toolformer or DFSDT, if every tool call were correct, their performance metrics would essentially match GTool’s.\n\n3. Could you further explain your final loss function? In what specific setting or stage is this loss jointly trained?\n\n4. In large-scale tool scenarios, why does GTool perform better in your experiments? Do you think this is related to the graph’s inherent understanding of tool relations? Given that with 16k tools the contextual information could become excessive—leading to higher hallucination rates—I wonder whether the graph’s strong dependency modeling might also increase the overall error rate.", "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)