Loading ToolBench
Learning to build a todo model context protocol server.
This TODO server has critical gaps in parameter descriptions and output schema documentation. All 4 tools lack parameter descriptions (null values in schema), violating the baseline that 100% of A+ tools have documented params. Tool descriptions are present but minimal (10-20 chars), below the 50-200 char LLM-optimized range. No output schemas are documented. Error handling is present but generic ('not found' messages lack recovery guidance). The server uses Zod for input validation but does not expose schema details to the LLM context.
Adds new todo
Mark ToDo as complete
Deletes ToDo
Lists all ToDos
All parameter descriptions are null or missing. The 'text' param in add-todo, 'id' params in complete-todo and delete-todo have no descriptions. LLMs cannot infer parameter meaning from names alone.
Tool descriptions are too brief (10-20 chars). 'Adds new todo', 'Lists all ToDos', 'Mark ToDo as complete', 'Deletes ToDo' lack context on WHEN to use each tool, what it returns, and any prerequisites. Baseline for LLM-optimized descriptions is 50-200 chars.
No output schemas documented. Tools return text content but LLMs have no formal schema for the response structure. This forces LLMs to parse unstructured text and guess at field names for downstream operations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Error messages lack recovery guidance. 'To Do item with ID X not found' tells the LLM nothing about what to do next. Should suggest 'Call get-todos to see available items' or similar.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The server marks tools with Risk levels (WRITE, DESTRUCTIVE) in metadata but does not expose these via MCP tool annotations, limiting client-side safety checks.