Paper deep dive
UniToolCall: Unifying Tool-Use Representation, Data, and Evaluation for LLM Agents
Yijuan Liang, Xinghao Chen, Yifan Ge, Ziyi Wu, Hao Wu, Changyu Zeng, Wei Xing, Xiaoyu Shen
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 96%
Last extracted: 4/14/2026, 2:36:30 AM
Summary
UniToolCall is a unified framework for LLM agent tool learning that addresses fragmentation in tool-use representation, data, and evaluation. It introduces a standardized Query-Action-Observation-Answer (QAOA) representation, a large-scale tool pool of 22k+ tools, and a hybrid training corpus of 390k+ instances. The framework features a synthetic data generation pipeline with an Anchor Linkage mechanism for multi-turn dependencies and supports fine-grained evaluation across function-call, turn, and conversation levels. Fine-tuning Qwen3-8B on this framework achieves state-of-the-art performance, notably reaching 93.0% single-turn Strict Precision in distractor-heavy settings.
Entities (5)
Relation Signals (3)
UniToolCall → uses → QAOA
confidence 100% · We convert 7 public benchmarks into a unified Query--Action--Observation--Answer (QAOA) representation
UniToolCall → improves → Qwen3-8B
confidence 95% · Experiments show that fine-tuning Qwen3-8B on our dataset substantially improves tool-use performance.
UniToolCall → includes → Anchor Linkage
confidence 95% · To support coherent multi-turn reasoning, we further introduce an Anchor Linkage mechanism
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Tool-use capability is a fundamental component of LLM agents, enabling them to interact with external systems through structured function calls. However, existing research exhibits inconsistent interaction representations, largely overlooks the structural distribution of tool-use trajectories, and relies on incompatible evaluation benchmarks. We present UniToolCall, a unified framework for tool learning that standardizes the entire pipeline from toolset construction and dataset generation to evaluation. The framework curates a large tool pool of 22k+ tools and constructs a hybrid training corpus of 390k+ instances by combining 10 standardized public datasets with structurally controlled synthetic trajectories. It explicitly models diverse interaction patterns, including single-hop vs. multi-hop and single-turn vs. multi-turn, while capturing both serial and parallel execution structures. To support coherent multi-turn reasoning, we further introduce an Anchor Linkage mechanism that enforces cross-turn dependencies. Furthermore, we convert 7 public benchmarks into a unified Query--Action--Observation--Answer (QAOA) representation with fine-grained evaluation at the function-call, turn, and conversation levels. Experiments show that fine-tuning Qwen3-8B on our dataset substantially improves tool-use performance. Under the distractor-heavy Hybrid-20 setting, achieves 93.0% single-turn Strict Precision, outperforming commercial models including GPT, Gemini, and Claude.
Tags
Links
- Source: https://arxiv.org/abs/2604.11557v1
- Canonical: https://arxiv.org/abs/2604.11557v1
Trouble viewing inline? Open PDF directly →
Full Text
72,709 characters extracted from source content.
Expand or collapse full text
UniToolCall: Unifying Tool-Use Representation, Data, and Evaluation for LLM Agents Yijuan Liang 1,2 , Xinghao Chen 2,3 , Yifan Ge 2 , Ziyi Wu 2 , Hao Wu 2 , Changyu Zeng 2 Wei Xing 2 , Xiaoyu Shen 2 * 1 University of Science and Technology of China 2 Ningbo Institute of Digital Twin, Eastern Institute of Technology, Ningbo 3 Department of Computing, The Hong Kong Polytechnic University xyshen@eitech.edu.cn Abstract Tool-use capability is a fundamental compo- nent of LLM agents, enabling them to interact with external systems through structured func- tion calls. However, existing research exhibits inconsistent interaction representations, largely overlooks the structural distribution of tool-use trajectories, and relies on incompatible evalu- ation benchmarks. We present UniToolCall, a unified framework for tool learning that stan- dardizes the entire pipeline from toolset con- struction and dataset generation to evaluation. The framework curates a large tool pool of 22k+ tools and constructs a hybrid training corpus of 390k+ instances by combining 10 standard- ized public datasets with structurally controlled synthetic trajectories. It explicitly models di- verse interaction patterns, including single-hop vs. multi-hop and single-turn vs. multi-turn, while capturing both serial and parallel exe- cution structures. To support coherent multi- turn reasoning, we further introduce an Anchor Linkage mechanism that enforces cross-turn dependencies. Furthermore, we convert 7 pub- lic benchmarks into a unified Query–Action– Observation–Answer (QAOA) representation with fine-grained evaluation at the function- call, turn, and conversation levels. Experiments show that fine-tuning Qwen3-8B on our dataset substantially improves tool-use performance. Under the distractor-heavy Hybrid-20 setting, UniToolCall achieves 93.0% single-turn Strict Precision, outperforming commercial models including GPT, Gemini, and Claude. 1 1 Introduction The emergence of LLM agents marks a shift from passive text generation to goal-directed interaction with external environments (Durante et al., 2024; Luo et al., 2025a; Sapkota et al., 2026). A key capability underlying this shift is tool use, which * Corresponding Author 1 https://github.com/EIT-NLP/UniToolCall. Figure 1: Existing datasets are severely limited by the fragmentation problem. To address these challenges, UniToolCall introduces a standardized framework that provides robust structural constraints, yielding SOTA over strong baselines. enables agents to take actions by translating natu- ral language instructions into executable function calls. Through tool use, LLM agents can access external knowledge, invoke APIs, and perform multi-step operations, extending their capabilities beyond parametric knowledge (Schick et al., 2023; Yu et al., 2025). Consequently, an agent’s effec- tiveness largely depends on its ability to select, compose, and execute tools reliably, making tool learning a central problem in agent research (Pa- prunia et al., 2025; Lu et al., 2026). In the current data-driven paradigm, progress in tool learning is largely determined by the availabil- ity and quality of training data, particularly tool-use trajectories that capture how agents interact with external environments. Early efforts such as Tool- LLM (Qin et al., 2024), ToolBench (Patil et al., 2024), and API-Bank (Li et al., 2023) construct such data by executing real-world APIs. While providing realistic supervision signals, they suffer from limited scalability and instability due to their arXiv:2604.11557v1 [cs.AI] 13 Apr 2026 reliance on external systems. To address these limi- tations, more recent works have shifted toward syn- thetic data generation, building simulated tool envi- ronments and automatically generating interaction trajectories (e.g., ToolForge (Chen et al., 2025b), LoopTool (Zhang et al., 2025), ASTRA (Tian et al., 2026)). In parallel, a number of benchmarks have been proposed to evaluate tool-use capabil- ity, including ComplexFuncBench (Zhong et al., 2025), HammerBench (Wang et al., 2024), and ACEBench (Chen et al., 2025a). Despite this progress, existing efforts are largely developed in isolation, leading to a fundamen- tal fragmentation problem in tool learning. This fragmentation manifests along three key dimen- sions. First, representation inconsistency: different datasets adopt incompatible schemas to encode tool calls, arguments, and observations, making joint training across sources difficult. Second, structural under-modeling: current pipelines largely overlook the diversity of execution structures, particularly the distinction between serial and parallel tool in- vocation patterns. Third, evaluation mismatch: ex- isting benchmarks rely on disparate protocols, tool definitions, and evaluation scripts, preventing fair and reproducible cross-dataset comparisons. To- gether, these issues hinder both scalable training and systematic evaluation of tool-use capabilities. To address these limitations, we propose Uni- ToolCall, a unified framework for tool learning that standardizes the entire pipeline from toolset con- struction and data generation to evaluation under a shared representation. We first curate a large- scale tool pool by aggregating tools from mul- tiple sources, resulting in a filtered set of over 22K tools. Building on this, we construct a hy- brid training corpus that combines standardized public datasets with structurally controlled syn- thetic trajectories, yielding 390K instances span- ning single-hop, multi-hop, single-turn, and multi- turn interactions. Crucially, our synthetic pipeline explicitly models both serial and parallel execution structures, enabling fine-grained analysis of exe- cution patterns. Finally, we unify all data into a Query–Action–Observation–Answer (QAOA) rep- resentation 2 and introduce a standardized evalua- tion protocol with comprehensive metrics, enabling consistent and fair comparison across diverse set- tings. Our contributions are as follows: •Structurally-Aware data generation We pro- 2 A single-hop sample is shown in Appendix C.2. pose a synthetic data generation pipeline that provides controlled supervision for single/multi-hop and single/multi-turn inter- actions. The pipeline explicitly models both serial and parallel execution patterns and in- troduces an Anchor Linkage mechanism to enforce cross-turn dependencies. •A standardized unified benchmark We con- vert heterogeneous public benchmarks into a unified QAOA format with shared match- ing rules and metrics, enabling fine-grained evaluation across function-call, turn, and con- versation levels and fair comparison across diverse task structures. •Strong empirical Performance Fine-tuning a lightweight QWEN3-8B model on our frame- work achieves state-of-the-art results. Under the distractor-heavy Hybrid-20 setting, Uni- ToolCall attains 93.0% single-turn Strict Preci- sion, outperforming leading commercial mod- els including GPT, Gemini, and Claude. 2 Related work Synthetic data generation Early work (Tang et al., 2023) generates instruction-style tool-use examples to teach basic API usage. Subsequent pipelines further automate dataset construction (Liu et al., 2024; Chen et al., 2025b; Zhang et al., 2025), synthesizing tool-use trajectories at larger scale. Despite this, most generated trajectories tend to follow relatively simple interaction patterns. More- over, the balance between serial and parallel tool execution is rarely considered. In contrast, our syn- thetic pipeline explicitly models structural diversity by considering both serial and parallel execution patterns across four interaction structures. Tool-use benchmarksSome studies rely on real environments (Qin et al., 2024; Wang et al., 2025; Gao et al., 2025), where models interact with ex- ternal tools through actual execution. To improve reproducibility, several benchmarks evaluate tool usage through simulated invocation while retaining real tool definitions (Chen et al., 2025a; Moon et al., 2024). However, these benchmarks adopt hetero- geneous schemas, evaluation rules, and task struc- tures, which hinder fair comparison. To address these limitations, we construct a unified bench- mark that evaluates heterogeneous datasets under a shared QAOA representation, enabling multi- granularity evaluation and providing a more com- prehensive assessment of tool learning. Toolset Construction Constructed Datasets Academic Benchmark MCP Servers s Multi-Stage Filtering Exact Deduplication Schema Validation Semantic Deduplication Tool Pool 3. Category Diversity: 6 categorie 1. Large-Scale: 22k+ tools 2. Domain Diversity: 13 domins s Unified Data Synthesis EngineStructural Integration Validated Syntheic Data Cleaned Public Data Query Find a flight to Beijing. Action SearchFlights (dest='NRT') Observation Flight found: [JL123] Answer I found flight JL123 to Beijing QAOA Formatting Unidied Dataset Gold-anchored Hybrid Sampling 20 Candidate Target Tools n Tools in Total System Prompt Turn-Level Trajectory (Cross-Turn Dialogues) Tool PoolSamplingChonsen Tools LLM Dual-path Planning Hop-Level Trajectory (Parallel & Serial) Self-Evaluation Rubric Validated Syntheic Data Evaluation Protocol Query Trajectory Matching Criteria GranularityUnified Metrics Figure 2: The overall architecture of UniToolCall, comprising several interconnected modules: (1) Toolset construc- tion; (2) Unified data synthesis engine; (3) Structural integration; (4) Evaluation protocol. 3 UniToolCall In this section, we present UniToolCall, a unified framework for tool learning. At the core of our framework is a standardized QAOA representa- tion, which provides a consistent format for mod- eling tool interactions across datasets. As illus- trated in Figure 2, the framework consists of three components: a curated toolset, a data generation pipeline, and a structural assembly stage. In ad- dition, we introduce a unified benchmark to enable consistent evaluation across tool-use scenarios. 3.1 Toolset construction To serve as the candidate pool for dataset con- struction, we construct a comprehensive toolset after applying the multi-stage filtering mechanism (Appendix A.3), denoted asT. As illustrated in Figure 7, the toolset is formed from three pri- mary sources: (1) Academic benchmarks, (2) MCP servers, and (3) Constructed datasets. All tools are standardized into a unified JSON Schema format. To facilitate semantic organization and balanced sampling during data generation, we categorize tools along two dimensions: functional category and application domain. Based on common API usage patterns in agent systems, we define 6 func- tional categories (e.g., visualization, analysis) to capture the operational roles of tools and 13 ap- plication domains (e.g., finance, technology) to represent typical real-world usage scenarios. 3 3 The details, complete taxonomy and category definitions are provided in Appendix A.1 and A.2. 3.2 Training dataset construction Source To equip the agent with robust tool-use and planning capabilities, we construct a large- scale hybrid training dataset, denoted asD train . The dataset is composed of two parts: (1) Public data integration (D pub ) We collected and integrated 10 distinct tool-use datasets 4 . To ensure validity and reliability, we implemented a two-stage filtering strategy applied before and after format conver- sion (Appendix A.4). (2) Synthetic augmentation (D syn ) To overcome the structural shallowness in- herent in public corpora, we construct a synthetic datasetD syn based on the toolsetT. In particu- lar, the pipeline controls both execution patterns (serial vs. parallel tool invocation) and interac- tion complexities (single-hop, multi-hop, single- turn, and multi-turn scenarios).D syn is filtered using an LLM-based self-evaluation framework us- ing six core metrics (e.g., Tool-fit, Success), plus an additional anchor-linkage metric for multi-turn episodes (Appendix A.5). Unified synthetic data pipelineWe design a uni- fied generative framework equipped with stringent quality control. Formally, the construction of any synthetic subsetD x ∈ D sh ,D mh ,D mt is gener- alized as follows: D x = Ψ(τ,P sys ,L cand )| S ⊆T ,τ ∼M(S), Φ eval (τ ) = 1 whereSis a sampled subset from the filtered tool poolT,τrepresents the raw interaction trajectory 4 Table 5 provides detailed statistics for each dataset. Figure 3: Detailed illustration of our synthetic trajec- tory generation pipelines. The single-turn pipeline en- compasses both fundamental single-hop invocations (K = 1) and complex multi-hop scenarios (K ≥ 2), which are further categorized into parallel and serial execution strategies. The multi-turn pipeline extends the interaction to long-horizon conversational settings, explicitly enforcing strict cross-turn state dependencies via Anchor Linkage mechanism. generated by the LLMM, andΦ eval acts as the heuristic self-evaluation gate. Across all scenarios, the structural assembly functionΨstandardizes the validated trajectories into our QAOA format. Crucially,Ψconstructs the candidate listL cand us- ing a uniform Hybrid-20 setting: retaining the ground-truth tools fromSas anchors, retrieving top-ranking hard negatives via embedding similar- ity, and appending 5 random easy negatives to yield exactly 20 candidates (Esfandiarpoor et al., 2026). Finally, a system promptP sys (Appendix C.2) de- tailing tool-use constraints is injected. While shar- ing this core formulation, the specific definitions of the tool subsetSand the trajectoryτdiverge to target distinct agentic capabilities: Single-Hop (D sh )Focuses on fundamental invo- cation mapping. We sample a single tool (|S| = 1), and the modelMdeterministically generates a one- step trajectoryτ =⟨q,a,o,r⟩based strictly on the tool’s schema, whereq,a,o, andrdenote Query, Action, Observation, and Answer, respectively. Multi-Hop (D mh )Trains the agent to coordinate sequences of tool calls. We sample a domain- constrained subsetS(|S| ∈ 2,..., 5). The tra- jectory extends toKsteps (K ≥ 2). Crucial distinction: We explicitly control the execution routing. For serial instances,Mgenerates steps iteratively, constraining subsequent turns to refer- ence concrete values from earlier observations to form genuine inter-step dependencies. For par- allel instances, the queryqand all tool calls are synchronized in a one-shot generation to prevent intention-tool mismatches. Multi-Turn (D mt )Models long-horizon, stateful interactions acrossT ∈ 2, 3, 4dialogue turns. We sample a usage-balanced subsetS(|S| = 10). Generation requires a Two-Stage planning mech- anism (episode-level storyline followed by turn- level intent). Furthermore, to address the disjointed context shifts common in existing datasets (Ma et al., 2024), we introduce explicit Anchor Link- age: a strict adjacent-turn constraint ensuring that the user query at turntdeterministically inherits state variables (e.g., transaction IDs) generated by the tool observations at t− 1. 3.3 Evaluation protocol To evaluate model performance across complex tool-use scenarios, we construct a unified bench- markD test . This unified benchmark focuses on two fundamental capabilities of tool-use agents: accurate tool selection and correct parameter gener- ation. We convert all raw data into the standardized QAOA framework. This standardization enables fairer comparison by applying a unified set of evalu- ation metrics across all datasets. Agent interactions exhibit a hierarchical structure: a full conversation consists of multiple turns, and each turn contains one or more individual function calls. To accurately capture performance across these nested levels, we decouple our evaluation logic into the following granularities: Function call-level verificationAt the most fun- damental level, the validity of each individual tool invocation is assessed by matching the predicted tool name and generated arguments against the ground truth. This call-level correctness serves as the computational basis for calculating propor- tional scores in flexible metrics. Turn & Conversation-level aggregation To evaluate task-level capabilities, the aforementioned call-level results are aggregated at higher dimen- sions, denoted byN. We explicitly map the ag- gregation granularity to the specific type of task complexity being assessed: (1) Turn-level: For single/multi-hop scenarios, we compute metrics across individual dialogue turns. (2) Conversation- level: For single/multi-turn scenarios, we compute metrics across the entire dialogue trajectory. Dur- ing aggregation, Strict metrics employ an all-or- nothing penalty (the instance scores 0 if any func- tion call is flawed), whereas Flexible metrics award credit based on the ratio of correct function calls within the instance. These instance scores are sub- sequently macro-averaged across the dataset. Matching criteria At the Function Call-level, we employ a cascaded strategy to determine the validity of a predicted function call: (1) Rule- based matching: Serving as the primary strategy, this method achieves exact matching through rig- orous standardization 5 . A match is confirmed if the standardized prediction aligns perfectly with the ground truth. (2) Semantic matching: We calculate the ROUGE-L similarity score between the prediction and the reference. A prediction is deemed a semantic match if the score is≥ 0.7. 4 Experiments 4.1 Experimental setup Models and training data We instantiate Uni- ToolCall on the open-source backbone Qwen3- 8B (Yang et al., 2025). The model is fine-tuned on our comprehensive datasetD train , which con- tains 390,060 instances grounded in our tool pool Tof 22,606 tools. Specifically, this consists of 387,123 high-quality conversations retained from the standardized public corpus (D pub ), and 2,937 synthetic trajectories (D syn ). The synthetic sub- set is generated and rigorously self-evaluated by Qwen3-32B (Yang et al., 2025), comprising 979 instances each for single-hop, multi-hop, and multi- turn scenarios respectively. Implementation detailsWe employ the LLaMA- Factory framework integrated with DeepSpeed op- timization to fine-tune the base model. Training is conducted with LoRA (Hu et al., 2022). We target all linear modules with rankr = 8and scaling factorα = 16. The model is trained for 1 epoch using AdamW with a learning rate of1× 10 −5 and a warmup ratio of0.03. The maximum sequence length is set to 8192 tokens. The effective batch size is 8. We use bfloat16 precision throughout training. All experiments are conducted on a single node with 4×NVIDIA A800-SXM4 GPUs (40GB each) and an Intel Xeon Platinum 8378A CPU. Baselines We compare UniToolCall against six strong LLM baselines.To improve inference efficiency, we standardize the inference setup by disabling explicit reasoning traces when sup- ported (e.g.,<think>style outputs). Our fine- tuned Qwen3-8B is trained and evaluated in 5 Refer to Appendix B.2 for the detailed rules. an enable-thinking=false setting, and DeepSeek- V3.2 (DeepSeek-AI et al., 2025), Qwen3- 32B (Yang et al., 2025), and Claude 4.6 Son- net (Anthropic, 2026) are evaluated with reasoning disabled also through the available API options. For other proprietary models, we use their non- reasoning or efficiency-oriented variants, includ- ing GPT-5.2 Instant (OpenAI, 2025) and Gemini 3 Flash Preview (Google, 2025). Evaluation settingsOur main evaluation is con- ducted under the Hybrid-20 setting mentioned in Section 3.2. We additionally report results under the Ground Truth (GT) setting, in which the can- didate list contains only the required target tools. The main result tables report a single representative run for each model. To characterize training stabil- ity, we further report multi-run summary statistics for UniToolCall and the vanilla Qwen3-8B in Ap- pendix C.1 for reference. The unified evaluationD test mentioned in Sec- tion 3.3 comprises 7 public benchmarks, yielding 6,163 high-quality conversations after filtering (Ta- ble 5). Based on this evaluation protocol, we define four macro-averaged quantitative metrics. We first introduce three indicator functions for a predicted function callpwithin an instance’s prediction set P i (Missed cases will be filled with null), evaluated against the ground truth set G i : • m n (p) : Returns 1 ifphas a correctly match- ing tool name in G i ; otherwise 0. • m s (p): Returns 1 ifpstrictly matches a call in G i in both name and all argument values. • m f (p): Returns 1 ifpmatches the tool name and satisfies the semantic similarity threshold for arguments. Note: Under-predicted calls inP i are padded with null to penalize omissions, directly yielding a score of 0 when no tools are invoked (|P i | = 0). Strict Precision (SP)This metric establishes the rigorous lower bound for tool selection. An in- stance scores 1 if and only if every predicted tool name perfectly matches the ground truth: SP = 1 N P N i=1 1 |P i | =|G i |∧∀p∈ P i ,m n (p) = 1 Flexible Precision (FP)As a tolerant tool selec- tion metric, this macro-averaged precision calcu- lates the proportion of correctly named tools: FP = 1 N P N i=1 1 |P i | P p∈P i m n (p) Strict Parameter Accuracy (SPA) This metric assesses the exactness of argument generation. The denominator is the total number of predicted calls (|P i |). A prediction only contributes to the score if both its name and arguments are perfectly correct: SPA = 1 N P N i=1 1 |P i | P p∈P i m s (p) Flexible Parameter Accuracy (FPA) This met- ric measures the proportion of predicted tools that pass argument matching: either exact rule-based matching or ROUGE-L similarity: FPA = 1 N P N i=1 1 |P i | P p∈P i m f (p) 4.2 Main results Tables 1 summarizes the overall performance of UniToolCall and the baselines under the Hybrid-20 setting. We highlight three main observations. Strong gains in tool selection As shown in Figure 4, UniToolCall achieves the best strict tool-selection performance in both single-hop and single-turn settings, reaching SP scores of 92.9% and 93.0%, respectively. These results substan- tially improve over the vanilla Qwen3-8B and also exceed stronger open-source and proprietary base- lines such as Qwen3-32B and Gemini 3 Flash Pre- view. In multi-hop settings, UniToolCall obtains the second-best SP (80.7%) and FP (89.6%), while remaining close to Claude 4.6 Sonnet on strict se- lection. This suggests that our framework is particu- larly effective at improving precise tool localization under distractor-heavy retrieval conditions. Improved parameter grounding Beyond tool selection, UniToolCall also improves parameter generation quality. In the single-turn setting, it achieves the best SPA and FPA across all compared models. In multi-turn scenarios, UniToolCall im- proves FP and parameter-level metrics compared to the vanilla backbone, although strict conversation- level matching remains challenging for all models due to the long-horizon nature of the task. Comparison to the GT setting The GT setting removes distractor tools and therefore serves as a useful reference point for analyzing retrieval diffi- culty. In single-hop evaluation, UniToolCall under Hybrid-20 approaches the vanilla model’s GT per- formance. In single-turn and multi-hop settings, the fine-tuned model even surpasses the vanilla model evaluated in the GT condition, suggesting that the gains are not limited to distractor resistance alone, but also reflect improved intrinsic capability in structured tool-use prediction. 4.3 Ablations Our synthetic pipeline is designed to provide struc- turally controlled supervision rather than to replace the scale and domain breadth of large public cor- pora. We conduct ablations from two distinct per- spectives: downstream model training and intrin- sic data quality. To evaluate downstream training efficacy, we investigate two design questions un- der a matched data budget (N = 979): (1) how the structural profile of pipeline-generated data differs from that of collected public corpora, and (2) whether mixing different structural complex- ities is beneficial within synthetic training. To ensure a comprehensive assessment, Table 2 re- ports the macro-averaged results across our unified benchmark. Furthermore, to continuously observe performance dynamics under varying execution structures, we conduct a targeted evaluation on the BFCL v3 (Patil et al., 2025) subset (Figure 5). BFCL v3 was selected due to its sufficient volume of multi-hop instances, allowing us to dynamically control parallel-to-serial ratios via stratified ran- dom sampling. Separately, to validate the genera- tion mechanism itself, we address a third question: (3) the efficacy of explicit state-tracking constraints. We explore this by directly assessing the intrinsic quality of synthesized multi-turn trajectories with and without our Anchor Linkage mechanism. Ablation I: Structural profile of public vs. syn- thetic data Evaluated globally across the entire benchmark (Table 2), the public subset naturally achieves strong overall scores due to its broad lin- guistic and domain coverage. However, its inherent serial-to-parallel ratio is severely skewed (1:5.69), indicating a dominance of flatter, independent invo- cation patterns. In contrast, our synthetic pipeline explicitly injects denser sequential dependencies (1:1.91). We isolate the impact of this structural bias using the BFCL v3 fine-grained analysis in Figure 5. As the proportion of parallel tasks in- creases (x-axis), all evaluation scores artificially inflate, confirming that serial dependencies are in- herently more challenging. Crucially, the com- parative advantage between synthetic and public data dynamically shifts across this spectrum. In heavily sequential scenarios, the Synthetic Mixed data demonstrates clear superiority over the Public Models SP (%)↑FP (%)↑SPA (%)↑FPA (%)↑ SHMHSTMTSHMHSTMTSHMHSTMTSHMHSTMT GT Setting Qwen3-8B (Upper Bound)96.1 47.5 92.6 0.096.1 76.4 95.5 39.528.7 57.2 32.1 18.852.3 70.0 54.9 24.9 Hybrid-20 Setting Proprietary Models GPT-5.2 Instant50.9 39.0 50.5 0.050.9 58.2 52.5 16.123.2 49.1 26.3 9.139.2 55.3 41.59.8 Gemini 3 Flash Preview68.3 77.2 70.3 0.068.3 83.6 70.9 22.525.2 69.3 30.3 14.246.378.5 50.515.6 Claude 4.6 Sonnet58.8 83.3 62.1 0.058.8 89.6 62.7 34.824.9 74.1 30.319.443.1 84.1 47.9 25.2 Open-Source Models Kimi-K2-Instruct55.9 75.9 58.7 0.055.9 86.1 59.7 31.121.3 69.626.5 18.437.1 80.142.0 24.9 DeepSeek-V3.246.9 39.7 47.0 0.046.9 65.3 49.6 15.018.8 54.3 22.9 10.332.8 60.9 36.3 13.0 Qwen3-32B72.664.0 72.78.372.679.9 74.338.223.7 61.3 27.9 21.643.8 72.9 47.4 28.8 Qwen3-8B (Vanilla)66.9 22.7 63.3 0.066.9 53.9 66.5 25.819.8 38.1 22.1 12.119.8 38.1 22.1 12.1 UniToolCall (Ours) 92.9 ↑ 26.0 80.7 ↑ 58.0 93.0 ↑ 29.7 0.0 ↓ 0.0 92.9 ↑ 26.0 89.6 ↑ 35.7 93.8 ↑ 27.3 39.4 ↑ 13.6 27.1 ↑ 7.3 66.6 ↑ 28.5 31.6 ↑ 9.5 21.2 ↑ 9.1 48.6 ↑ 28.8 78.8 ↑ 40.7 52.4 ↑ 30.3 26.1 ↑ 14.0 Table 1: Comprehensive evaluation results across varying tool-use complexities. SH, MH, ST, and MT denote Single-Hop, Multi-Hop, Single-Turn, and Multi-Turn scenarios, respectively. All reported metrics are scaled to percentages (%). The best results are bolded and the second best results are underlined in all following tables. Figure 4: Performance breakdown of UniToolCall across the 7 sub-datasets in our unified evaluation benchmark D test . For each benchmark, we report both hop-level (left) and turn-level (right) results using the unified metrics introduced in Section 3.3. Mixed baseline across metrics. This indicates that our pipeline’s explicit constraint modeling effec- tively tackles deep inter-step dependencies. Con- versely, as the parallel proportion rises, the Public Mixed baseline gradually catches up, benefiting from its inherent abundance of flat, independent invocations. This dynamic complementarity proves that while public data provides a robust baseline for parallel tasks through massive domain exposure, synthetic data is an indispensable supplement for injecting precise, controllable sequential reasoning. Ablation I: Mixing structural complexities within synthetic data We next zoom into the synthetic pipeline to compare pure homogeneous datasets against the mixed configuration. On the global benchmark (Table 2), while all synthetic variants improve over the vanilla model, task- specific concentration only benefits in-domain met- rics (e.g., pure multi-turn yields the strongest multi- turn FP but suboptimal multi-hop SP). The neces- sity of a mixed curriculum is visually corroborated in our targeted BFCL v3 analysis (Figure 5). In the highly challenging sequential and balanced regions (low to medium x-axis values), the Synthetic Mixed setting maintains a strong upper bound among all synthetic variants. While homogeneous datasets like Pure Multi-Hop can perform competitively in highly parallel scenarios, they exhibit noticeable degradation when strict sequential logic is required. Meanwhile, Pure Single-Hop consistently lags be- hind across the entire spectrum. This demonstrates that specializing in a single interaction pattern lim- its generalization. Combining simpler extraction tasks with complex sequential routing creates a positive knowledge transfer, providing the most robust and balanced performance across varying reasoning complexities. Figure 5: Performance trends across different data compositions under varying parallel-to-serial ratios. Method MH RatioMHMT (Ser:Par) SP (%)↑ SPA (%)↑FP (%)↑ Vanilla Qwen3-8B-22.738.125.8 Ablation I: Public vs. Synthetic under matched budget Synthetic Mixed1 : 1.957.156.839.6 Public Mixed1 : 5.759.758.247.9 Ablation I: Synthetic-only comparison (Homogeneous vs. Mixed) Pure Single-hop-51.954.938.5 Pure Multi-hop1 : 1.353.455.642.1 Pure Multi-turn1 : 0.954.356.444.4 Synthetic Mixed1 : 1.957.156.839.6 Table 2: Controlled analysis under a matched data bud- get (N = 979). MH Ratio denotes the proportion of serial to parallel multi-hop trajectories. Both Mixed datasets are constructed by proportionally sampling from their respective structural subsets. Ablation I: Efficacy of the Anchor Linkage Mechanism We randomly sampled 10 multi- turn samples generated with the Anchor Link- age constraint and 10 generated without it, which were evaluated using our LLM-based rubric (Ap- pendix A.5). As illustrated in the radar chart (Fig- ure 6), removing the anchor mechanism leads to a substantial performance drop on the specific An- chor dimension. This confirms that without ex- plicit constraints, generative models struggle to produce later turns that consistently and function- ally reference preceding states. Consequently, this lack of cross-turn continuity negatively impacts the Query Evaluation dimensions. Conversely, the un- constrained baseline yields slightly higher scores in Trajectory Evaluation metrics. This dynamic reflects a natural structural trade-off: when multi- turn episodes lack strict inter-turn dependencies, they tend to degenerate into a series of decoupled, simpler single-turn interactions. Ultimately, these results demonstrate that the Anchor Linkage mech- anism is indispensable for synthesizing genuinely coherent, complex multi-turn datasets. Tool-fit Δ-0.17 Clarity Δ-0.25 Naturalness Δ-0.19 Success Δ+0.03 Grounding Δ+0.16 Efficiency Δ+0.21 Anchor Δ-0.85 Total Δ-0.20 8.0 8.5 9.0 9.5 10.0 With AnchorWithout Anchor Figure 6: Intrinsic data quality evaluation for the An- chor Linkage mechanism. Deltas (∆) indicate the score reduction or increase when the mechanism is removed. 5 Conclusion In this paper, we presented UniToolCall, a unified framework for tool learning in LLM agents. Our framework standardizes the entire pipeline from toolset construction and hybrid data synthesis to evaluation under a shared QAOA representation. By integrating large-scale public corpora with struc- turally controlled synthetic trajectories, the result- ing training dataset contains 390k+ instances cov- ering diverse interaction patterns, including single- hop, multi-hop, single-turn and multi-turn scenar- ios with both serial and parallel execution struc- tures. In addition, we construct a unified bench- mark that enables fine-grained evaluation across function-call, turn, and conversation levels. Exper- iments show that models trained with our frame- work achieve strong improvements in tool selection and parameter generation, highlighting the impor- tance of explicitly modeling structural diversity in tool-use data. In future work, we plan to extend the framework to longer-horizon agent interactions and further evaluate it in real-world environments with live tool execution. Limitations Due to computational constraints, our experiments were conducted with a maximum context length of 8192 tokens, which restricts our exploration of extremely long-horizon interactions or scenarios in- volving large tool outputs (e.g., lengthy documents or database results). Second, our experiments pri- marily focus on a lightweight backbone (Qwen3- 8B). While the framework significantly improves its performance and even surpasses several larger models, we did not systematically investigate scal- ing behavior on larger backbones (e.g., 30B+ or 70B+ models). Finally, there is a potential risk of evaluation distortion introduced by our rigor- ous data filtering and format conversion processes. Because our methodology relies on standardizing highly heterogeneous datasets into a unified bench- mark, readers should be aware that the final evalua- tion results may not fully preserve all original task attributes or idiosyncratic features of the source benchmarks. Ethics Statement For the integration of public data, we exclusively utilized open-source datasets that have been previ- ously released under permissive licenses. During the synthetic data generation process, our prompt- ing mechanisms and LLM-based planners were ex- plicitly instructed to simulate fictitious user intents and generic business scenarios. We confirm that no personally identifiable information or sensitive user data was scraped, generated, or included in our final dataset. Furthermore, while our data synthe- sis relies on LLMs, which may inherently reflect societal biases, our multi-stage quality filtering and strict argument-grounding rubrics significantly mit- igate the risk of generating unsafe or hallucinated content. All scientific artifacts, including base mod- els and MCP server definitions, were used strictly in accordance with their intended purposes and li- censes. Therefore, we believe that our research complies with the ACL Code of Ethics. We used ChatGPT and Gemini for minor language polish- ing and grammar correction. All technical content, experiments, and conclusions were generated and verified by the authors. References Mayank Agarwal, Ibrahim Abdelaziz, Kinjal Basu, Merve Unuvar, Luis A. Lastras, Yara Rizk, and Pa- van Kapanipathi. 2025. Toolrm: Outcome reward models for tool-calling large language models. arXiv preprint arXiv:2509.11963. Anthropic. 2026. Claude 4.6 sonnet.https://w. anthropic.com/news/claude-sonnet-4-6. Chen Chen, Xinlong Hao, Weiwen Liu, Xu Huang, Xingshan Zeng, Shuai Yu, Dexun Li, Yuefeng Huang, Xiangcheng Liu, Xinzhi Wang, and Wu Liu. 2025a. ACEBench: A comprehensive evaluation of LLM tool usage. In Findings of the Association for Com- putational Linguistics: EMNLP 2025, pages 12970– 12998, Suzhou, China. Association for Computa- tional Linguistics. Hao Chen, Zhexin Hu, Jiajun Chai, Haocheng Yang, Hang He, Xiaohan Wang, Wei Lin, Luhang Wang, Guojun Yin, and Zhuofeng Zhao. 2025b.Tool- forge: A data synthesis pipeline for multi-hop search without real-world apis.arXiv preprint arXiv:2512.16149. DeepSeek-AI, Aixin Liu, Aoxue Mei, Bangcai Lin, Bing Xue, Bingxuan Wang, Bingzheng Xu, Bochao Wu, Bowei Zhang, Chaofan Lin, Chen Dong, Chengda Lu, Chenggang Zhao, Chengqi Deng, Chen- hao Xu, Chong Ruan, Damai Dai, Daya Guo, Dejian Yang, Deli Chen, Erhang Li, Fangqi Zhou, Fangyun Lin, Fucong Dai, Guangbo Hao, Guanting Chen, Guowei Li, H. Zhang, Hanwei Xu, Hao Li, Haofen Liang, Haoran Wei, Haowei Zhang, Haowen Luo, Haozhe Ji, Honghui Ding, Hongxuan Tang, Huangqi Cao, Huazuo Gao, Hui Qu, Hui Zeng, Jialiang Huang, Jiashi Li, Jiayin Xu, Jiewen Hu, Jingchang Chen, Jingting Xiang, Jingyang Yuan, Jingyuan Cheng, Jin- hua Zhu, Jun Ran, Junguang Jiang, Junjie Qiu, Jun- long Li, Junxiao Song, Kai Dong, Kaige Gao, Kang Guan, Kexin Huang, Kexing Zhou, Kezhao Huang, Kuai Yu, Lean Wang, Lecong Zhang, Lei Wang, Liang Zhao, Liangsheng Yin, Lihua Guo, Lingx- iao Luo, Linwang Ma, Litong Wang, Liyue Zhang, M.S. Di, M.Y. Xu, Mingchuan Zhang, Minghua Zhang, Minghui Tang, Mingxu Zhou, Panpan Huang, Peixin Cong, Peiyi Wang, Qiancheng Wang, Qihao Zhu, Qingyang Li, Qinyu Chen, Qiushi Du, Ruiling Xu, Ruiqi Ge, Ruisong Zhang, Ruizhe Pan, Runji Wang, Runqiu Yin, Runxin Xu, Ruomeng Shen, Ruoyu Zhang, S.H. Liu, Shanghao Lu, Shangyan Zhou, Shanshuang Chen, Shaofei Cai, et al. 2025. Deepseek-v3.2: Pushing the frontier of open large language models. arXiv preprint arXiv:2512.02556. Zane Durante, Qiuyuan Huang, Naoki Wake, Ran Gong, Jae Sung Park, Bidipta Sarkar, Rohan Taori, Yusuke Noda, Demetri Terzopoulos, Yejin Choi, Katsushi Ikeuchi, Hoi Vo, Li Fei-Fei, and Jianfeng Gao. 2024. Agent ai: Surveying the horizons of multimodal in- teraction. CoRR, abs/2401.03568. Reza Esfandiarpoor, Vishwas Suryanarayanan, Stephen Bach, Vishal Chowdhary, and Anthony Aue. 2026. TheMCPCompany: Creating general-purpose agents with task-specific tools. Xuanqi Gao, Siyi Xie, Juan Zhai, Shqing Ma, and Chao Shen. 2025. Mcp-radar: A multi-dimensional bench- mark for evaluating tool use capabilities in large lan- guage models. CoRR, abs/2505.16700. Google.2025.Gemini3flash—fron- tier intelligence built for speed.https: //blog.google/products-and-platforms/ products/gemini/gemini-3-flash/. Edward J Hu, Yelong Shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Lu Wang, and Weizhu Chen. 2022. LoRA: Low-rank adaptation of large language models. In International Conference on Learning Representations (ICLR). Interstellar Ninja. 2025. Hermes reasoning tool use dataset.https://huggingface.co/datasets/ interstellarninja/hermes_reasoning_tool_ use. Hugging Face Dataset. Junaidjk.2024.Functioncallingdataset. https://huggingface.co/datasets/Junaidjk/ function_calling. Hugging Face Dataset. Minghao Li, Yingxiu Zhao, Bowen Yu, Feifan Song, Hangyu Li, Haiyang Yu, Zhoujun Li, Fei Huang, and Yongbin Li. 2023. API-bank: A comprehensive benchmark for tool-augmented LLMs. In Proceed- ings of the 2023 Conference on Empirical Methods in Natural Language Processing, pages 3102–3116, Singapore. Association for Computational Linguis- tics. Zuxin Liu, Thai Hoang, Jianguo Zhang, Ming Zhu, Tian Lan, Shirley Kokane, Juntao Tan, Weiran Yao, Zhi- wei Liu, Yihao Feng, Rithesh R. N., Liangwei Yang, Silvio Savarese, Juan Carlos Niebles, Huan Wang, Shelby Heinecke, and Caiming Xiong. 2024. Api- gen: Automated pipeline for generating verifiable and diverse function-calling datasets. In NeurIPS. Xuan Lu, Haohang Huang, Rui Meng, Yaohui Jin, Wen- jun Zeng, and Xiaoyu Shen. 2026. Tools are under- documented: Simple document expansion boosts tool retrieval. In The Fourteenth International Conference on Learning Representations. Junyu Luo, Weizhi Zhang, Ye Yuan, Yusheng Zhao, Jun- wei Yang, Yiyang Gu, Bohan Wu, Binqi Chen, Ziyue Qiao, Qingqing Long, Rongcheng Tu, Xiao Luo, Wei Ju, Zhiping Xiao, Yifan Wang, Meng Xiao, Chenwu Liu, Jingyang Yuan, Shichang Zhang, Yiqiao Jin, Fan Zhang, Xian Wu, Hanqing Zhao, Dacheng Tao, Philip S. Yu, and Ming Zhang. 2025a. Large lan- guage model agent: A survey on methodology, appli- cations and challenges. CoRR, abs/2503.21460. Ziyang Luo, Zhiqi Shen, Wenzhuo Yang, Zirui Zhao, Prathyusha Jwalapuram, Amrita Saha, Doyen Sa- hoo, Silvio Savarese, Caiming Xiong, and Junnan Li. 2025b. MCP-universe: Benchmarking large lan- guage models with real-world model context protocol servers. In Workshop on Scaling Environments for Agents. Chang Ma, Junlei Zhang, Zhihao Zhu, Cheng Yang, Yujiu Yang, Yaohui Jin, Zhenzhong Lan, Lingpeng Kong, and Junxian He. 2024. Agentboard: An ana- lytical evaluation board of multi-turn LLM agents. In The Thirty-eight Conference on Neural Information Processing Systems Datasets and Benchmarks Track. MathAndMagic.2024.Functioncalling dataset.https://huggingface.co/datasets/ MathAndMagic/function-calling. Hugging Face Dataset. MCP.so Team. 2025. Mcp.so: A registry for model con- text protocol servers.https://mcp.so/. Accessed: 2025-11-20. Suhong Moon, Siddharth Jha, Lutfi Eren Erdogan, Se- hoon Kim, Woosang Lim, Kurt Keutzer, and Amir Gholami. 2024. Efficient and scalable estimation of tool representations in vector space.CoRR, abs/2409.02141. OpenAI. 2025. Introducing gpt-5.2.https://openai. com/index/introducing-gpt-5-2/. Dhruvi Paprunia, Vansh Kharidia, and Pankti Doshi. 2025. Advancing slm tool-use capability using rein- forcement learning. Preprint, arXiv:2509.04518. Shishir G Patil, Huanzhi Mao, Fanjia Yan, Char- lie Cheng-Jie Ji, Vishnu Suresh, Ion Stoica, and Joseph E. Gonzalez. 2025. The berkeley function calling leaderboard (BFCL): From tool use to agentic evaluation of large language models. In Forty-second International Conference on Machine Learning. Shishir G Patil, Tianjun Zhang, Xin Wang, et al. 2024. Gorilla: Large language model connected with massive apis. In Advances in Neural Informa- tion Processing Systems (NeurIPS), volume 37, pages 126544–126565. Yujia Qin, Shihao Liang, Yining Ye, Kunlun Zhu, Lan Yan, Yaxi Lu, Yankai Lin, Xin Cong, Xiangru Tang, Bill Qian, Sihan Zhao, Lauren Hong, Runchu Tian, Ruobing Xie, Jie Zhou, Mark Gerstein, dahai li, Zhiyuan Liu, and Maosong Sun. 2024. ToolLLM: Facilitating large language models to master 16000+ real-world APIs. In The Twelfth International Con- ference on Learning Representations. Ranjan Sapkota, Konstantinos I. Roumeliotis, and Manoj Karkee. 2026. Ai agents vs. agentic ai: A conceptual taxonomy, applications and challenges. Information Fusion, 126:103599. Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. 2023. Toolformer: Language models can teach themselves to use tools. CoRR, abs/2302.04761. Zhengliang Shi, Yuhan Wang, Lingyong Yan, Pengjie Ren, Shuaiqiang Wang, Dawei Yin, and Zhaochun Ren. 2025.Retrieval models aren’t tool-savvy: Benchmarking tool retrieval for large language mod- els. In ACL (Findings), pages 24497–24524. Qiaoyu Tang, Ziliang Deng, Hongyu Lin, Xianpei Han, Qiao Liang, and Le Sun. 2023. Toolalpaca: Gener- alized tool learning for language models with 3000 simulated cases. CoRR, abs/2306.05301. Xiaoyu Tian, Haotian Wang, Shuaiting Chen, Hao Zhou, Kaichi Yu, Yudian Zhang, Jade Ouyang, Junxi Yin, Jiong Chen, Baoyan Guo, Lei Zhang, Junjie Tao, Yuansheng Song, Ming Cui, and Chengwei Liu. 2026. Astra: Automated synthesis of agen- tic trajectories and reinforcement arenas. Preprint, arXiv:2601.21558. Vikhrmodels. 2024.Tool plannings v0.2.https: //huggingface.co/datasets/Vikhrmodels/ tool-plannings-v0.2. Hugging Face Dataset. Jun Wang, Jiamu Zhou, Muning Wen, Xiaoyun Mo, Haoyu Zhang, Qiqiang Lin, Cheng Jin, Xihuai Wang, Weinan Zhang, Qiuying Peng, and Jun Wang. 2024. Hammerbench: Fine-grained function-calling eval- uation in real mobile device scenarios.CoRR, abs/2412.16516. Zhenting Wang, Qi Chang, Hemani Patel, Shashank Biju, Cheng-En Wu, Quan Liu, Aolin Ding, Alireza Rezazadeh, Ankit Shah, Yujia Bao, and Eugene Siow. 2025. MCP-bench: Benchmarking tool-using LLM agents with complex real-world tasks via MCP servers. In Workshop on Scaling Environments for Agents. Mengsong Wu, Tong Zhu, Han Han, Chuanyuan Tan, Xiang Zhang, and Wenliang Chen. 2024. Seal-tools: Self-instruct tool learning dataset for agent tuning and detailed benchmark. In NLPCC (2), pages 372– 384. Zhangchen Xu, Adriana Meza Soria, Shawn Tan, Anurag Roy, Ashish Sunil Agrawal, Radha Pooven- dran, and Rameswar Panda. 2026. TOUCAN: Syn- thesizing 1.5m tool-agentic data from real-world MCP environments. An Yang, Anfeng Li, Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Gao, Chengen Huang, Chenxu Lv, Chujie Zheng, Day- iheng Liu, Fan Zhou, Fei Huang, Feng Hu, Hao Ge, Haoran Wei, Huan Lin, Jialong Tang, Jian Yang, Jianhong Tu, Jianwei Zhang, Jian Yang, Ji- axi Yang, Jingren Zhou, Junyang Lin, Kai Dang, Keqin Bao, Kexin Yang, Le Yu, Lianghao Deng, Mei Li, Mingfeng Xue, Mingze Li, Pei Zhang, Peng Wang, Qin Zhu, Rui Men, Ruize Gao, Shixuan Liu, Shuang Luo, Tianhao Li, Tianyi Tang, Wenbiao Yin, Xingzhang Ren, Xinyu Wang, Xinyu Zhang, Xu- ancheng Ren, Yang Fan, Yang Su, Yichang Zhang, Yinger Zhang, Yu Wan, Yuqiong Liu, Zekun Wang, Zeyu Cui, Zhenru Zhang, Zhipeng Zhou, and Zi- han Qiu. 2025. Qwen3 technical report. CoRR, abs/2505.09388. Junjie Ye, Zhengyin Du, Xuesong Yao, Weijian Lin, Yufei Xu, Zehui Chen, Zaiyuan Wang, Sining Zhu, Zhiheng Xi, Siyu Yuan, Tao Gui, Qi Zhang, Xuanjing Huang, and Jiecao Chen. 2025. Toolhop: A query- driven benchmark for evaluating large language mod- els in multi-hop tool use. In ACL (1), pages 2995– 3021. Chaojia Yu, Zihan Cheng, Hanwen Cui, Yishuo Gao, Zexu Luo, Yijin Wang, Hangbin Zheng, and Yong Zhao. 2025. A survey on agent workflow – status and future. In Proceedings of the 2025 8th International Conference on Artificial Intelligence and Big Data (ICAIBD), pages 770–781. IEEE. Kangning Zhang, Wenxiang Jiao, Kounianhua Du, Yuan Lu, Weiwen Liu, Weinan Zhang, Lei Zhang, and Yong Yu. 2025. Looptool: Closing the data-training loop for robust llm tool calls. CoRR, abs/2511.09148. Lucen Zhong, Zhengxiao Du, Xiaohan Zhang, Haiyi Hu, and Jie Tang. 2025. Complexfuncbench: Ex- ploring multi-step and constrained function call- ing under long-context scenario. arXiv preprint arXiv:2501.10132. Appendix A Dataset details A.1 Toolset construction As illustrated in Figure 7, the toolset is formally defined as the union of six distinct subsets drawn from three primary sources: (1) Academic bench- marks: We integrated tools from established bench- marks to ensure comparability. This includes FC- REWARDBENCH (T fc ) (Agarwal et al., 2025) and TOOLRET-TRAIN (T ret ) (Shi et al., 2025). (2) MCP servers: To capture real-world tool usage patterns, we collected Model Context Protocol (MCP) servers. This subset comprises the top 40 servers listed on mcp.so at the time of collection (T so ) (MCP.so Team, 2025) and 11 servers utilized in MCP-UNIVERSE (T uni ) (Luo et al., 2025b). The specific list of MCP servers is provided in Table 3. (3) Constructed datasets: This subset includes the specific tool definitions extracted from the training (T train ) and test (T test ) datasets constructed in this study. A.2 Tool classification taxonomy Functional Categories Based on common API usage patterns observed in agent systems, we define six functional categories: •Analysis: Data analysis and insights (statisti- cal analysis, trend analysis, data mining, pre- dictive analysis, business intelligence, etc.) • Operations: Business process operations (create, update, delete, workflow management, business logic execution, etc.) •System: System administration and mainte- nance (system configuration, user manage- ment, system monitoring, technical mainte- nance, etc.) •Visualization: Data visualization and presen- tation (chart generation, report creation, data display, dashboard creation, etc.) •Search: Information retrieval and search (full- text search, fuzzy search, index query, struc- tured query, data lookup, etc.) • Generate: Content and data generation (con- tent generation, code generation, intelligent recommendation, AI generation, automated creation, etc.) Application domains Tools are further associ- ated with one of thirteen application domains to reflect real-world usage scenarios: •Finance: Finance related (payment, invest- ment, wealth management, insurance, trading, etc.) •Technology: Technology and software devel- opment (programming, system management, software tools, IT infrastructure, etc.) •Education: Education and learning (aca- demic courses, training programs, educational content, learning management, etc.) •Healthcare: Medical and health services (medical treatment, health monitoring, medi- cal devices, healthcare management, etc.) •Entertainment: Entertainment and media (music, games, film/TV, social entertainment, news, content creation, etc.) •Travel: Travel and transportation (tourism, transportation, accommodation, attractions, travel planning, etc.) •Business: Business management (enterprise operations, marketing, customer relations, business processes, etc.) • Lifestyle: Daily life services (shopping, food, housekeeping, personal tools, consumer ser- vices, etc.) •Science: Scientific research and analysis (re- search projects, scientific experiments, aca- demic studies, data analysis, etc.) •Social: Social communication and commu- nity (social networking, communication tools, community management, collaboration, etc.) •Sports: Sports and fitness (sports activities, fitness training, sports events, athletic perfor- mance, etc.) •Environment: Environment and sustainabil- ity (environmental protection, climate moni- toring, ecology, sustainable development, etc.) •Culture: Culture and arts (art, literature, his- tory, cultural events, language learning, cre- ative content, etc.) A.3 Toolset filtering details Because the collected tools originate from hetero- geneous sources, the raw pool contains redundancy and incomplete definitions. As illustrated in Fig- ure 7, we therefore apply a multi-stage filtering pipeline to improve tool quality and ensure fair eval- uation. First, we remove exact duplicates within and across subsets based on tool names and descrip- tions. Second, we exclude tools whose schemas rely on temporal attributes, since different bench- marks adopt inconsistent conventions for resolving relative time expressions (Appendix B.1). Third, Servers from mcp.so (Top 40) 302_browser_use_mcp302_sandbox_mcpagentql-mcp-serveramap-maps aws-kb-retrieval-serverbaidu-mapblenderbrave-search context7devcontextedgeone-pages-mcpeverart fetchfirecrawl-mcp-serverframelink-figma-mcp-servergithub gitlabgoogle-mapshowtocook-mcpjina-ai-mcp-tools mailtrap-email-sending-mcpmcp-advisormcp-server-flomo-mcp-serverminimax-mcp neon-mcp-servernotion-mcp-serverperplexity-ask-mcp-serverplaywright-mcp postgresqlpuppeteerqiniu-mcp-serverredis search1apisentrysequential-thinkingserper-mcp-server slacktimetodoist-mcpzhipu-web-search Servers from MCP-Universe (11 Servers) blendercalculatordatefetch githubgoogle-mapsgoogle-searchnotion playwrightweatheryfinance Table 3: The complete list of collected MCP servers used in our toolset construction. we discard tools with missing or invalid parameter schemas to ensure that each tool provides sufficient information for argument generation. Finally, we perform semantic deduplication using embedding similarity to remove functionally redundant tools with different names. Exact deduplication Tools extracted from pub- lic datasets often contain duplicates because identi- cal tool definitions appear in multiple query–tool pairs. We first perform intra-subset deduplication by removing entries with identical tool names and descriptions. This is followed by inter-subset dedu- plication across different tool sources. To preserve dataset consistency, tools belonging toT train and T test are retained even when duplicates are detected across external subsets. Schema validationWe remove tools with incom- plete definitions, such as those lacking a valid pa- rameter schema. Tools that contain only a name or description without argument specifications can- not provide sufficient supervision for learning the mapping between user queries and structured tool arguments. Semantic deduplication To identify semanti- cally redundant tools with different names, we en- code the concatenation of each tool’s name and description using QWEN3-EMBEDDING-8B. Co- sine similarity is computed using FAISS. Tools with similarity greater than 0.9 are considered du- plicates. When duplicates are detected, instances from external subsets are removed while those be- longing toT train andT test are retained to preserve dataset consistency. A.4 Public data quality evaluation and filtering To construct a structurally consistent training and evaluation corpus, we apply uniform filtering prin- ciples across all public datasets. Table 4 sum- marizes the dataset-level normalization and filter- ing applied to all public corpora prior to integra- tion. Across all datasets, we enforce the following dataset-agnostic criteria: •Schema completeness: each sample must contain a well-formed user query, a valid tool call (or candidate API schema), and—when applicable—observations and final answers. •Executable supervision: we discard items with missing function calls, incomplete pa- rameter specifications, invalid JSON structure, or empty/malformed ground-truth traces. •Language normalization: only English- language user queries and assistant messages are retained. •Toolset compatibility: samples referenc- ing tools removed during tool filtering (e.g., temporal-sensitive or redundant tools) are ex- cluded. •Invalid-category filtering: subsets explic- itly marked as irrelevant or lacking actionable ground truth are removed. • Deterministic evaluation: for test sets, we re- tain only samples for which function calls and argument mappings can be deterministically reconstructed. T train (30,199) T test (5,113) T ret (31,123) T fc (1,983) T so (275) T uni (119) T train (30,199) Preserved T test (5,113) Preserved T ret (25,014) T fc (1,980) T so (247) T uni (90) T train (23,372) T test (3,610) T ret (19,516) T fc (974) T so (205) T uni (68) T train (15,078) T test (2,257) T ret (16,603) T fc (949) T so (197) T uni (64) T train (15,078) Preserved T test (2,257) Preserved T ret (4,944) T fc (127) T so (150) T uni (50) Removed (Exact Match) Removed (Temporal) Removed (Empty Schema) Removed (Semantic) Multi-Stage Toolset Quality Filtering Flow Figure 7: The multi-stage data reduction flow of our toolset quality filtering process. Gray indicates the tool being deduplicated, and purple indicates the tool being retained. After standardization, we further filtered sam- ples based on the finalized training and evaluation tool inventories, removing conversations that refer- enced tools excluded during toolset filtering. The statistics are illustrated in Table5. A.5 Synthetic data quality evaluation and filtering To ensure the quality and consistency of the synthet- ically generated dataset without relying on exter- nal proprietary models, we design a unified LLM- based self-evaluation framework. The generator model (QWEN3-32B) evaluates its own generated QAOA trajectories across a set of fine-grained met- rics. The framework is shared across single/multi- hop and single/multi-turn datasets, with minor ex- tensions for multi-turn episodes. Evaluation dimensions The evaluation rubric consists of six core metrics grouped into two dimensions: Query Evaluation and Trajectory Evaluation. Each metric is scored on a scale from 1 to 10 by the generator model. Query evaluation This dimension evaluates the initial user queryqwith respect to the available tools: •Tool-fit: Whether the query is appropriately designed around the available tool capabili- ties and implicitly or explicitly provides the necessary parameters. •Clarity: Whether the task specification is un- ambiguous, well-defined, and provides suffi- cient constraints for planning a valid solution. •Naturalness: Whether the query resembles a realistic user request in a practical sce- nario rather than a templated or system-style prompt. Trajectory evaluationThis dimension evaluates the correctness and coherence of the generated tra- jectory consisting of Action (a), Observation (o), and Answer (r): •Success: Whether the generated tool calls and final answer successfully complete the user’s task. •Grounding: Whether the final response is strictly supported by the simulated observa- tions, without hallucinated facts or inconsis- tent parameters. • Efficiency: Whether the trajectory completes the task using a concise and non-redundant sequence of tool calls. DatasetProcessing Summary BFCL (Patil et al., 2025)Removed irrelevance, live_irrelevance, live_relevance, and multi_turn_miss_func subsets; dropped non-English queries; converted 3,065 valid samples to the unified QAOA format. ACEBench (Chen et al., 2025a)Retained subsets with deterministic function-call mapping; removed atom-type subsets; normalized query–function structures; added consistent gold function-call annotations. Seal-Tools (Wu et al., 2024)Preserved train/dev/test-in/out-domain partitions; standardized tool schemas; con- verted all entries into QAOA with explicit tool definitions. HammerBench (Wang et al., 2024) Excluded multi-turn parameter-filling subsets; processed single-turn samples with new identifiers; mapped tool definitions and integrated unified system prompts. ComplexFuncBench (Zhong et al., 2025)Standardized multi-step API sequences into multi-hop trajectories; ensured consis- tent JSON formatting; retained 1,000 normalized samples. API-Bank (Li et al., 2023)Kept only Level-3 (Plan+Retrieve+Call) samples; removed Level-1/2 subsets re- quiring missing user inputs; transformed remaining items into QAOA structure. ToolAlpaca (Tang et al., 2023)Transformed API descriptions and queries into single-hop QAOA format; removed structurally inconsistent items. ToolHop (Ye et al., 2025)Retained items convertible to multi-hop trajectories; removed unresolved-hop sub- sets; normalized argument formats and tool identifiers. APIGen (Liu et al., 2024)Filtered structurally invalid entries from 60,000 raw items; standardized tool schemas; integrated 17,178 valid samples into QAOA. Junaidjk (Junaidjk, 2024)Unified formatting into QAOA; removed schema-mismatched or incomplete entries; retained samples with valid function-call traces. Vikhrmodels (Vikhrmodels, 2024)Standardized tool schemas; resolved formatting inconsistencies; retained entries convertible to well-formed function calls. MathAndMagic (MathAndMagic, 2024) Normalized function-calling traces; removed incomplete or invalid entries; retained consistent QAOA-formatted samples. Toucan (Xu et al., 2026) Converted 1.37M raw samples; removed incomplete or structurally inconsistent trajectories; retained 319,669 QAOA-normalized conversations. Table 4: Public data quality evaluation and filtering. DatasetConv.Filt. Training Data (D pub ) API-Bank (Li et al., 2023)338122 ToolAlpaca (Tang et al., 2023)4,0962,429 ToolHop (Ye et al., 2025)9957 APIGen (Liu et al., 2024)60,00028,666 Seal-Tools (Wu et al., 2024)12,0225,214 Toucan (Xu et al., 2026)1,367,983319,669 Tool-calling (Interstellar Ninja, 2025)35,7868,692 Junaidjk (Junaidjk, 2024)13,8503,470 Vikhrmodels (Vikhrmodels, 2024)3,3962,493 MathAndMagic (MathAndMagic, 2024)22,21816,361 Total (Train)1,520,684387,123 Evaluation Benchmark (D test ) BFCL V3 (Patil et al., 2025)3,065984 ACEBench (Chen et al., 2025a)25059 Seal-Tools (Wu et al., 2024)1,354579 HammerBench (Wang et al., 2024)6,5314,340 ComplexFuncBench (Zhong et al., 2025)1,00051 API-Bank (Li et al., 2023)5035 ToolAlpaca (Tang et al., 2023)209145 Total (Test)12,4596,163 Table 5: Statistics of the public datasets integrated into our framework. Conv. (Converted Count) represents the initial number of conversations obtained after standard- izing the raw heterogeneous data into our unified QAOA format. Filt. (Filtered Count) indicates the final retained size after our rigorous quality filtering mechanism. Multi-Turn anchor evaluation For multi-turn episodes, we extend the six- dimensional rubric with an additional episode-level metric: •Anchor Linkage (s anchor ): Measures whether later turns explicitly and consistently refer- ence anchors introduced in previous turns, and whether such references are functionally meaningful for subsequent tool usage. Acceptance thresholds For all synthetically generated candidates that pass basic schema and formatting checks, we apply strict acceptance criteria based on the evaluation scores. Single-Hop and Multi-Hop instances A trajec- tory is accepted only if the following conditions are simultaneously satisfied: •Minimum score constraint: The lowest score among all six metrics must be at least 4.0 (min(S)≥ 4.0). •Average score constraint: The average score across the six metrics must be at least8.0 (avg(S)≥ 8.0). These constraints ensure that no individual di- mension is critically flawed while maintaining high overall quality. Multi-Turn episodesFor multi-turn data, accep- tance is determined by a weighted comprehensive score: S = 0.4 Query avg + 0.4 Trajectory avg + 0.2s anchor (1) A multi-turn episode is accepted only ifS ≥ 8.0 and the minimum score across all dimensions is at least 4.0. Self-Refinement loop If a generated trajectory fails to satisfy the above criteria, the pipeline triggers an automatic self- correction loop. The generator model is instructed to regenerate the trajectory for the same target tool, with a maximum of three retries. If no valid trajec- tory is produced after all attempts, the correspond- ing tool is excluded from the synthetic datasetD syn . A.6 Statistics of D Pub Figure 8 shows the comprehensive statistics of our unified training datasetD Pub . Collectively, these distributions highlight the dataset’s high diversity and rigorous complexity, highlighting the diversity and structural complexity of the dataset. B Benchmark details B.1 Temporal filtering criteria Different benchmarks adopt inconsistent conven- tions for handling temporal parameters. For ex- ample, ACEBench resolves relative expressions (e.g., tomorrow) into absolute timestamps, whereas HammerBench preserves the original relative ex- pressions. To ensure the exclusion of time-sensitive tools that may introduce evaluation bias, we im- plemented a keyword-based filtering mechanism based on the following criteria: Keyword list •Core keywords: date, dates, time, times, date- time, timestamp •Units: day, days, hour, hours, minute, min- utes, second, seconds •Periods: year, years, month, months, week, weeks • Actions/Properties: when, schedule, sched- uled, duration, period, periods •Specific scenarios: start_time, end_time, start_date,end_date,pickup_time, dropoff_time, etc. Matching patterns We support multiple naming conventions to ensure comprehensive coverage: • Snake case: e.g., travel_date, start_time • Kebab case: e.g., travel-date, start-time • Camel case: e.g., travelDate, startTime • Word boundary: Isolated occurrences of key- words (e.g., date, time) B.2 Rule-based matching details Rule-based matching is implemented as strict exact matching after deterministic normalization. This stage is designed to treat formatting variance as equivalent while preserving hard correctness con- straints. Tool name normalization Tool names are nor- malized by removing punctuation, digits, and sepa- rators, and then converting to lowercase. For exam- ple, uber.ride and uber_ride become identical after normalization. Parameter value normalization. To robustly compare parameter values across heterogeneous outputs, we apply the following canonicalization rules: •Date canonicalization: date strings in multi- ple formats (e.g., April 1, 2023, 2023-04-01, and 2023/04/01) are normalized to Y- M-D. •Array parsing: stringified arrays (e.g., [1, 2, 3]) are parsed into actual arrays before com- parison. •String normalization: strings are lowercased, punctuation and articles (a/an/the) are re- moved, and whitespace is ignored; e.g., A black cat and blackcat are treated as identical. •Type casting: mixed representations of the same value are unified, including numeric string–number equivalence (e.g., "40.7128" and 40.7128). Matching criteria After normalization, rule- based matching requires full equality on both nor- malized tool names and all normalized argument key-value pairs. Such normalization improves eval- uation fairness and reproducibility by removing superficial formatting variance while preserving exact semantic correctness constraints. Figure 8: Comprehensive statistics of our unified training datasetD Pub . The top row illustrates the structural complexity and scale, including the distribution of tool calls per sample, token length density, and the proportions of multi-turn and multi-hop trajectories. The bottom row demonstrates the broad semantic diversity across tool domains and functional categories, alongside conversation density metrics. Note that Messages per Sample reflects the total count of user queries, tool calls, environment observations, and assistant answers within a single dialogue episode. ModelSH SP (%)MH FP (%)SH SPA (%)MH FPA (%) Qwen3-8B (Vanilla) 67.7± 1.3 22.9± 1.7 39.1± 2.4 39.1± 2.4 UniToolCall 93.9± 1.0 80.5± 0.5 67.0± 0.7 78.6± 0.3 Table 6: Repeated-run statistics for hop-level metrics. ModelST SP (%)MT FP (%)ST FPA (%)MT SPA (%) Qwen3-8B (Vanilla) 64.1± 1.3 27.5± 3.4 22.5± 0.7 13.2± 1.3 UniToolCall 93.8± 0.8 37.8± 1.6 52.8± 0.4 16.6± 4.0 Table 7: Repeated-run statistics for turn-level metrics. C Experimental details C.1 Run-level stability statistics Tables 6 and 7 report repeated-run statistics for the trainable backbone models. Both UniToolCall and the vanilla Qwen3-8B are trained three times with independent runs. The reported values are mean± sample standard deviation across runs. The repeated-run statistics show that the im- provements of UniToolCall over the vanilla back- bone remain consistent across runs, particularly for single/multi-hop, and single-turn tool selection. Variance remains relatively small for most metrics. Multi-turn metrics exhibit larger fluctuations due to the small evaluation size (36 conversations) and the inherent difficulty of strict conversation-level matching. C.2 Example of the action-only training format Observation and Answer fields are retained in the dataset for evaluation purposes but are not part of the prediction target during fine-tuning. This design isolates the model’s tool-selection and parameter-generation capabilities from down- stream response realization. To illustrate this struc- ture, a concrete data sample of a single-hop sce- nario is presented below. Data Sample (P sys ) "conversations":[ "from": "human", "value": "Provide secure access to medical records for a patient named John Smith." , "from": "function_call", "value": "\"name\":\"MedicalRecordAccess\",\"arguments\":\"patient_name\":\"John Smith\"" , "from": "observation", "value": "" , "from": "gpt", "value": "<answer></answer>" ], "system": "# Role are an AI assistant capable of calling various functions to help users solve their problems. # Tool Selection **Important**: The available function signatures are provided in the <tools></tools> section. You must carefully select one or more appropriate tools from this section that can solve the user's request. # Output Rules must strictly follow the rules below when responding: ## 1. Function Call Format you need to call a function, you must output only one function call per round in the following format: <tool_call> \"name\": <function-name>, \"arguments\": <args-json-object> </tool_call> **Parameter Parsing**: The arguments must be parsed based on the user's query. **Do not fabricate parameters that are not mentioned or cannot be reasonably inferred from the query.** Only use parameters that can be reasonably extracted or inferred from the user's request. **Basis for Generating Function Call Content**: - **First function call**: The user's query and available tools information. - **n-th function call (n > 1)**: The user's query, available tools information, and the complete conversation history in <chat_history></chat_history> from the previous n-1 rounds (including all prior function calls, observations, and answers). In some scenarios, observations may be empty; this is acceptable for generating function calls. **Example**: <tool_call> \\\"name\\\": \\\"cancel_booking\\\", \\\"arguments\\\": \\\"access_token\\\": \\\" abc123xyz\\\", \\\"booking_id\\\": \\\"flight_001\\\" </tool_call> ## 2. Answer Format you judge from the chat history that all necessary tools have been called, you must immediately stop calling tools and provide the final answer in the following format: <answer> final answer here </answer> **Answer Generation Requirements**: - **Critical**: If all observations in chat-history are empty (meaning tools were called but returned no data), you MUST reply exactly: \"Sorry, I did not obtain sufficient information to complete your request.\" Do NOT fabricate, invent, or generate any content based on assumptions. Do NOT create imaginary results or responses. Only output this exact message. - **Important**: The provided tools may include tools that are irrelevant or unsuitable for the current query. If you determine there are no suitable tools to answer the user 's request, reply: \"Sorry, there are no suitable tools to answer your request.\" - **Important**: If you have called some tools and obtained observations, but the available tools are insufficient to fully satisfy the user's request (e.g., some required tools are missing from the available tool list), you MUST reply exactly: \"Sorry, there are not enough tools to fully satisfy your request.\" Do NOT fabricate or generate partial answers based on incomplete information. - Carefully analyze the conversation history to determine the current turn. The answer must be based on the user's query and all available observation results in the conversation. ## 3. Intelligent Process Stage Judgment - single-hop: Typically requires only one tool call to complete the task. - multi-hop: Requires multiple tool calls to complete the task. - single-turn: Involves only one user query. - multi-turn: Involves multiple user queries; later queries may refer to or build upon earlier exchanges. - When you see that the assistant has issued a tool call and received an observation, that tool call is considered complete.\ n **Special Note**: By examining the conversation history, you can clearly see: - Previous interactions between the user and the assistant - Tool calls that have already been executed - Results returned by tools - The stage the current conversation has reached ## 4. Strictly Prohibited Behaviors - Do not output a function call and an answer in the same round. - Do not repeatedly call the same tool with identical parameters. - Do not ignore existing tool calls and their returned information in the conversation history. - Do not fabricate parameters that are not present in or reasonably implied by the user's query. ## 5. Error Handling and Data Quality Assessment - If the tool returns an empty observation, it may indicate there is no data under the current query conditions or that observation data is unavailable in the current context. - If the tool returns error messages (e.g., \"resource not found\", \"invalid parameters\"), do not repeat the same tool call. - In such cases, provide an explanatory answer describing the specific error cause or data condition. - Absolutely do not repeatedly call the same tool because it returned an error or empty data. ", "tools": "[ \"name\": \"MedicalRecordAccess\", \"description\": \"API for providing secure access to medical records.\", \"category\": \"operations\", \"domain\": \"healthcare\", \"inputSchema\": \"type\": \"object\", \"properties\": \"patient_name\": \"type\": \"str\", \"description\": \"The name of the patient.\", \"required\": [\"patient_name\"] , ... [18 distractor tools omitted for brevity] ..., \"name\": \"update_with_defaults\", \"description\": \"Updates the defaults dictionary with the values from the updates dictionary.\", \"inputSchema\": \"type\": \"object\", \"properties\": \"defaults\": \"type\": \"object\", \"additionalProperties\": \"type\": \"integer\", \"description\": \"The default dictionary to be updated.\", \"updates\": \"type\": \"object\", \"additionalProperties\": \"type\": \"integer\", \"description\": \"The dictionary containing updates to apply to the defaults.\", \"required\": [\"defaults\", \"updates\"], \"category\": \"operations\", \"domain\": \"technology\" ]"