GTool: Graph-Enhanced Tool Planning for LLMs

• GTool is a graph-enhanced tool planning method that encodes request-specific dependency graphs to capture incomplete tool dependencies.
• It integrates a missing dependency prediction task with a graph token, yielding over 29.6% accuracy improvement and robust planning performance.
• By coupling with a frozen LLM backbone, it reduces prompt token usage by more than 95% and inference time to one-tenth of baseline methods.

GTool is a graph-enhanced method for tool planning with LLMs in the presence of incomplete tool dependencies. In this setting, tool planning denotes selecting, organizing, and preparing the tools necessary to complete a user request. GTool addresses the claim that current approaches treat different tools as isolated components and therefore fail to leverage inherent dependencies, which can yield invalid planning results when dependency information is incomplete or toolsets are large. The method constructs a request-specific tool graph, encodes that graph into a <graph token> that is injected into the LLM prompt, and adds a missing dependency prediction task to improve reliability under incomplete dependencies. Reported experiments show more than 29.6\% performance improvements over SOTA baselines with a light-weight (7B) LLM backbone, together with more than 95\% reduction in prompt token consumption and inference time per request of only one-tenth of baselines (Chen et al., 18 Aug 2025).

1. Problem formulation and motivation

GTool is introduced for a tool-planning regime in which LLMs must reason over collections of external tools whose dependencies are only partially observed. The motivating problem is that tools often have intricate dependencies: the output of one may be needed as the input of another, forming a dependency structure that is not adequately captured when tools are treated independently. The method is positioned as the first work aiming to enhance the tool planning ability of LLMs under incomplete dependencies (Chen et al., 18 Aug 2025).

The paper distinguishes two classes of prior approaches. Tuning-free methods, including prompt engineering and few-shot chaining, encode tool descriptions and dependencies via prompts, but are described as struggling with long contexts and incomplete user intent understanding; they are also said to be unable to robustly handle missing tool dependency data. Tuning-based methods, including task-specific fine-tuning, LoRA, and RLHF, are described as relying on specialized, often manually-labeled datasets in which dependencies are assumed to be known and complete, making them resource-intensive and not robust to incomplete or real-world missing dependency graphs. In that formulation, the central difficulty is not only selecting relevant tools, but doing so when the dependency graph itself is only partially available (Chen et al., 18 Aug 2025).

A recurrent misconception is that tool descriptions alone are sufficient for reliable planning. GTool explicitly rejects that assumption by making dependency structure a first-class object. Another misconception is that incomplete dependency graphs can be handled merely by longer prompts; the paper instead treats missing dependencies as a separate prediction problem rather than a prompt-formatting issue (Chen et al., 18 Aug 2025).

2. Request-specific tool graph construction

The core representation in GTool is a request-specific tool graph. The global tool graph has node set

$$V = \left\{ v_i = (t_i, a_i) \mid i = 1, \ldots, n \right\},$$

where each node $v_i$ represents a tool $t_i$ with attribute $a_i$ derived from the tool’s documentation,

$a_i = f(d(t_i)),$

with $f$ typically instantiated as a language encoder such as BERT. Edges are derived iteratively from actual tool usage trajectories $H = \{ \tau_1, \ldots, \tau_m \}$,

$$E \leftarrow E \cup \{ (v_{i_j}, v_{i_{j+1}}) \mid 1 \leq j \leq |\tau_i| - 1 \}.$$

This makes the graph trajectory-grounded rather than purely schema-driven (Chen et al., 18 Aug 2025).

For a user query $q$, GTool augments the graph with a request node,

$$V(q) = V \cup \{ v_{n+1} = (q, a_{n+1}) \mid a_{n+1} = f(q) \},$$

and then connects all tool nodes to that request node through directed edges,

$v_i$0

The stated purpose is to allow information propagation from tools to the request node, so that the learned graph-level representation is specific to the current request rather than a static summary of the tool inventory (Chen et al., 18 Aug 2025).

The graph is encoded by a GNN $v_i$1,

$v_i$2

and the embedding of the request node is taken as the graph-level representation,

$v_i$3

This $v_i$4 is the <graph token>. It is inserted into the prompt with a custom marker such as [/graph], with the stated goal of providing condensed and contextually relevant dependency information that remains understandable to the LLM even when the number of tools is large and their relations are complex (Chen et al., 18 Aug 2025).

3. Missing dependency prediction

A defining feature of GTool is that it does not assume observed tool trajectories yield a complete dependency graph. Instead, it introduces Missing Dependency Prediction with LLMs (MDPL) to infer plausible unobserved edges. During training, edges are artificially masked at random with probability $v_i$5. Masked positive edges are labeled yes, written as $v_i$6, while negative samples are node pairs with no edge, labeled no (Chen et al., 18 Aug 2025).

Because the number of candidate pairs is large, the method uses balanced sampling: $v_i$7 where $v_i$8 is a random sampling function and $v_i$9 is the sample size. The loss over sampled edges is written as

$t_i$0

where $t_i$1 is the LLM’s predicted probability for label $t_i$2 given prompt $t_i$3 (Chen et al., 18 Aug 2025).

The paper attributes two roles to MDPL. First, it directly improves robustness by allowing the system to infer plausible missing dependencies instead of collapsing when historical tool-usage data are sparse. Second, it stabilizes planning under high rates of edge absence. The appendix reportedly gives empirical missing dependency prediction accuracy greater than 82\%, which is used as evidence that the model can recover substantial dependency information from incomplete graphs (Chen et al., 18 Aug 2025).

This suggests that GTool treats incompleteness as a learnable structural uncertainty problem rather than as annotation noise. A plausible implication is that the method is most valuable when historical trajectories are informative but not exhaustive, which is a common condition in dynamic tool ecosystems; that implication is consistent with the paper’s framing, though not separately benchmarked as a theoretical claim (Chen et al., 18 Aug 2025).

4. LLM coupling, optimization, and inference pathway

GTool is designed so that the LLM backbone remains frozen. The paper states that GTool does not fine-tune or modify LLM parameters and that all training is restricted to the GNN encoder $t_i$4, which produces the <graph token>. At inference time, the system constructs the request-specific graph, encodes it, and concatenates the resulting representation with a simple prompt of the form $a_i$4 before sending the input to the frozen LLM (Chen et al., 18 Aug 2025).

The method is described as seamlessly integrable with various LLM backbones, including Llama-2, Vicuna, and Qwen3, without extensive retraining. In that sense, GTool is a plug-in planning module rather than an end-to-end reparameterization of the underlying LLM (Chen et al., 18 Aug 2025).

The joint objective combines tool planning and missing dependency prediction. The planning loss is written as

$t_i$5

and the total loss as

$t_i$6

The accompanying hyperparameter analysis reports optimal performance with 3 GNN layers, moderate MDPL loss weighting, and sampling size $t_i$7 (Chen et al., 18 Aug 2025).

A second misconception is that GTool is a fine-tuning framework for LLM agents. The paper states the opposite: the frozen LLM is retained, while the trainable component is the graph encoder. That design choice is central to the reported claims of low integration cost and backbone portability (Chen et al., 18 Aug 2025).

5. Empirical evaluation and reported performance

GTool is evaluated on HuggingFace, Daily Life, Multimedia from TaskBench, and ToolE. The reported metrics are Node F1 (n-F1), Link F1 (l-F1), and Normalized Edit Distance (NED). Across these settings, the paper reports more than 29.6\% improvement in planning accuracy over SOTA baselines with a 7B backbone (Chen et al., 18 Aug 2025).

A concrete example is given for HuggingFace with a Llama-2-7B backbone. GTool reports n-F1 $t_i$8, l-F1 $t_i$9, and NED $a_i$0, whereas the best baseline, GNN4Plan, reports n-F1 $a_i$1, l-F1 $a_i$2, and NED $a_i$3. The method is also described as performing consistently across other LLMs, including Vicuna-13B and Qwen3-14B (Chen et al., 18 Aug 2025).

Robustness under severe graph incompleteness is a central empirical claim. Even when 90\% of tool dependencies are missing, GTool is reported to maintain high planning performance and to significantly outperform both tuning-based and tuning-free SOTA baselines. Efficiency claims are equally prominent: the <graph token> mechanism reportedly yields more than 95\% reduction in prompt token consumption, and inference time per request is only one-tenth of baselines (Chen et al., 18 Aug 2025).

The scalability evaluation extends beyond standard benchmarks. The method is reported to be plug-and-play with up to 10 different backbones and to scale to ToolBench with more than 16,000 APIs, where it achieves higher planning accuracy and efficiency than existing approaches. Ablation studies further report that removing either the request node or missing dependency prediction causes 3–17\% relative performance drops, while removing both returns performance to near-baseline (Chen et al., 18 Aug 2025).

These results are specifically about planning quality and planning efficiency. They should not be conflated with end-to-end agent success on open-ended workflows, which is a broader evaluation problem addressed elsewhere in the literature (Wang et al., 17 Apr 2026).

6. Position within the tool-use literature

The name “GTool” can be confused with several adjacent lines of work. In the GEAR literature, “GTool” appears as a generic label for the tool resolution problem: selecting the most appropriate tool and generating a suitable API call. GEAR addresses that problem through a computationally efficient query-tool grounding algorithm that delegates tool grounding to small LLMs and execution to an LLM, using semantic and pattern-based evaluation. GTool, by contrast, is specifically a graph-enhanced planning method for incomplete dependencies (Lu et al., 2023, Chen et al., 18 Aug 2025).

GTool is also distinct from GOAT, which is a training framework that automatically constructs synthetic datasets of goal-oriented API execution tasks directly from API documents and fine-tunes LLM agents in a human annotation-free setting. The contrast is direct: GOAT centers on synthetic supervision and agent fine-tuning, whereas GTool states that it does not fine-tune or modify LLM parameters and instead trains only a GNN encoder that supplies a graph-conditioned planning representation (Min et al., 14 Oct 2025, Chen et al., 18 Aug 2025).

Relative to benchmarking work, GTA-2 evaluates General Tool Agents on both atomic tool use and open-ended workflows and reports a pronounced capability cliff, with frontier models below 50\% on atomic tasks and top workflow success at only 14.39\%. This suggests that improved tool planning, while important, is not equivalent to complete workflow competence; execution harness design, persistent memory, dynamic planning, and deliverable construction remain distinct bottlenecks (Wang et al., 17 Apr 2026).

Relative to tool simulation work, GTM introduces a 1.5-billion-parameter universal tool simulator trained on over 20,000 tools across 300 domains. A plausible implication is that graph-enhanced planning methods such as GTool and simulation layers such as GTM could be complementary in larger agent-training pipelines, but such a combination is not claimed by either paper (Ren et al., 4 Dec 2025). The title overlap with “GraphTool-Instruction” and its GTools dataset should also be treated carefully: that work concerns decomposed subtask instruction for graph reasoning tasks and an associated graph reasoning dataset, not incomplete-dependency tool planning for LLM agents (Wang et al., 2024).

In that broader landscape, GTool occupies a narrow but well-defined layer: request-conditioned structural planning over partially observed tool dependencies. Its contribution is not synthetic data generation, not tool simulation, not workflow evaluation, and not generic tool grounding in the GEAR sense, but a graph-based interface that injects dependency information into frozen LLMs through a learned <graph token> (Chen et al., 18 Aug 2025).