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 missing entirely (no docstring visible in registration). Output schema is inferred from response structure but not formally documented. No error handling guidance. Naming is acceptable but lacks context about when/why to use this tool. This server demonstrates minimal production-grade tooling practices.
Tool 'add' has no description. LLMs cannot determine when or why to select this tool without a docstring explaining its purpose, when to use it, and what it returns.
Parameters 'a' and 'b' have null descriptions. The rubric requires every parameter to have a non-empty description explaining what it controls. LLMs cannot infer parameter meaning from names alone.
Output schema is not formally documented. The tool returns {content: [{type: 'text', text: string}]} but this structure is not declared in a schema definition visible to the LLM.
No error handling or recovery guidance. If the tool fails (e.g., invalid input types), there is no mechanism to tell the LLM what went wrong or how to retry.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
Tool name 'add' is generic and lacks context. A more descriptive name like 'add_numbers' or 'calculate_sum' would clarify intent and help LLMs distinguish this tool from others.