Loading ToolBench
Agent-friendly task planning and execution MCP server with browser UI
Steps MCP demonstrates solid tool design with complete JSON Schema definitions, clear naming conventions (verb_noun pattern), and consistent parameter documentation. All 17 tools have explicit schemas with required fields, types, and descriptions. However, tool descriptions average ~100 chars (below the 194-char baseline for A+ tools), and several lack actionable context about when to use them vs. alternatives. Parameter descriptions are present but often minimal (e.g., 'Plan UUID' without guidance on how to obtain it). Output schemas are not documented in the tool definitions, forcing LLMs to infer response structure. Error handling is implicit rather than explicit, no recovery guidance in descriptions. Composition is strong: tools follow single-responsibility principle and chain well (e.g., plan.create → plan.create_with_steps). Security appears sound: no credentials in parameters, destructive operations require explicit confirmation flags (confirmDeleteContent, confirmDeleteAttachments). Overall, this is a well-structured server that would benefit from richer descriptions and documented output schemas.
Create an attachment for a note and return metadata and content resource URIs.
Delete an attachment and stored content after explicit confirmation.
Update attachment metadata and return the updated attachment resource URI.
Create a note for a step without changing step status.
Delete a note only when it is not required by a transition.
Record explicit user approval for a reviewed draft plan.
Mark a plan blocked when execution cannot continue at plan level.
Output schemas not documented. Tool definitions lack return type documentation, forcing LLMs to infer response structure. This violates the pattern:tool-chain requirement that downstream tools receive necessary IDs and references.
Tool descriptions are minimal (avg ~100 chars vs 194-char baseline). Descriptions lack context about when to use each tool vs. alternatives, and do not explain prerequisites or expected outcomes. E.g., 'Create a note for a step' does not explain how to obtain a stepId or what happens next.
Parameter descriptions lack actionable guidance. 'Step UUID' and 'Plan UUID' do not explain how to obtain these IDs or what to do if the ID is unknown. Should include hints like 'Obtain from plan.list() or plan.create_with_steps() response.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2026-07-28+ | v2 |
Create an empty work plan and return its plan resource URI and review URL.
Create a work plan with detailed formatted todo steps and return resource URIs and review URL.
Delete a plan and its contained workflow data after explicit confirmation.
List recent accessible plans with optional status, title/id, and active-step filtering.
Pause an executing plan and return its current plan resource URI.
Reorder all steps in a draft or approved plan and return updated plan resource URIs.
Resume a paused plan and return its next-step resource URI.
Clear a plan-level blocker and return the next-step resource URI.
Update plan metadata and return the updated plan resource URI.
Return overview guidance, key prompt names, and the first planning workflow.
No explicit error handling guidance in tool descriptions. Destructive operations (delete, block) do not document what errors might occur or how to recover. E.g., plan.delete should explain 'Returns error if plan is executing; pause first.'
plan.list lacks pagination documentation. Schema includes cursor and limit, but description does not explain how to use cursor for multi-page results or what the response structure contains (total count, next_cursor, etc.).