Loading ToolBench
A simple MCP server for managing a todo list with in-memory storage
Four tools with complete schemas and descriptions, but descriptions are in Chinese (non-standard for LLM optimization), lack actionable context, and are too brief (avg 12 chars). No parameter descriptions beyond names. No output schemas documented. No error recovery guidance. Tools lack idempotency hints and destructive operation warnings. Schema definitions are present but minimal. No tool annotations (readOnlyHint, destructiveHint). Naming is verb-first and clear (add_, get_, update_, delete_), which is good, but descriptions do not explain WHEN to use each tool or what happens on retry.
新增一個待辦事項
刪除一個待辦事項
取得所有待辦事項
更新待辦事項的完成狀態
Descriptions are in Chinese and extremely brief (avg 12 chars). LLMs expect English descriptions of 50-200 chars explaining WHAT, WHEN, and WHY. Current descriptions ('新增一個待辦事項' = 'Add a todo item') lack context for tool selection and error recovery.
No output schemas documented. Callers cannot predict response structure. add_todo returns text; get_todos returns formatted text; update_todo and delete_todo return text. Structured JSON responses with typed fields (id, title, completed, createdAt) would enable downstream tool chaining and reduce LLM parsing errors.
No tool annotations. delete_todo is destructive but lacks destructiveHint. get_todos is read-only but lacks readOnlyHint. update_todo is idempotent but lacks idempotentHint. Annotations guide agent retry logic and safety policies.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | <=2025-11-25 | v2 |
Error handling returns raw error strings ('找不到待辦事項' = 'Todo not found') with no recovery guidance. Per pattern:recovery-guide, errors should suggest next steps: 'Todo ID not found. Call get_todos() to list available IDs.'
No idempotency guarantees documented. add_todo uses time.Now().UnixNano() for ID generation, which is unique per call but not deterministic. If an agent retries after a network timeout, a duplicate todo is created. Idempotent operations should return the same result on repeated calls with identical input.