Loading ToolBench
MCP server with OAuth authentication and a simple arithmetic tool
Single tool 'add' has critical definition gaps. Input schema present with Zod types (a, b as numbers) but parameter descriptions are null, violates the requirement that every parameter needs a description. Tool description is completely missing (null/empty). No output schema documented. The tool performs a simple arithmetic operation but lacks the LLM-facing metadata needed for proper tool selection and invocation.
Tool 'add' has no description. LLMs cannot determine when or why to select this tool without a description explaining its purpose, when to use it, and what it returns.
Input parameters 'a' and 'b' have null descriptions. Rubric requires every parameter to have a non-empty description explaining what it controls. LLMs cannot infer parameter meaning from names alone.
No output schema documented. Tool returns text content but LLMs need to know the structure of the response (fields, types) to plan downstream calls and extract data correctly.
Tool name 'add' lacks action verb prefix. Rubric baseline shows 90% of A+ tools start with action verbs (get_, create_, update_, etc.). 'add' is ambiguous, does it add numbers, add items to a list, or add a record? Consider 'calculate_sum' or 'add_numbers'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 32 | 2026-07-28+ | v2 |
No error handling guidance. If inputs are invalid (non-numeric, NaN, Infinity), the tool should return actionable error messages telling the LLM what went wrong and how to recover.