Loading ToolBench
An MCP server for managing Taskwarrior tasks. Enables adding, listing, searching, modifying, and annotating tasks with support for projects, filters, priorities, due dates, tags, and wait/scheduled dates.
Taskwarrior MCP demonstrates solid definition quality with comprehensive, well-structured schemas and detailed parameter descriptions. All 8 tools are properly registered with schemars::JsonSchema-derived input schemas visible in the source code. Tool names follow clear verb_noun patterns (add_task, list_tasks, complete_task, etc.). Descriptions are substantial and actionable, ranging from 90-850 characters, well above the 10-1024 char baseline. Parameter descriptions are consistently present and detailed, with specific guidance on formatting, constraints, and usage patterns. However, there are notable gaps: output schemas are not documented in the source (tool descriptions mention return types informally but JSON Schema output definitions are absent), error handling guidance is minimal (no recovery hints or error classification visible in schemas), and there are no tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite the server having WRITE, READ_ONLY, IRREVERSIBLE, and DESTRUCTIVE tools. The descriptions are very instruction-heavy (designed for LLM prompt-engineering) which is good but occasionally borders on verbose, e.g., list_tasks description is 850+ chars. No secrets in parameters (good). No batch operations offered for common agent patterns (e.g., no batch add_task). Overall, this is a well-built tool set with excellent parameter clarity but missing the final polish of documented output schemas and proper risk annotations.
Add a new task. `project` is REQUIRED — every task must belong to a project. Supports due dates (today/tomorrow/eow/eom/friday/ISO datetime), tags, dot-notation subprojects (e.g. Work.Backend), priorities (H/M/L), wait dates (hide until actionable), and scheduled dates (when you plan to start).
Attach a timestamped note/annotation to a task.
Mark a task as completed. This is irreversible without manually editing Taskwarrior's data files.
Permanently delete a task. This is irreversible without manually editing Taskwarrior's data files.
Fetch full task details by ID or UUID. UUIDs are preferred for stability — numeric IDs shift after complete/delete.
List tasks sorted by urgency. `project` is REQUIRED. ALWAYS use the most specific `filter` and `report` for your intent — do NOT call with no filter unless you genuinely need every pending task. Quick reference: actionable work → filter='+READY' or report='next'; overdue → filter='+OVERDUE'; due today → filter='+TODAY'; blocked → filter='+BLOCKED' or report='blocked'; high priority → filter='priority:H'; waiting/snoozed → report='waiting'. Only set `all_projects=true` for explicit cross-project requests.
Output schemas not documented. Tool descriptions mention return types informally (e.g., 'Fetch full task details', 'List tasks sorted by urgency') but no JSON Schema output definitions are present in the source or visible to callers. LLMs cannot plan downstream calls or extract fields without knowing the response structure.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk categories. The server defines Risk labels (WRITE, READ_ONLY, IRREVERSIBLE, DESTRUCTIVE) in comments but does not emit them via MCP tool annotations. This forces LLMs to infer risk from descriptions alone, risking misuse of destructive tools.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Modify an existing task. Supports all task fields: due dates, priority, tags, projects, wait/scheduled dates, and more. Clear a field by omitting its value in the modification string.
Search tasks by regex pattern across descriptions and annotations. `project` is REQUIRED and automatically scopes the search. Only set `all_projects=true` for explicit cross-project searches.
Error handling provides no recovery guidance. The server returns McpError::internal_error but does not classify errors (retryable, user-fixable, fatal) or suggest next steps. E.g., if a project does not exist, the error should suggest 'Try create_project() first' rather than a raw error message.
modify_task uses free-form string ('space-separated modification tokens') instead of structured parameters. While well-documented, this approach is error-prone for LLMs and makes validation difficult. A schema with typed fields (due, priority, tags, wait, scheduled, project, description) would be more robust and self-documenting.
No enums for constrained parameters. priority accepts 'H', 'M', 'L' but is defined as Option<String> with no enum constraint. report accepts specific values ('next', 'blocked', 'waiting', 'completed', 'list', 'all') but no enum validation. LLMs may hallucinate invalid values.
No dry-run or confirmation step for irreversible operations. complete_task, delete_task, and modify_task are one-shot with no confirmation gate. Agents can delete critical tasks without asking the user first.
add_task and list_tasks require 'project' parameter but do not provide a discovery tool to list available projects. An agent without prior knowledge of project names cannot construct valid calls. A list_projects or describe_projects tool would be essential.
No pagination support on list_tasks or search_tasks. If a project has hundreds of tasks, list_tasks will return all pending tasks. Description mentions 'expensive' for all_projects=true but does not offer limit or offset parameters to cap results and force pagination.