Loading ToolBench
A Kanban board with MCP server integration for AI-assisted task management
Viban demonstrates solid fundamentals with 9 tools all explicitly registered with Zod schemas and clear descriptions. Tool names follow verb_noun convention (get_*, create_*, update_, move_*, delete_*, complete_*). All tools have input schemas with enum constraints for categorical parameters. Descriptions are present and contextual (range 50-150 chars). However, there are consistent gaps in schema completeness and output documentation. Output schemas are NOT documented, tools return unstructured JSON strings rather than typed content objects. Parameter descriptions lack actionable constraints (e.g., 'Task ID' provides no guidance on format). Error handling is present but minimal, errors return isError flag with bare text messages without recovery guidance. No batch operations despite several write tools that agents would naturally call in loops. Tools like move_task and move_to_review have overlapping responsibilities. Security and audit logging are absent. Overall, this is a well-structured starter implementation that meets DEFINITION basics but lacks the polish and operational completeness of production-grade tools.
Mark a task as done - move it to the DONE column
Create a new task on the Kanban board
Delete a task from the board
Get statistics about the Kanban board (task counts per column)
Get all tasks from the Kanban board, optionally filtered by column
Get all tasks in the TODO column - these are tasks ready to be worked on
Move a task to a different column
Output schemas completely undocumented. All tools return unstructured JSON strings (type: 'text') instead of typed ContentBlocks. LLM cannot parse responses structurally or plan downstream tool calls with confidence. Example: create_task should return {id, title, description, column, priority, createdAt} as structured content, not a JSON string.
No error recovery guidance. Error responses return isError: true with plain text (e.g., 'Error: Task with ID xyz not found') without actionable next steps. Per pattern:recovery-guide, errors must guide the LLM, e.g., 'Task not found. Available task IDs: [list]. Call get_tasks() to discover valid IDs.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Move a task from TODO to REVIEW - use this when you have completed work on a task
Update an existing task properties
Overlapping tool responsibilities. move_task (with column='done'), complete_task, and move_to_review all move tasks between columns. LLM must reason about which to call for the same semantic intent. Per pattern:tool, each tool should do exactly one thing. Consolidate or clearly document exclusive use cases in descriptions.
Delete operation lacks irreversibility safeguard. delete_task has no confirmation or dry-run step. Per pattern:confirmation-request, destructive operations should support confirmation before execution to prevent agent mistakes. Add a confirm_delete_task tool or a 'dryRun' parameter.
Parameter descriptions lack actionable constraints. 'Task ID', 'New title', 'New priority' provide no format guidance. Per pattern:constrained-input, descriptions should state: 'Task ID (UUID format)', 'Title (1-255 chars)', 'Priority (low|medium|high)'. This prevents LLM-generated invalid input.
Duplicate functionality not justified. get_todo_tasks(column=undefined) returns tasks where column='todo', which is identical to get_tasks(column='todo'). Per pattern:tool, avoid multiple tools doing the same thing. Remove get_todo_tasks or document why it exists (e.g., common query optimization).
No pagination support documented. get_tasks and get_board_stats return all results with no limit, offset, or cursor. Per pattern:paginated-result, tools returning lists should accept limit/offset and return total count. Without pagination, large boards blow context window.
Idempotence not guaranteed or documented. Moving a task to its current column, or 'completing' an already-done task, behavior is unspecified. Per pattern:idempotent-operation, agents retry on failures; non-idempotent operations risk duplicate side effects. State whether repeated calls with the same input are safe.
No batch operations for write tools. If an agent needs to create 10 tasks or move 5 to review, it must call create_task/move_to_review 10 - 5 times sequentially. Per pattern:tool (composition), batch variants (e.g., create_tasks with array input) waste fewer tokens and latency. Add batch_create_tasks, batch_move_tasks, etc.
No audit logging or security scoping. Tools lack permission checks, audit trails, or scope declarations. Per pattern:audit-trail and pattern:scope-declaration, each tool should log who called it, when, and what happened. Implement server-side logging of all mutations and access control gates for destructive operations.