Loading ToolBench
Three tools with basic schemas and descriptions, but significant gaps in parameter documentation, output schema clarity, and error handling. Tool names follow verb_noun convention (good), but descriptions are minimal (avg 40 chars, well below 194-char baseline). No parameter descriptions for any inputs. Output is unstructured text rather than typed objects. No error recovery guidance. Missing pagination for list operations. Schemas present but sparse.
Create a new repair request (only for customers).
Fetch all repair requests.
View details of a specific repair request.
All parameters lack descriptions. 'serial_number', 'description', 'request_id' have no guidance on format, constraints, or purpose beyond the name itself. LLMs cannot infer whether request_id is a UUID, integer, or string.
Tool descriptions are too brief (30-40 chars vs 194-char baseline). 'Fetch all repair requests' lacks context on when to use it, what it returns, or whether results are paginated. No guidance on expected output structure.
Output is unstructured plain text (string return type). LLMs cannot parse 'ID: 123 | Device: ABC | Status: open' reliably. Should return structured JSON with typed fields (id, device_serial_number, status, etc.) for downstream tool chaining.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
view_all_requests has no pagination (limit, offset, page_size). If the backend returns 1000+ repair requests, the entire list is returned as a single string, blowing context window. No total count or next_cursor.
Error handling returns raw strings ('Error contacting backend: ...') with no recovery guidance. LLM cannot determine if error is retryable, user-fixable, or fatal. No actionable next steps.