Loading ToolBench
MCP Server providing kanban tools for AI agents to manage file-based kanban boards using Yurtle (Turtle RDF in Markdown). Enables work item management, status tracking, and board visualization through AI.
Server provides 10 kanban-management tools with mostly complete schemas and descriptions. Tool names follow verb_noun convention (kanban_list_items, kanban_create_item, kanban_move_item, etc.), which is good. Descriptions are present for all tools and range from 54 - 88 characters, meeting the minimum threshold. However, several critical issues reduce the score: (1) Parameter descriptions are present but sparse, many lack actionable detail about constraints, ranges, or formats. For example, 'assignee' is described as 'Filter by assignee name' but doesn't specify whether partial names work or if exact match is required. (2) Output schemas are completely undocumented, the source code shows tool definitions but does not include documentation of what fields/structure each tool returns. This forces LLMs to call tools blind and guess the response format. (3) No error handling guidance, tools lack descriptions of failure modes or recovery steps. (4) No mention of idempotency, confirmation steps for destructive operations, or permission gates. The kanban_create_item, kanban_move_item, kanban_add_comment, and kanban_update_item tools are write operations but lack any note about confirmation or rollback. Per-tool scores average to 62.
Add a comment to a work item.
Create a new work item.
Get all blocked work items.
Get the current kanban board state with all items organized by column.
Get details of a specific work item by ID.
Get work items assigned to a specific person.
List work items from the kanban board. Can filter by status, type, or assignee.
Output schemas completely undocumented. Tool definitions show input schemas but do not document what fields or structure each tool returns. LLMs cannot plan downstream calls or extract required data without guessing response format.
Parameter descriptions lack actionable detail. 'Filter by assignee name' does not clarify if partial names work, if exact match is required, or if the parameter accepts email or display name. Missing constraint documentation forces LLMs to guess valid input formats.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Move a work item to a new status.
Suggest the next highest-priority item to work on.
Update a work item's properties (title, priority, assignee, description, tags). Use move_item for status changes.
Write operations lack error handling guidance and confirmation steps. kanban_create_item, kanban_move_item, kanban_add_comment, and kanban_update_item modify state but provide no guidance on failure recovery, retry logic, or pre-execution confirmation. Agents cannot distinguish retryable errors from user-fixable ones.
No idempotency declaration for write tools. kanban_create_item and kanban_add_comment do not state whether repeated calls with identical parameters will create duplicates or skip silently. Agents need to know if retries are safe.
Pagination not implemented for list operations. kanban_list_items and kanban_get_board return potentially unbounded result sets with no limit, offset, or pagination parameters. Large boards could exceed context windows.
Tool descriptions are generic and do not explain when to use each tool. For example, kanban_get_board, kanban_list_items, and kanban_get_my_items all return items but the descriptions do not clarify the distinction or when an agent should prefer one over the others.