MCP server for Cowork Tasks - exposes the task store to the live artifact and the task-extractor agent. A live kanban board for Claude Cowork that auto-creates and tracks tasks from email, meetings, Slack, and issue trackers.
This MCP server has 16 well-defined tools with consistent naming (verb_noun pattern), good descriptions in the 100 - 200 char range, and complete JSON Schema with type and description annotations on nearly all parameters. However, output schemas are entirely undocumented (no response structure or field descriptions returned), error handling guidance is minimal, and several design issues reduce composability. Tools like `clear_artifact_folder` and `delete_task` lack confirmation/dry-run patterns for destructive operations. Descriptions are clear but occasionally lack actionable hints for multi-step workflows (e.g., `is_processed` has no guidance on when to call it before `create_task`). Parameter constraints are specified where needed (enums for priority, minimum for limits), but some tools accept complex polymorphic input (e.g., `create_task` source parameter accepts oneOf string or object) without clear guidance on which form to use when. Schema validation coverage is good but response documentation is the major gap.
Archives a task (soft delete; recoverable).
Checks whether a newer Cowork Tasks release is available upstream. Cached for 6 hours so this is free to call on every open.
Removes a stale artifact folder under the Cowork artifacts directory. Use this when create_artifact fails with "folder already exists" but the artifact is not in list_artifacts (manifest out of sync). Refuses to delete anything outside the provided artifactsDir or any path that does not match a safe id.
Creates a new task on the kanban board. `source` accepts either a URL string or a structured object {type, url, author, title, ...}.
Creates multiple tasks in one batch - used by the triage-now skill so a meeting with N action items lands as a single board update.
Permanently deletes a task (hard delete; irreversible).
Output schemas entirely undocumented. No response structure, field types, or descriptions provided for any tool. LLMs cannot predict what fields to extract or plan downstream tool calls without knowing return signatures.
Destructive operations (delete_task, clear_artifact_folder) lack confirmation or dry-run mechanism. Agents can irreversibly delete tasks without a safety check, increasing risk of data loss.
Polymorphic source parameter in create_task (oneOf string or object) lacks clear guidance on which form to use. LLMs may select the wrong variant, causing parameter mismatch errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2026-07-28+ | v2 |
Retrieves a single task with its full description, checklist, comments and source link.
Retrieves multiple tasks in one round-trip by their ids.
Checks whether a source item (e.g. an email or meeting) has already been triaged into a task.
Returns the board configuration: columns, labels, owners, working hours and triage cadence.
Lists all tasks on the kanban board with their column, owner, priority, labels and source. Pass `since` to receive only changes since that version.
Marks a source item (e.g. an email or meeting) as triaged into a task.
Moves a task to a different column and position - the kanban drag/drop primitive.
Prepares the live kanban artifact HTML with the current board state pre-injected. Returns ready-to-render HTML so the live artifact opens instantly without extra round-trips.
Updates board configuration: columns, labels, owners, working hours and triage cadence.
Updates fields on an existing task: title, description, owner, priority, due date, labels.
create_task and create_tasks accept complex nested objects ('source' with 11 optional fields) without validation error messages documented. If the source format is wrong, LLM has no recovery guidance.
is_processed and mark_processed have no description guidance on when to call them in workflows. LLMs may not recognize the pattern: check first, then mark after create_task succeeds.
list_tasks accepts 'since' cursor and 'limit' parameter but no total count or next_cursor returned. Pagination logic is opaque, LLMs cannot determine when to stop iterating.
Tool descriptions omit state-modification warnings. No clear indication that create_task, update_task, delete_task, archive_task are irreversible or have side effects that agents should consider before retrying.
ifVersion parameter on update_task and move_task is documented as 'optimistic concurrency version' but no guidance on how to obtain it, what happens on mismatch, or recovery strategy.