Loading ToolBench
A Model Context Protocol server implementation for Dart task management system
Dart server has 6 tools with basic names and descriptions, but significant quality gaps across the rubric. Tool names follow verb_noun convention (get_, create_, update_), which is a baseline positive. Descriptions exist but are minimal (14 - 40 chars), below the 50-200 char target for LLM-optimized clarity. Input schemas are present with JSON Schema structure, but parameter descriptions are sparse or generic. Output schemas are not documented, the code does not show what these tools return, making it impossible for agents to plan chaining. Error handling is minimal; no recovery guidance, categorization of error types, or actionable error messages visible in the code. The tool set covers basic task management (create_task, update_task, get_default_status, get_default_space, get_dartboards, get_folders), but lacks critical discovery tools (list_tasks, search_tasks) and composition helpers (get_task_by_id). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite having both READ_ONLY and WRITE operations. Security: dotenv is used to load DART_TOKEN from environment, which is good; however, the token is later referenced in spawn() child process setup, increasing leak risk if process args are logged.
Create a new Dart task
Get all dartboards in a space
Get the default space DUID
Get the default status DUIDs
Get all folders in a space
Update an existing Dart task
Output schemas not documented for any tool. Agents cannot know what fields to expect, how to chain tools, or what IDs to extract for downstream calls. This is a critical blocker for agent composition.
Descriptions are too short (14 - 32 chars; baseline 50 - 200 chars). Lack actionable context: when to use each tool, prerequisites, and what the agent should expect. LLMs struggle to disambiguate tools with minimal descriptions.
No parameter enums or validation hints. 'priority' parameter in create_task and update_task accepts free-form strings with no guidance on valid values (e.g., low|medium|high|urgent). Agents will hallucinate invalid priorities.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 29 | - | v1 |
No pagination or result limiting for 'get all' tools (get_dartboards, get_folders). 'Get all' without limits can return thousands of items, exhausting context windows. No pagination parameters (page, limit, cursor) visible.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools marked READ_ONLY or WRITE in metadata, but not in schema, agents cannot statically determine which tools are safe to retry without re-executing.
No error handling guidance visible in tool definitions. No recovery hints, error categorization, or actionable error messages. Agents receive generic failures with no next steps.
Missing critical discovery tools. No list_tasks, search_tasks, or get_task_by_id. Agents cannot discover or retrieve individual tasks, only get defaults and create/update. Incomplete domain coverage.
Parameter descriptions are generic labels ('Title of the task', 'Priority level of the task') rather than actionable guidance. No format hints, constraints, or examples (e.g., 'Priority: one of low|medium|high|urgent').
No indication of size parameter constraints in create_task/update_task. Is size a numeric estimate (1 - 100)? Can it be a string? What units? No bounds or format guidance.