Loading ToolBench
Remote MCP server example with OAuth authentication
Single tool 'add' has a basic schema with typed parameters (number, number) and minimal description. Description is only 27 characters, below the 50-200 char LLM-optimized baseline. No parameter descriptions provided; LLMs cannot infer what 'a' and 'b' represent beyond their type. No output schema documented. No error handling guidance. Tool is trivial (arithmetic) and does not reflect production patterns. Naming is generic ('add') rather than verb_noun with context.
Adds two numbers together
Tool description is 27 characters, too short to guide LLM selection. Should be 50 - 200 chars explaining what the tool does, when to use it, and what it returns.
Parameters 'a' and 'b' lack descriptions. LLMs cannot infer that these are operands for addition. Every parameter must have a non-empty description.
No output schema documented. LLMs need to know the response structure (e.g., returns {result: number}) to plan downstream calls and extract results.
Tool name 'add' is generic and lacks context. Consider 'add_numbers' or 'calculate_sum' to be more explicit and self-documenting.
No error handling guidance. If inputs are invalid (non-numeric, NaN, Infinity), the tool should return a clear, actionable error message.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |