Skip to main content
Tool calls are often where the truth of a run lives. If the Agent’s answer is wrong, either the tool returned the wrong thing, or the Agent picked the wrong tool, or picked the right tool with the wrong args. The Trace makes all three visible.

​
Tool call view

For each tool call in a run:
  • Tool name and version.
  • Arguments — the exact JSON the model chose.
  • Response — the raw response from the tool.
  • Duration — wall clock from call to response.
  • Retries — attempts if the tool retried.
  • Cost — direct dollar cost (for tools with API pricing).
Arguments are shown with syntax highlighting and diff annotations against the tool’s schema — required-but-missing args in red, unrecognized args in yellow.

​
The “why did the Agent call this?” question

Above each tool call, the Trace shows the rationale: the fragment of the model’s reasoning output that motivated the call. Not always available (some models don’t emit reasoning), but when it is, it’s the fastest way to understand “why”.

​
Common failure modes

​
Wrong tool

Agent picked send_email when it should have picked send_slack. Fix by tightening the tools’ descriptions — the Agent chose based on descriptions alone.

​
Wrong args

Right tool, wrong arguments. Common cause: parameter descriptions were unclear. The Trace shows exactly what the model chose, so it’s usually obvious.

​
Tool errored

Tool returned a 4xx or 5xx. See Response for the error body. Handle by:
  • Fixing the tool config (wrong URL, expired secret).
  • Adding retries on transient errors.
  • Making the tool description warn the Agent about the argument shape.

​
Tool succeeded but returned the wrong data

Tool call passed, but the returned data was misleading. The Agent then reasoned on bad data. Investigate the tool implementation.

​
Tool response inspection

Large responses (JSON with hundreds of fields) are collapsible. The default view shows top-level keys; click to expand. Copy as curl recreates the exact request for local debugging.

​
Tool call sequences

Multi-tool runs show as a stacked sequence. Common patterns:
  • Search → Read → Answer — Agent searches, reads the top result, answers.
  • Lookup → Verify → Act — Agent looks up an entity, verifies with a second source, acts.
  • Retry loops — Agent tried a tool call, got a specific error, tried again with adjusted args.
Sequences are annotated: SUCCESS, RETRY, ABANDONED. Abandoned means the Agent gave up on that path.

​
Tools called during a rewrite

If verification triggered a rewrite (see Verify agent answers), the second pass may make different tool calls. Both passes are shown in the timeline separated by a Rewrite marker.

​
Recording tool calls to a dataset

Right-click any tool call → Add to dataset. Copies the tool call inputs and outputs as a labeled example. Useful for building test fixtures from real production behavior.