Loading ToolBench
A tool for auditing supplier lead times and detecting delayed restocks based on historical delay patterns
Single tool with partial schema definition and minimal description. The tool name 'audit_lead_time' is reasonably verb-forward but lacks clarity on what triggers an alert. The schema is present but incomplete, parameter descriptions are present but the output schema is not documented in the source. The tool description (67 characters) is below the recommended minimum and does not explain when to use it, what prerequisites exist, or what the alert threshold means. No error handling guidance, no examples of failure modes, and no mention of how to interpret the 'alert_triggered' boolean. The implementation itself is readable but the MCP interface lacks production polish.
Audit supplier lead time by calculating average historical delays and determining if an alert should be triggered
Tool description is too brief (67 chars) and lacks critical context. Does not explain the alert threshold (3.0 days), when to call this tool, what inputs are required, or how to interpret results. LLMs cannot determine whether this tool addresses their user's need.
Output schema is not documented in the source code or tool definition. The MCP schema only defines inputs; the output structure (estimated_total_delay_days, alert_triggered) is inferred from the implementation. LLMs cannot reliably parse or chain results without documented output types.
No error handling or recovery guidance. If historical_delays_days is an empty list or contains invalid data, the tool silently defaults via max(1, len(...)); no validation or error message informs the LLM of the constraint. Tool should document edge cases and return clear errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | 2026-07-28+ | v2 |
Parameter descriptions are present but lack actionable detail. 'historical_delays_days' says 'List of historical delay values in days' but does not specify: range of acceptable values, what happens if the list is empty, whether negative delays are valid, or how many items are typical. LLMs may pass invalid data.
Tool name 'audit_lead_time' is slightly ambiguous. Does 'audit' mean validate, calculate, or review? A clearer name like 'calculate_supplier_delay_alert' or 'check_supplier_restock_alert' would make intent obvious without reading the description.
Magic number alert threshold (3.0 days) is hardcoded in the implementation and not configurable. The description does not mention this threshold, so LLMs cannot explain to users why an alert was or was not triggered. If the threshold needs to change, the tool must be redeployed.