Loading ToolBench
Fetch a website and return the content in various formats (HTML, Markdown, plain text, JSON)
Four tools with consistent structure but significant quality gaps. All tools have basic descriptions (40-60 chars, below the 194-char baseline) and identical input schemas. Parameter descriptions are minimal ('Optional headers to include in the request' lacks format/constraint details). No output schema documentation. Error handling returns generic error messages without recovery guidance. Tools lack idempotent/destructive hints. No per-tool validation or actionable error messages.
Fetch a website and return the content as HTML
Fetch a JSON file from a URL
Fetch a website and return the content as Markdown
Fetch a website, return the content as plain text (no HTML)
Descriptions are too short (40-60 chars vs 194-char baseline). 'Fetch a website and return the content as HTML' lacks context for when to use this tool vs fetch_markdown or fetch_txt. LLMs cannot distinguish between similar tools without richer descriptions.
No output schema documented. Callers cannot know what fields to expect (e.g., does fetch_json return parsed object or stringified JSON?). LLMs must guess, risking downstream tool call failures.
'headers' parameter description is vague ('Optional headers to include in the request'). No format guidance, no examples of valid headers, no constraint on header names/values. LLMs cannot reliably construct valid header objects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
Error responses are generic ('Failed to fetch <url>: <message>'). No recovery guidance. LLMs cannot determine if error is retryable, user-fixable, or fatal. No actionable next steps.
No tool annotations (readOnlyHint, idempotentHint). All four tools are read-only and idempotent, but this is not declared. Agents cannot optimize retry logic or understand safety properties.