Loading ToolBench
MCP server for task and board management, providing tools to read and write tasks, boards, subtasks, and daily summaries via API tokens with scope-based access control.
Server defines 14 tools with consistent naming (verb_noun pattern) and basic schemas. All tools have descriptions (10-50 chars, below ideal 50-200 baseline). Input schemas are present and use Zod validation, but parameter descriptions are minimal or missing. Output schemas are not documented. Error handling exists but lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint). Composition is sound, tools are single-responsibility and chainable via IDs. Security: auth scopes enforced server-side, no secrets in params. Overall: functional but descriptions and output documentation need strengthening.
Create a board for the token owner.
Create a subtask on one of the token owner's tasks.
Create a task on one of the token owner's boards.
Delete one of the token owner's boards.
Delete one of the token owner's subtasks.
Delete one of the token owner's tasks.
Get one owner-scoped board by slug.
Tool descriptions are too short (10-50 chars vs. baseline 50-200). LLMs cannot determine when to select tools or distinguish similar ones (e.g., update_task vs update_board vs update_subtask).
Output schemas are not documented. LLMs cannot plan downstream calls or extract required fields (e.g., what fields does get_board return? Does it include task_ids for chaining?).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe reads from destructive writes without explicit hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Get the token owner's daily task summary.
Get the token owner's dashboard snapshot.
List the token owner's boards.
Update one of the token owner's boards.
Update the note on one of the token owner's boards.
Update one of the token owner's subtasks.
Update scalar fields on one of the token owner's tasks.
Error handling lacks recovery guidance. mcpErrorResult() returns raw error text without suggesting next steps (e.g., 'User not found. Try list_boards() first.').
Parameter descriptions are minimal. 'fields' param in update_task/update_board/update_subtask lacks detail on what fields are updatable or their constraints.