Loading ToolBench
Configurable Plane planning, work visibility, relations, and lifecycle MCP server
18 tools with mostly complete schemas and descriptions, but significant gaps in error handling, output documentation, and parameter validation. Tool names follow verb_noun convention well (get_, list_, create_, update_, etc.). Descriptions average ~120 chars, meeting baseline (p10=34, p90=392). However, 6 tools lack documented output schemas, and error recovery guidance is minimal. Write operations (create_standard_work_item, update_standard_work_item) include dry_run/confirm patterns (good), but no explicit permission gates or audit trail declarations. Parameter descriptions are present but often generic ('Work item UUID' repeated 5+ times without context on how to obtain it). No tool exposes secrets as parameters (good security baseline). Composition is sound, tools chain well (find_work_items → get_work_item → update_standard_work_item), but some tools combine multiple concerns (e.g., create_standard_work_item handles outcome, scope, criteria, complexity, priority, assignee, module, labels, due_date in one call, 9 parameters, p90=8).
Activate a stored Plane workspace profile by name.
Attach a file to a work item from the local filesystem.
Draft attaching one file uploaded to the current Mattermost message to an existing Plane work item.
Cancel a work item with a factual reason for cancellation.
Mark a work item as completed with a summary and verification details.
Create a new work item in the active Plane project with standardized fields including title, description, priority, complexity, and acceptance criteria.
Output schemas not documented for 6 tools (get_work_item_relations, diagnose_plane_connection, list_profiles, get_project_briefing, get_work_item, find_work_items). LLMs cannot plan downstream calls or extract required fields without knowing response structure.
Error handling lacks recovery guidance. Tools return PlaneWorkflowError but do not tell LLM what to do next (e.g., 'Try search_users() first' or 'Retry with a different project_id'). Agents cannot self-correct.
create_standard_work_item combines 9 parameters (outcome, scope, acceptance_criteria, complexity, priority, assignee_id, module_name, label_names, due_date), exceeds p90=8 and violates single-responsibility principle. Should split into create_work_item + add_acceptance_criteria or similar.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Verify that the configured Plane workspace and API key are valid and accessible.
Ensure a module exists in the active Plane project, optionally creating it if missing.
Find work items by identifier, title, or description using fuzzy matching.
Get a high-level overview of the active Plane project, including its name, description, members, modules, and current work-item statistics.
Get detailed information about a specific work item by its UUID.
Get all relations (dependencies, blocks, duplicates, etc.) for a work item.
List all configured Plane workspace profiles.
List work items in the active Plane project with optional filtering by state, priority, assignee, module, label, or search text.
Set the active Plane project for the current profile.
Create or update a relation between two work items (blocking, blocked_by, duplicate, relates_to, start_before, start_after, finish_before, finish_after).
Mark a work item as started by moving it to the started state.
Update a work item with new values for title, description, priority, complexity, assignee, module, labels, or due date.
Parameter descriptions are generic and repetitive ('Work item UUID' appears 5+ times without guidance on how to obtain it). Should include dependency hints like 'Obtain from find_work_items() or get_project_briefing().'
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) declared in schema. Agents cannot infer which tools are safe to retry or which modify state without reading descriptions.