Loading ToolBench
A Kanban board MCP server written in Go that provides tools for managing tasks, projects, and progress tracking
Three tools with well-structured schemas and detailed descriptions. board_get and progress_history have comprehensive parameter documentation with enums, ranges, and clear use cases. progress_set includes good guidance on append-only semantics and backward estimation. However, output schemas are not explicitly documented in the source, only input schemas are visible. Error handling guidance is absent. Tool names follow verb_noun convention but lack action clarity (board_get vs get_board). No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles.
Read the board. Compact text by default — about 1,000 tokens for 30 active tasks, roughly 90% smaller than the same board as indented JSON, so it is cheap enough to call at the start of every session. structuredContent is always full JSON.
Read the full progress-mark history behind one metric: a project's manual estimate (project only) or one task's summary estimate (task). This is the same append-only calibration history progress_set writes — nothing here is averaged, rounded or decimated, so a revision like 70% rolled back to 45% is visible exactly as it happened, in the order it happened. Specify exactly one target: either `task` (e.g. KANB-3) to read one task's history, or `project` (e.g. KANB) to read the project's own manual history. Returns `data.marks[]` in chronological order (oldest first) — each with its assessor, percent, timestamp and eta forecast if one was given — plus `data.total`, the full mark count before the `limit` cap.
Record a progress assessment and completion forecast for a task or an entire project. Provide periodic assessments as work proceeds (e.g. every few steps or significant discoveries), not just at the start or finish. Progress marks form an append-only calibration history: revisions never overwrite prior marks. Overestimating and underestimating are expected and harmless; rolling your progress estimate backward (e.g. from 70% down to 45%) is a normal and valuable signal reflecting discovered complexity, not an admission of defeat. Specify exactly one target: either `task` (e.g. KANB-3) to assess a specific task, or `project` (e.g. KANB) to assess the project as a whole. `eta` is an RFC3339 timestamp forecasting the expected finish date and time (e.g. 2026-09-12T18:00:00Z), not a remaining duration. Returns `data` containing the recorded mark and the updated summary progress for the assessed scope.
Output schemas not documented. Input schemas are complete, but response structures (data.marks[], data.total, etc.) are described only in prose. LLMs cannot reliably extract fields from undocumented responses.
No error handling guidance. Tools lack descriptions of failure modes, recovery steps, or actionable error messages. E.g., what happens if task key is invalid? What should the LLM do?
Tool annotations missing. progress_set is destructive (WRITE risk), progress_history is read-only, but neither declares idempotentHint or readOnlyHint. Agents cannot infer retry safety.
Naming inconsistency: board_get vs progress_history vs progress_set. First tool uses get_X pattern; others use X_verb. Standardize to verb_noun (get_board, get_progress_history, set_progress).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2025-06-18+ | v2 |
Mutually exclusive parameters not enforced in schema. progress_history and progress_set both require 'exactly one of task or project' but this is only documented in prose, not in JSON Schema (no oneOf constraint).