Loading ToolBench
MCP demo server in Go with stdio and HTTP transport support, featuring utility tools and in-memory todo management
Server has 8 tools with complete input schemas and descriptions. Naming follows verb_noun convention (greet, echo, add, list_todos, create_todo, complete_todo, delete_todo). Descriptions are present but brief (10-50 chars), below the 50-200 char LLM-optimized baseline. All parameters have type definitions and descriptions via jsonschema tags. Error handling is minimal, no recovery guidance or actionable error messages. Output schemas are implicit in struct definitions but not formally documented. Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE) are present but not exposed in tool definitions. No pagination, no batch operations, no idempotency guarantees documented.
Add two numbers
Mark a todo completed or not completed
Create a new todo item
Delete a todo by id
Echo a message back (useful for connectivity checks)
Say hi to someone
Return server health and basic stats
List all todos currently stored in memory
Tool descriptions are too brief (10-50 chars vs. 50-200 char baseline). LLMs cannot determine when to select tools or what they return. E.g., 'Say hi to someone' lacks context on output format, when to use vs. other tools, or prerequisites.
Output schemas are not formally documented. Tool implementations return structured objects (greetOut, echoOut, addOut, etc.) but the MCP tool definitions do not declare expected response fields, types, or structure. LLMs cannot plan downstream calls or extract data reliably.
Error handling lacks recovery guidance. Functions return generic errors (e.g., 'title is required', 'todo not found') without suggesting next steps. LLMs cannot self-correct or plan recovery actions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE) are declared in metadata but not exposed in tool definitions. LLMs cannot see which tools are safe to retry or have irreversible consequences.
No idempotency guarantees or confirmation patterns for destructive operations. delete_todo has no dry-run, confirmation, or undo mechanism. Agents cannot safely retry on ambiguous failures.