jevuipathbooleanper tool callmirrors uipath.eval ToolCallArgsEvaluator / ToolCallOutputEvaluator, with equivalent-argument matching

Tool calls (semantic, per call)

Tool calls (semantic) gives each expected tool call a probability that an equivalent call was made: same tool, and argument values that mean the same thing even if keys are renamed or values reformatted. It is the judgment version of UiPath's ToolCallArgsEvaluator, one question per call in one request.

Run this example in the console 1 jev question · answered inside one request
how it works // frame by frame

What the evaluator does

For M expected calls jeval adds M Noul questions. Score is the share matched; details list each call with its probability.

frame 1/4 · expected calls
expected calls
search_flights(from: BLR, to: SFO, date: 2025-11-12, direct: true)
send_email(to: priya@example.com, subject: Flight confirmation)
actual calls
search_flights(origin: BLR, destination: SFO, date: Nov 12, 2025, nonstop: true)
send_email(to: priya@example.com, subject: Your SFO flight)
97%renamed keys + reformatted date → still equivalent
62%same recipient, different subject wording → probably equivalent
2/2 matched · exact match would report 0/2
exactly what jev is asked

The question, verbatim

This is the question the API sends for the example below, generated from the same code path the playground and API use. Jev sees the request fields as state and returns a probability for each outcome. Nothing is generated, so there is nothing to parse.

t0noul · p(yes)

`tool_calls` contains a call equivalent to `expected_tool_calls[0]`: same tool, and argument values that mean the same thing even if formatted or named differently.

when to use it

Reach for it when

  • Agents whose tool schemas drift (origin/destination vs from/to).
  • Dates, amounts and enums that come back formatted differently.
  • Any place exact-match tool tests produce false failures.

Not the right tool when

  • Arguments must be byte-identical for a downstream system (use tool_call_args).

Watch out for

  • Semantic equivalence can be too lenient for security-sensitive arguments (recipients, amounts); keep the exact evaluators for those.
inputs and example

What to send

required fields
tool_callsexpected_tool_calls
optional fields
input
in suites
AgentEverything
result shape

score 0–1 (p of the good outcome), label “nn% yes”, confidence |p − 0.5| × 2, probabilities yes/no, passed at 0.5. Plus a details array with one row per tool call.

POST /api/v1/evaluateopen in console
{
  "evaluators": [
    "tool_call_semantic"
  ],
  "output": "booked",
  "tool_calls": [
    {
      "name": "search_flights",
      "args": {
        "origin": "BLR",
        "destination": "SFO",
        "date": "Nov 12, 2025"
      }
    }
  ],
  "expected_tool_calls": [
    {
      "name": "search_flights",
      "args": {
        "from": "BLR",
        "to": "SFO",
        "date": "2025-11-12"
      }
    }
  ]
}
expected

Matched with high probability; exact match would have failed.

rolling it up

Aggregate with

One result per item is a fact; a dataset of them is a metric. These are the aggregations that fit this evaluator's output shape.

related evaluators
questions people ask
Does semantic tool-call matching replace exact matching?
No, it complements it. Run both: exact for arguments that must be precise, semantic for the ones where format varies.