Loading ToolBench
MCP server for task management with Redis backend supporting create, read, update, delete, and complete operations
This server has 5 tools with explicit schemas and descriptions, but quality is inconsistent. Tool names follow verb_noun convention (good), but descriptions are overly terse and lack actionable guidance. Parameter descriptions are present but sparse. Most critically, error handling is absent, tools return generic success messages without structured data, making it hard for LLMs to extract values for chaining. Output schemas are completely undocumented. The task manager implementation uses ambiguous search-by-name lookups (see update_task and delete_task) instead of requiring IDs, which invites collision bugs and silent failures. Baseline median for servers like this is 45-55; this lands at the higher end due to complete schemas and readable descriptions, but quality gaps prevent a higher score.
Mark a task as complete by searching for it by name
Create a new task with optional description, due date, and priority
Delete a task by searching for it by name
Get a list of tasks with various filters
Update an existing task by searching for it by name and then updating it
Output schemas completely undocumented. Tools return plain text messages ('Task created successfully', 'Task not found') instead of structured JSON with task IDs, timestamps, and state. LLMs cannot extract values for downstream calls or verify success.
Error handling absent. No structured error responses, no recovery guidance. A task not found returns plain text 'Task not found' instead of a structured error with suggestions. LLMs cannot reason about failure modes.
Ambiguous search-by-name lookups. delete_task, complete_task, and update_task accept task names (free-form strings) and search for matches. Multiple tasks with identical names will silently select the first match, risking wrong deletions or updates. Should require explicit IDs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
get_tasks filter parameter is vague. Description says 'Natural language filter like today, tomorrow, next week, priority 1, overdue' but implementation does not parse or validate these. The code just passes the filter to GetTasks() which appears to ignore it (placeholder implementation). LLMs will pass natural language but get no filtering.
Parameter descriptions lack format/range guidance. Due date parameters (due_string, due_string in update_task) require RFC3339 format but the description only hints at this. The update_task description says 'natural language like tomorrow, next Monday' which contradicts the create_task requirement for RFC3339, inconsistent API surface.
update_task has redundant and conflicting parameters. Schema includes both 'id' and 'task_name' and 'content', three ways to identify a task, unclear which takes precedence. The description says 'searching for it by name and then updating it' but the ID parameter suggests ID-based updates should work. Ambiguous API invites misuse.
No pagination or result limits documented. get_tasks has a 'limit' parameter (default 10) but the description does not explain what happens if there are more results. No 'next_cursor' or 'total_count' in the response. Large task lists will truncate silently.
Tool descriptions are terse (under 100 chars). They state WHAT but not WHEN or WHY. E.g. 'Get a list of tasks with various filters' does not explain the expected use case or when to call it instead of other tools. LLMs need context for tool selection.
No input validation documented. create_task requires 'content' but no minimum length is specified. Priority enum is [1,2,3,4] but descriptions do not map these to labels (normal, medium, high, urgent). LLMs and users lack guidance on valid ranges.