Loading ToolBench
Physics oracle: verifies S-parameter models and coupling matrices are physically possible.
Four tools with complete input schemas and descriptions. Naming is domain-specific and clear (check_*, tool_*). Descriptions are substantive (150-250 chars) and explain WHEN to use each tool. However, parameter descriptions are minimal or absent in some cases (e.g., 'path' in check_touchstone lacks format guidance). Output schemas are documented in code but not formally exposed in tool registration. Error handling is present but generic. No tool annotations (readOnlyHint, etc.) despite all being read-only operations.
Check a predicted coupling matrix against the many-body screening ceiling. Screening can only REDUCE coupling below the isolated-pair value, so a ratio above 1 is physically impossible.
Check whether an S-parameter (Touchstone .sNp) file describes a physically possible passive network. Verifies passivity, reciprocity, energy conservation, positive-real input impedance and non-negative group delay. Use this before reasoning from any S-parameter data you did not generate yourself.
Given a screening factor k, return the relative error incurred by a pairwise-superposition extractor that assumes no screening.
Verify the physics checker still discriminates, by confirming it rejects deliberately-invalid networks. Run this if you need to rely on a clean verdict.
Parameter descriptions are minimal or missing. 'path' in check_touchstone lacks format guidance (e.g., '.sNp file extension required'). 'c_full' and 'c_iso' in check_screening lack dimension/type hints (NxN float arrays). 'screening_factor' lacks range documentation despite code enforcing (0, 1].
No tool annotations despite all four tools being read-only and side-effect free. Adding readOnlyHint=true would signal to agents that these tools are safe to call speculatively and can be retried without risk.
Output schemas are documented in docstrings and return statements but not formally declared in the tool registration. LLMs cannot see the structure of 'laws' array in check_touchstone or 'as_dict()' output from check_screening without reading implementation code.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Error handling is minimal. pairwise_error raises ValueError for out-of-range screening_factor, but error message is generic. No guidance on recovery (e.g., 'screening_factor must be in (0, 1]; got X'). Other tools have no explicit error paths.
Tool names use 'check_' and 'tool_' prefixes inconsistently. TOOLS dict keys are 'check_touchstone', 'self_test', 'check_screening', 'pairwise_error', but function names are 'tool_check_touchstone', 'tool_self_test', etc. This mismatch could confuse tool registration.