Loading ToolBench
A todo list management service for TickTick/Dida365 that provides project and task management capabilities via MCP tools.
Server provides 12 tools with mostly consistent naming (verb-noun patterns) and structured schemas, but has critical gaps in parameter documentation, output schema clarity, and error handling guidance. All tools have descriptions (10-120 chars average), but most descriptions lack context about WHEN to use the tool versus alternatives, prerequisites, and return value structure. Input schemas are present but inconsistently detailed, many parameters lack explicit descriptions in the schema (embedded in tool descriptions instead). No documented output schemas, no error classification, no recovery guidance. Tools are read/write/destructive but lack confirmation or dry-run patterns. This is a borderline D+/C- server, better than mediocre due to naming consistency, but held back by incomplete schemas and missing operational patterns.
Complete a task.
Create a project(collection of tasks).
Create a task in a project.
Delete a project(collection of tasks).
Delete a task.
Filter the tasks in a project. Return only those tasks for which **all** filter expressions match.
get a project details by id, no tasks included.
Destructive operations (delete_project, delete_task) lack confirmation/dry-run patterns. No guidance on recovery if user accidentally deletes the wrong resource.
No documented output schemas for any tool. LLMs cannot predict return structure, forcing trial-and-error for downstream tool chaining. E.g., create_task response structure is not documented, does it return task_id, id, or something else?
Parameter descriptions are sparse or missing in JSON schemas. E.g., filter_project_tasks has 'filter_fields' array but no explanation of syntax (e.g., what operators are valid? how to combine filters?). Descriptions exist in tool docstrings but not in schemas where LLMs parse them.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 22 | - | v1 |
Get a project(collections of tasks) details and a list of tasks in the project. Note the tasks might be very long, use filter_project_tasks to filter out the task you need.
Get a list of all Projects(collections of tasks). The inbox contains all tasks that are not allocated to any project.
Get a task by id.
Update a project(collection of tasks).
Update a task in a project.
Tool descriptions lack context about WHEN to use vs. alternatives. E.g., get_project_by_id vs. get_project_details, both retrieve projects, but differences are unclear to LLMs. Descriptions should state 'Use this to fetch lightweight project metadata; use get_project_details if you need task lists.'
No error classification or recovery guidance. APIClient._make_request() returns {'error': str(e)} on failure, but tool descriptions don't explain what errors are possible or how to recover. E.g., 'If task not found, try get_project_details to list available tasks.'
Tool descriptions do not declare risk/permission levels. E.g., delete_project, delete_task, and update_task modify state, but descriptions lack warnings. LLMs should know 'This operation is destructive and cannot be undone.'
filter_project_tasks filter syntax is poorly documented. Description says 'operators like ==, !=, >, <, >=, <= with date keywords (today, tomorrow, yesterday) or ISO format dates' but no examples or BNF grammar. LLMs will struggle to construct valid filters.
create_task and update_task accept 'priority' as integer (0, 1, 3, 5) but no enum constraint in schema. Descriptions provide the mapping, but LLMs should infer valid values from schema enums, not descriptions.
Tool names 'get_projects' and 'get_project_by_id' are similar but serve different purposes (list vs. fetch one). Description clarity alone doesn't prevent LLMs from conflating them. Consider 'list_projects' + 'get_project' to match common naming conventions.