Loading ToolBench
Setup a Kanban workflow system with MCP server for Claude Code
MCP Kanban has 17 tools with consistent naming (verb_noun pattern) and basic schemas. However, descriptions are minimal (10-50 chars, well below the 194-char baseline), parameter descriptions are sparse or missing, and output schemas are undocumented. Error handling exists but lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint). Composition is reasonable, tools chain via IDs, but descriptions do not guide LLM selection or explain when to use each tool. This is a typical community server: functional but not LLM-optimized.
Add research item to a ticket
Claim a Ready ticket for an agent
Create a new project
Create a new ticket in a project
Get a comprehensive context bundle for a ticket including spec, research, dependencies, and tests
Get all tickets claimed by a specific agent
Get the next available Ready ticket for an agent from a project
Get health analysis of a project
Tool descriptions are 10 - 50 characters, far below the 194-char baseline. LLMs cannot determine when to select each tool or what it returns. E.g., 'Create a new project' lacks context on prerequisites, return value, or when to use vs. other tools.
Output schemas are not documented. LLMs do not know what fields to expect from list_tickets, get_context_bundle, or get_project_health. This forces agents to guess field names and risks extraction errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
Get progress metrics for a project
Get detailed status of a project
Get all tickets with Ready status, optionally filtered by project
Create a dependency link between two tickets
List all projects with optional limit
List tickets with optional filtering by status, priority, and limit
Release a claimed ticket back to Ready status
Update status of an entity (ticket or project)
Update ticket specification with contract, invariants, and acceptance criteria
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish read-only tools (get_*) from write tools (create_*, claim_*) without explicit hints. This risks unsafe retry behavior on destructive operations.
Error messages lack recovery guidance. Test script shows errors are returned, but no evidence that they guide LLMs on next steps (e.g., 'Try search_users() first' or 'Retry with a different status'). Bare error codes are not actionable.
Parameter descriptions are minimal or missing. E.g., 'status' in set_status lacks explanation of valid values; 'token_budget' in get_context_bundle lacks guidance on typical ranges. LLMs cannot infer constraints from names alone.