Loading ToolBench
MCP server for managing projects and todos with create, read, update, and delete operations
Project Planner demonstrates basic MCP competence with 9 tools covering a coherent project/todo domain. All tools have registered names, descriptions, and input schemas using Zod. However, the server has significant gaps in output schema documentation, error messaging quality, and parameter descriptions. Naming follows verb_noun conventions consistently (create_project, list_projects, get_project, delete_project, create_todo, update_todo, delete_todo, get_todo, list_todo). Descriptions are present but minimal (7-50 chars), barely meeting the 10-char floor. Parameter descriptions exist but are generic ('Project Id', 'Todo title') without format/constraint details. No pagination support on list operations despite potential for large datasets. Error handling throws raw JavaScript Error objects without recovery guidance. Output schemas are not documented, callers cannot predict response structure. This is a functional but rough implementation; it would benefit from enriched parameter documentation, output schema declarations, and LLM-friendly error messages.
Create a project
Create a new Todo in a project
delete a specific project and its todos
Delete todo from a project
Get a specific project by id
Get a specific todo by Id
List all Projects
List all todos by specific project Id
Output schemas not documented. Tools return raw JSON via {content:[{type:'text',text:JSON.stringify(...)}]} without specifying what fields exist in the returned object. LLMs cannot plan downstream calls or extract relevant data without explicit schema documentation.
List operations (list_projects, list_todo) lack pagination support. No limit, offset/page, or cursor parameters. No documented result count or max return size. Risk of context window exhaustion if projects/todos grow large. Violates pattern requirement that list tools support pagination.
Error messages lack recovery guidance. Examples: 'Project with this id:${projectId} Not Found' and 'Todo with this id:${todoId} Not Found' tell the LLM nothing about next steps. Should include recovery guidance like 'Try list_projects() to find valid project IDs' or available alternatives.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Update a todo's properties
Parameter descriptions are minimal and lack constraint details. E.g., 'Project Id' does not specify format (UUID, alphanumeric, etc.). 'Todo title' does not state length limits. 'Todo status' enum values are documented in schema but not in the description text itself. LLMs rely on descriptions to understand constraints, not JSON Schema introspection.
Destructive operations (delete_project, delete_todo) lack confirmation mechanism. No dry-run, no confirmation step. Agents can irreversibly delete data without safeguards. Violates pattern:confirmation-request.
Tool descriptions are too short (7-50 chars; baseline is 194 chars). 'Create a project', 'List all Projects', 'Get a specific project by id' lack context about when to use each vs. similar tools, what data is returned, and prerequisite information. LLMs struggle with minimal descriptions to disambiguate tool selection.
get_project returns both project and todos in a single response, combining two distinct concerns. Consider whether a separate list_project_todos tool would be clearer, or document in get_project description that it always includes todos.
No error classification or categorization. Errors are raw JavaScript Error throws. LLM cannot distinguish retryable (transient) errors from user-fixable (invalid ID) or fatal (permission denied) errors, so it cannot make intelligent recovery decisions.