Testing methods

How do you test an agent's tool calls?

Short answer

Testing tool calls means checking three things: did the agent pick the correct tool for the task, did it pass arguments that are both valid and correct, and did it handle what the tool returned, including errors. You test the first two by asserting on the calls the agent makes, and the third by returning realistic responses and failures and watching how the agent reacts.

Selection, arguments, and handling

  • Selection: given a task, did the agent choose the right tool, and did it avoid calling tools it did not need
  • Arguments: were the arguments schema-valid, and were the values actually correct for the task, not just well-formed
  • Response handling: when the tool returns data, an empty result, or an error, does the agent react sensibly

Valid is not the same as correct

A common trap is checking only that arguments match the schema. An agent can pass a perfectly valid customer ID that happens to be the wrong customer. Assert on the actual values against the task, not just their shape, or you will miss the errors that matter most.

pythondef test_selects_refund_with_correct_args():
    calls = run_agent("refund order #1234 for Maria")
    tool = next(c for c in calls if c.type == "tool_use")

    # 1. right tool
    assert tool.name == "create_refund"
    # 2. right arguments, not just schema-valid ones
    assert tool.input["order_id"] == "1234"
    assert tool.input["customer"] == "maria"
    # 3. it did not also cancel or charge anything
    assert not any(c.name in {"cancel_order", "create_charge"} for c in calls)

Schema validation would pass an order_id of "9999". Asserting the value is what catches the wrong-order bug.

Benchmarks and tooling

Function-calling ability is measured publicly by the Berkeley Function-Calling Leaderboard and ToolBench, which are useful for comparing models. For your own agent, most eval frameworks let you assert directly on the tool calls a run produced (see the tools guide).

Grading against a known-good answer

Checking a tool call in isolation still leaves the question of what the right call actually was. For a given task and starting state there is usually a known-good answer, the specific tool, arguments, and order a correct agent would produce, and scoring against that ground truth beats eyeballing transcripts.

The pattern is straightforward. Define the expected sequence of tool calls for a given workflow, run the agent, then compare actual against expected and flag anything that diverges, a wrong tool, a wrong argument, a missing step, or a call made out of order. It sounds simple, but most teams skip it because building the ground truth by hand is tedious and rarely feels worth the effort. Though, tools such as Arga Labs can build it automatically alongside its service replicas.