A task management and board collaboration server with MCP (Model Context Protocol) integration, supporting task planning, board management, and team collaboration features.
This MCP server exposes 16 tools for task/board management via HTTP. Tool naming is consistently verb-noun style (get_, create_, add_, invite_, transfer_) which is good. However, definitions have significant gaps: many parameter descriptions are minimal (1-10 words), output schemas are not documented, and error handling guidance is absent. The server uses the @nuxtjs/mcp-toolkit and properly registers tools via HTTP endpoints, but lacks LLM-optimized descriptions that explain WHEN to use each tool and what happens next. Parameter enums are present for status and priority fields, which is correct. Overall, this is functional but below production quality, descriptions need expansion, output schemas must be documented, and error recovery paths must be explicit.
Add a tag to a task. Returns the link if it already exists.
Add a tag to a specific task by task ID
Create a new board with default tags (Bug, Feature, Improvement, Documentation, Question) and add the creator as the owner
Create a new tag for a board with a name, color, and icon
Create a new task on a board. Automatically assigns the next board task ID and optionally records the action in board events.
Get columns for a board, creating default columns if none exist (Backlog, To Do, In Progress, Review, Done)
Get board-specific or global instructions (agent_instructions, task_workflow). Returns board-specific instructions if available, otherwise falls back to global instructions.
Duplicate tools: add_task_tag (#8) and add_task_tag_by_id (#9) perform identical operations with identical parameters. Both add a tag to a task. This forces LLMs to reason about which to call and invites wrong-tool-selection errors.
Output schemas not documented for any tool. Tools return data but responses lack schema definitions, LLMs cannot plan downstream calls or extract needed fields. Example: get_boards says it returns boards with 'membership metadata' but structure is undocumented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Get all members and pending invitations for a board. Returns members with roles and email information, and a list of pending invitations.
Get all tags for a board
Get all task-tag relationships for tasks in a board
Get all tasks for a board with optional filtering by status and search query. Supports pagination with limit and offset.
Get all boards that the current user is a member of, with membership metadata including last visited time and favorite status
Get global instructions that apply across all boards
Get all pending board invitations for the current user
Invite a user to a board by email. Only the board owner can invite members. Sends an invitation email to the specified address.
Transfer board ownership to another user via email. Only the board owner can initiate a transfer. Sends notification emails to both sender and recipient.
Error handling and recovery guidance absent. Tools provide no error messages guiding LLMs on what to do if a call fails (invalid email, user not found, permission denied, resource conflict). Example: invite_board_member has no documented error cases.
Irreversible operation (transfer_board_ownership) lacks confirmation/dry-run pattern. Transferring ownership is permanent and cannot be undone in-tool. No confirmation step or dry-run documented, risks agent accidentally transferring ownership.
Minimal descriptions for discovery tools. get_global_instructions (8 chars), get_board_tags (6 chars), below the 20-char minimum for actionable descriptions. LLMs cannot determine why or when to call these.
Pagination not documented for get_board_tasks. Tool accepts limit and offset parameters but response structure (total count, next_offset, has_more) is not documented. Large result sets could exhaust context window.