Python: FoundryEvals always emits arguments field for tool calls - #7734
Conversation
FoundryEvals uploaded tool_call content items without an arguments field when a tool call had no model-supplied arguments. Foundry's tool-aware evaluators (task_adherence, tool_output_utilization, tool_call_accuracy) require the arguments field to always be present, so zero-argument tool calls caused evaluation to fail with FAILED_EXECUTION. Default to an empty object instead of omitting the field.
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Adds support for tool calls that have no arguments by ensuring the evaluation conversion always emits an arguments field (defaulting to {}) and covering the behavior with a new test.
Changes:
- Add a test for zero-argument tool calls (
arguments=None) expecting{}. - Update message-to-eval conversion to always include
arguments, defaulting to{}when missing.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| python/packages/foundry/tests/test_foundry_evals.py | Adds regression test to validate zero-argument tool calls serialize with empty arguments. |
| python/packages/core/agent_framework/_evaluation.py | Ensures tool calls always include an arguments key, defaulting to {} when absent. |
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
Addresses Copilot review feedback: a truthiness check would also
overwrite valid but falsy parsed arguments (e.g. 0, "", False) with
{}. Use an explicit None check so only missing arguments are defaulted.
|
Please use our pull request template, and per contributing guidelines: respond to and resolve all open PR comments. |
|
/review |
There was a problem hiding this comment.
MAF Automated Review — Iteration 1
Result: No findings
Scope: full PR (2 commit(s)): 042676c982e3, 103185927c44
Model: gpt-5.6-sol
Overview
The change unconditionally emits the Foundry-required arguments field while preserving all non-None argument values, including falsy values, and defaulting only missing arguments to {}. The focused regression test covers the zero-argument case, while existing tests protect JSON-string parsing and mapping arguments. No publishable Critical, High, or Medium defect remains after reconciliation.
Reviewed the supplied pull-request change set across correctness, security/reliability, architecture, and failure behavior.
No publishable findings remained after source verification for this scope.
Python Test Coverage Report •
Python Unit Test Overview
|
||||||||||||||||||||||||||||||
Motivation & Context
AgentEvalConverter.convert_messageonly set theargumentsfield on atool_callcontent item when the parsed arguments were truthy, so tool calls with no model-supplied arguments were uploaded without anargumentsfield at all. Foundry's tool-aware evaluators (task_adherence,tool_output_utilization,tool_call_accuracy) require everytool_callitem to have anargumentsfield, even if empty, and fail withFAILED_EXECUTIONotherwise. This contributes to theFoundryEvalsevaluation scenario for agents with zero-argument tools.Description & Review Guide
python/packages/core/agent_framework/_evaluation.py:tc["arguments"]is now always set, defaulting to{}only when the parsed arguments areNone(an explicitis not Nonecheck, not a truthiness check, so valid-but-falsy arguments like0/""/Falseare preserved)."arguments": {}instead of omitting the key, matching what Foundry's evaluators require. No behavior change for tool calls that already had arguments.{}(vs. omitting the field) is the correct shape for all Foundry evaluators, and whether theis not Nonecheck should also apply to the existing{"_raw_arguments": "[unparseable]"}fallback path.Related Issue
Fixes #7714
Contribution Checklist