Loading ToolBench
An MCP server that provides tools for managing a Kanban board with projects, tickets, comments, and DORA metrics tracking
This server has 7 tools with basic descriptions and input schemas. Most tools have acceptable descriptions (60-100 chars), though several lack depth about when to use them vs. alternatives. All tools have type-annotated parameters, which is good. However, output schemas are entirely absent from the visible code, the tools return raw text strings rather than structured JSON objects. This is a critical gap that forces LLMs to parse unstructured output and prevents downstream tool chaining. Error handling is present but generic (returns error strings without recovery guidance). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. Naming is clear and verb-forward (get_, create_, update_, add_), which is a bright spot. Overall, this is a fair-to-poor server with solid fundamentals but missing critical production patterns.
Add a comment to a ticket in the Kanban board.
Create a new ticket in the Kanban board.
Get the current status of the Kanban board, including ticket counts by state and project.
Look up a project ID by project name using fuzzy, case-insensitive, and typo-tolerant matching.
Get all projects from the Kanban board.
Get all tickets from the Kanban board, optionally filtered by project.
Update a ticket's state in the Kanban board.
No output schemas documented. All tools return raw text strings instead of structured JSON objects. LLMs cannot parse the response format, extract typed fields, or chain results to downstream tools.
Missing tool annotations. No readOnlyHint on read tools, no destructiveHint on write tools, no idempotentHint. LLMs cannot determine which tools are safe to retry or modify state.
Error handling lacks recovery guidance. Errors return strings like 'Error: Project with ID X not found' without suggesting next steps or available alternatives. Per the rubric, errors must tell the LLM what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
get_projects and get_tickets lack pagination parameters. If the board has hundreds of tickets or projects, the tools will return massive unstructured text, blowing context windows and degrading LLM reasoning.
get_projects description is only 'Get all projects from the Kanban board.' (44 chars). Lacks context on when to call this vs. get_project_id_by_name, what fields are returned, or whether it includes ticket counts.
get_kanban_status description is vague ('Get the current status of the Kanban board...') and does not explain what 'status' means (ticket counts by state? Project summaries? Both?). At 93 chars, it is borderline but could be more explicit.
create_ticket has optional parameters (why, acceptance_criteria, test_steps, ticket_type) but does not clearly document what the defaults are or why they are optional. The ticket_type defaults to 2 per code, but the schema description says 'optional, defaults to 2', this is good, but the other optional params lack default documentation.
update_ticket_state only accepts a free-form 'state_name' string parameter instead of an enum. Valid values are documented as 'backlog, in progress, done, on hold' in the code, but the schema should enforce this as an enum constraint. LLMs will hallucinate invalid state names.