HyperTool: Evolving AI Agents from One-at-a-Time Tool Calls to Scripted Batch Execution

Forum topic · ✨步子哥 · 2026-06-12

Summary

Researchers from Shanghai Jiao Tong University and IQuest Research propose HyperTool, a framework that upgrades how AI agents use tools—from sequential single-tool calls to writing code blocks that batch multiple operations. Current MCP-style interfaces suffer from an execution-granularity mismatch: task-level operations unfold into multiple model-visible state transitions, causing context bloat and fragmented reasoning. HyperTool lets models write code blocks that call existing MCP tools, store and parse intermediate results, perform lightweight computations, and return only the final output to the main reasoning chain—fully backward-compatible with standard interfaces. A data synthesis pipeline (composite task construction, trajectory generation with GLM-5.1, and real-environment validation) trains models to use it. On MCP-Universe, Qwen3-32B improved from 15.69% to 35.29% accuracy and Qwen3-8B from 9.93% to 33.33%, with the 8B model outperforming GPT-OSS (32.13%) and Gemini-2.5-Flash (25.58%). Gains were largest on composition-heavy tasks like financial analysis. Ablations showed a unified code-block interface beats a hybrid mode by 6.5 points.

Imagine operating files via a command line. Every step requires manual input: open a folder, list files, find the target, copy the path, paste it into another command... If you need to do ten similar operations, you repeat the manual typing twenty times.

This is how today's AI agents use tools—call one tool, wait for the result, decide the next step. Even for a fully deterministic set of operations (e.g., look up the coordinates of two locations, then compute the distance), the agent must proceed step by step, with every intermediate result piling into the context window like a snowball.

A team from Shanghai Jiao Tong University and IQuest Research proposes HyperTool, upgrading agent tool usage from "typing commands line by line" to "writing scripts for batch processing."

Execution-Granularity Mismatch: The Root of the Problem

Current MCP-style tool interfaces have a fundamental design flaw—execution-granularity mismatch. A task-level operation (e.g., "find the distance between two cities") requires three low-level steps: geocode city A, geocode city B, compute distance. But the agent's reasoning only needs the final result: the distance.

In step-by-step mode, these three steps expand into three model-visible state transitions. Geocoding outputs, intermediate coordinates, and the final result are all exposed in the main reasoning chain. This causes two problems:

1. Context bloat: long tool outputs accumulate in the reasoning chain even when only a few fields are useful 2. Fragmented reasoning: the model is forced to repeatedly switch between high-level task reasoning and low-level data plumbing—like pausing to look up a dictionary every few sentences while writing an essay

HyperTool's Core Idea: Folding Subroutines into One Call

HyperTool's approach is elegant: don't change the underlying tools—change how they are invoked.

Instead of calling atomic tools one by one, the model writes a code block. Inside this block, it can call existing MCP tools, store return values, parse and filter results, do lightweight computations, and define temporary helper functions—all intermediate steps happen inside the block. Only the final result returns to the main reasoning chain.

It's like evolving from an "interactive command line" to a "scripting language": instead of manually stepping through operations, you write a small program that runs automatically and reports the result.

If a code block contains only one tool call, HyperTool degenerates into standard step-by-step mode—so it is fully compatible with existing interfaces and a superset of them.

Data Synthesis: Teaching Models to "Write Scripts"

Models don't naturally know how to use HyperTool. The team designed a data synthesis pipeline:

1. Composite task construction: generate tasks requiring cross-tool collaboration (e.g., "check weather + check flights + compare prices") 2. Trajectory collection: use GLM-5.1 to generate HyperTool-format execution trajectories, including local repair (auto-fixing broken code) and context compression 3. Trajectory verification: validate execution correctness and evidence consistency in real MCP environments

Verification is the key step—it's not enough to "look right"; code blocks must actually execute and produce correct results in a real environment.

Results: An 8B Model Surpasses GPT and Gemini

On the MCP-Universe benchmark, HyperTool delivers dramatic improvements:

Qwen3-32B: average accuracy from 15.69% to 35.29%—more than doubled
Qwen3-8B: from 9.93% to 33.33%—more than tripled
The 8B HyperTool model even surpassed GPT-OSS (32.13%) and Gemini-2.5-Flash (25.58%)

The largest gains came on composition-heavy tasks. In financial analysis, both the 8B and 32B versions reached 62.5% accuracy—because such tasks most need to pass intermediate values across tools, filter, and aggregate results, exactly what HyperTool's code blocks do best.

Ablations also revealed a counterintuitive finding: a unified interface beats a hybrid one. HyperTool-only mode (all operations via code blocks) scored 6.5 points higher than hybrid mode (simple operations via atomic calls, complex ones via code blocks). The unified interface reduces the cognitive burden of switching between two modes—just as you wouldn't switch back to a command line while writing a script.

Token Efficiency: Fewer Turns, More Tool Calls

HyperTool executes more underlying tool calls in fewer interaction turns. By folding multi-step deterministic operations into code blocks, it avoids the context bottleneck that truncates long ReAct trajectories. Under a budget of 50 tool calls and 128k context, HyperTool accomplishes more work in fewer turns.

Why This Matters

HyperTool isn't just about efficiency—it challenges a fundamental design choice in agent architecture. All mainstream agent frameworks (ReAct, CodeAct, ToolFormer) assume "one tool call at a time" is naturally sensible. HyperTool shows this assumption is suboptimal—much as no one would argue an operating system should only execute single commands.

From an engineering perspective, HyperTool's MCP compatibility means it can plug-and-play into existing agent systems. From a research perspective, it raises a deeper question: should an agent's reasoning granularity be aligned with tools' execution granularity? Perhaps future agents shouldn't keep switching between "thinking" and "executing," but weave the two together—using code to do both at once.

---

Paper: https://arxiv.org/abs/2606.13663 Code repository: https://github.com/toolprint/hypertool-mcp