Loading ToolBench
All 4 tools have basic schemas and descriptions, but quality is well below production baseline. Descriptions are extremely terse (10-50 chars vs. 194-char baseline). No parameter descriptions at all, LLMs cannot infer what 'selector' or 'text' mean without context. Schemas lack type annotations on parameters (all are bare strings with no format/pattern constraints). No output schemas documented. Error handling is minimal, tool failures return raw exception messages instead of actionable recovery guidance. No idempotency hints, no permission gates, no rate limiting. Tools are well-named (verb_noun pattern), but lack the depth needed for reliable agent use.
Click an element by CSS selector
Fill a form field
Retrieve the first 1000 characters of the page text
Open a URL in the browser
No parameter descriptions. 'selector' and 'text' parameters lack any explanation of format, constraints, or examples. LLMs cannot infer whether 'selector' expects CSS, XPath, or a label string.
Tool descriptions are extremely terse (10 - 50 chars vs. 194-char baseline). 'Open a URL in the browser' and 'Click an element by CSS selector' lack context on when to use each tool, what happens on failure, or prerequisites (e.g., must open_url before click).
No output schemas documented. Callers cannot predict the structure of results (e.g., does open_url return 'title' and 'url', or something else?). This forces LLMs to guess and breaks tool chaining.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2026-07-28+ | v2 |
Error handling returns raw exception messages ('Unknown tool: {name}') instead of actionable recovery guidance. LLMs cannot determine if an error is retryable, user-fixable, or fatal.
No idempotency hints or confirmation steps for destructive operations. 'click' and 'fill_form' modify page state but lack warnings or dry-run support. Agents cannot safely retry on ambiguous failures.