Loading ToolBench
Cross-project work tracking, changelog, and release tooling for Claude Code. Exposes tracking operations as MCP tools for managing items, checkpoints, notes, changelog entries, and session handoffs.
dct demonstrates solid tool design with 26 well-named, verb-prefixed tools covering a coherent domain (work tracking, sprints, handoffs). All tools have descriptions (avg ~120 chars) and input schemas with typed parameters. However, output schemas are undocumented, responses are described in prose (list_* return {cols, rows} format) but not formally specified in tool definitions. Parameter descriptions are present but often terse (avg ~50 chars), lacking actionable constraints and format guidance. Error handling is minimal, no recovery guidance or categorization visible. Security considerations (secret injection, audit trails) are absent from the code sample. Composition is strong: tools chain well (e.g., create_item → add_checkpoint → complete_checkpoint), and IDs are normalized (#42, ITEM-42, etc.). Overall: good naming and structure, but output schemas and error handling need formalization.
Add a changelog entry for shipped work
Add an acceptance criterion (checkpoint) to an item
Add an append-only note to an item
Add a new tag to the global dictionary
Assign an item to a specific sprint
Mark a checkpoint as done
Mark a handoff as consumed (read), preserving the row
Output schemas undocumented. Tool descriptions state response format in prose ('returns {cols, rows}') but formal JSON Schema output definitions are absent. LLMs cannot reliably parse or chain responses without explicit field documentation.
Parameter descriptions lack actionable constraints. E.g., 'priority' accepts 'P1|P2|P3|future' but description does not state enum values. 'source_lines' accepts ranges but format is not specified. LLMs cannot validate inputs without explicit constraints.
No error handling guidance. Tools return errors but recovery paths are not documented. E.g., if 'project' auto-detect fails, what should the LLM do? If a tag name is unknown, which tags are available? No recovery_guide pattern implemented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2026-07-28+ | v2 |
Count unreleased changelog entries for a project
Create a handoff (cross-session prompt) for next session
Create a new item (feature/todo/issue/idea/improvement)
Mid-session snapshot: current sprint, open items, unconsumed handoffs, unreleased changelog. Composed workflow op.
Fetch a single handoff with untruncated prompt + context_summary
Fetch a single item with full context (notes, checkpoints, progress)
Session end with unfinished work: set sprint + create handoff atomically. Composed workflow op.
List session handoffs (cross-session prompts). Returns {cols:[...], rows:[[...]]} format. Columns: id, scope, created_by, created_at, consumed_at, prompt (200-char preview)
List items with optional filtering. Returns {cols:[...], rows:[[...]]} format. Columns: id, item_type, priority, status, in_current_sprint, cp=[done,total], component, tags, created_at, title, description
List all registered projects
List all global (cross-project) tags
Merge one tag into another (rename/consolidate)
Session start: snapshot + consume the handoff (full prompt) in one call. Composed workflow op.
Mark a checkpoint as rejected (irrelevant)
Resolve an item (mark as resolved/wont_fix). Clears the derived in_current_sprint flag but retains sprint membership as completion history.
Session dashboard: current sprint status, items, checkpoints, progress
Atomically replace the current sprint with a new set of items
Update item fields (title, description, priority, status, component, tags, source_file, source_lines)
Update sprint lifecycle (planned|active|deferred|completed|abandoned)
Minimal parameter descriptions for discovery tools. list_projects, list_tags, count_unreleased_changelog have descriptions under 20 chars or are missing entirely. LLMs cannot determine when to call these tools.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Agents cannot distinguish safe reads from destructive writes without explicit hints. resolve_item, delete operations should be marked destructive.