Loading ToolBench
An open-source MCP server that gives Claude conversations a persistent, interactive plan/to-do panel.
Wingman MCP has 26 tools with complete JSON schemas and descriptions. Naming is verb-first and clear (create_plan, add_task, tick_task). However, descriptions are brief (avg ~60 chars) and lack context on WHEN to use each tool or dependencies between them. Parameter descriptions are minimal, most just restate the parameter name. Internal UI tools (_ui_*) are exposed as public tools, violating single-responsibility principle. No documented output schemas beyond inferred dict structures. Error handling is absent from tool definitions.
Internal: add task from UI input.
Internal: clear all tasks.
Internal: clear completed tasks.
Internal: delete plan from UI.
Internal: delete task from UI.
Internal: export plan as markdown.
Internal: get prompt for building plan from chat.
Internal UI tools exposed as public MCP tools. The 13 _ui_* tools should not be registered as callable tools, they are implementation details for the interactive panel. This violates single-responsibility and confuses LLMs about which tools to use.
Descriptions are too brief (avg 45 chars for UI tools, 50 for public tools). Lack context on WHEN to use each tool, dependencies, or prerequisites. E.g., 'Mark a task as done' does not explain that tick_task and update_task_status both exist or when to prefer one.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2025-06-18+ | v2 |
Internal: fetch plan state for live polling.
Internal: get prompt for running a task.
Internal: fetch plan list for picker polling.
Internal: inline title rename.
Internal: drag-to-reorder.
Internal: tick from UI.
Internal: status change from UI.
Append a single task to a plan.
Append multiple tasks to a plan in one call.
Create a new named plan with optional initial tasks.
Delete a plan and all its tasks.
Return plan state as formatted text (no panel).
List all plans with task counts.
Rename a plan.
Reorder tasks within a plan.
Render a plan as an interactive panel inline in the conversation.
Render a clickable list of all plans as an interactive panel. Use this when the user wants to see or pick from their plans.
Mark a task as done.
Change a task's status.
Parameter descriptions are minimal and often just restate the parameter name. E.g., 'Task ID' for task_id, 'Plan name' for plan_name. No guidance on format, constraints, or how to obtain the value if unknown.
No documented output schemas. Tool definitions show input schemas but do not document what fields are returned or their types. LLMs cannot plan downstream calls without knowing response structure.
No error handling guidance in tool definitions. No indication of what errors can occur, when they are retryable, or what the LLM should do next. E.g., delete_plan does not document what happens if the plan does not exist.