Loading ToolBench
Worktide MCP server — exposes tasks, projects, and time-tracking to Claude and other MCP clients.
Worktide MCP demonstrates solid fundamentals: all 18 tools have clear verb-noun naming (tasks.search, projects.create, time.log), explicit Zod schemas converted to JSON Schema, and consistent descriptions (avg ~120 chars). Tool composition is clean, each tool has one responsibility. However, parameter descriptions are sparse (many lack context on format/constraints), output schemas are undocumented (LLMs cannot predict response structure), and error handling is minimal (generic catch-all returns raw error messages without recovery guidance). No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification. Pagination is present but limit defaults (25 - 50) lack justification. Security is sound (secrets via env vars, no token params), but the server lacks idempotency guarantees and confirmation patterns for destructive ops.
List tasks assigned to the current user, filtered by status (default: open). Useful first-thing-in-the-morning query.
Return the current authenticated user (the holder of the API token).
Set isArchived=true on a project. Reversible via update.
Return the kanban board for a project — one entry per status column with the tasks currently in it. Closed tasks are included.
Create a new project. Number is auto-filled from the workspace pattern if blank.
Fetch a single project by UUID, IRI, or key (e.g. "WORK").
List projects in the active workspace. By default excludes archived projects. Returns name, key, status, customer IRI, dates, and tags.
Output schemas undocumented. LLMs cannot predict response structure (fields, types, nesting). Forces agents to guess what data is available after each call, risking failed downstream tool chains.
Parameter descriptions lack format/constraint details. E.g., 'dueOn' says 'ISO date YYYY-MM-DD' but others (statusIri, assigneeIris) omit format entirely. LLMs cannot validate inputs without explicit constraints.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Server clearly stratifies risk (READ_ONLY vs WRITE vs REVERSIBLE) but does not expose this to clients. Agents cannot distinguish safe from dangerous operations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
Add a dependency between two tasks. type defaults to finish_to_start (classic blocker).
Mark a task as done — finds the workspace's first completed TaskStatus and assigns it.
Create a new task. Project is optional (private task without project).
Fetch a single task by UUID, IRI, or identifier (e.g. "WORK-123").
Search tasks by title (partial match) and optional filters. Returns up to 25 tasks with their identifier, title, status, project IRI, due date, assignees, and tags.
Update task fields. Pass only the fields to change. Set status to a TaskStatus IRI to move the task on the board (PATCHing status is how Drag-and-Drop persists too).
Record a time entry retro-actively. Either provide endsAt OR durationMinutes — the other is computed server-side.
Aggregate time-entries in a date range, grouped by user/project/task/typeOfWork. Returns total minutes plus per-group breakdown.
Get the user's currently running timer (if any).
Start a timer. Either taskIri or projectIri is required (taskIri wins if both); a free-text description is optional.
Stop the running timer and turn it into a TimeEntry.
Error handling returns raw exception messages without recovery guidance. E.g., 'Invalid arguments: ...' or bare error text. LLMs cannot self-correct or know whether to retry, ask user, or abort.
No confirmation/dry-run pattern for destructive operations (tasks.complete, projects.archive, time.stop). Agents can accidentally complete tasks or archive projects without user approval.