Loading ToolBench
A Model Context Protocol (MCP) server template for todo management with tools, resources, and prompts
Three tools are registered with schemas and descriptions. Tool naming follows verb_noun convention (create, delete, complete). Descriptions are present but terse (10-40 chars). Parameter schemas are defined but lack depth, no enums for priority despite 'low|medium|high' constraint, no format validation for dueDate, no pagination for results. Output schemas are not documented. Error handling and recovery guidance are absent. The server uses a custom Pikku framework wrapping MCP SDK, making some implementation details opaque, but tool definitions in src/functions are visible.
Mark a todo as complete by ID
Create a todo item with title, optional details, priority, due date, and tags
Delete a todo by ID
Parameter 'priority' accepts enum values (low, medium, high) but is defined as a free-form string with no enum constraint in the schema. LLMs will not restrict themselves to valid values and may pass 'critical', 'urgent', or other hallucinated strings.
Tool descriptions are extremely terse (10-40 characters). 'Create a todo item with title...' is under the 50-char baseline for actionable descriptions. Missing WHEN to use, WHAT it returns, and dependencies. Rubric baseline: 194 chars average for A-grade tools.
No output schema or return value documentation for any tool. LLMs cannot plan downstream calls or extract chaining IDs (e.g., if createTodoTool returns a todo ID, subsequent tools should reference it). Missing documented return types violates A-grade baseline (100% of A+ tools have documented return types).
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 10 | - | v1 |
No error handling or recovery guidance. Tools do not document what happens on failure (e.g., 'todo not found', 'user not found', 'invalid date'), what errors are retryable, or what the LLM should do next. Missing per-tool error classification.
Parameter 'dueDate' is a free-form string with no format constraint. LLMs will pass inconsistent formats (2024-01-15, Jan 15, 1/15/2024, etc). Should declare ISO 8601 format or natural-language constraint in description.
'userId' parameter in createTodoTool defaults to a demo user if not provided. The description ('User ID (uses demo user if not provided)') is present but unclear about the default behavior and when the demo user applies. This non-deterministic default could cause unexpected todos to be created for the wrong user.
No pagination support. If a user has hundreds of todos, tools do not accept limit/offset or return a count. Tools like 'list todos' (if they exist) would have no way to bound results, risking context window exhaustion.
No documented idempotency guarantees. If createTodoTool is retried after a network failure, will it create a duplicate todo or return the existing one? Agents rely on idempotency semantics to safely retry transient failures.
deleteTodo and completeTodo lack confirmation or dry-run capability. Destructive operations (delete) should support a dry-run or require explicit confirmation to prevent accidental data loss when an agent makes a mistake.