Loading ToolBench
Universal MCP server for terminal automation supporting Claude Desktop, iFlow CLI, Gemini CLI, and other MCP clients. Provides workspace management, task automation, app launching, and command execution tools.
TermPipe MCP Server shows significant definition quality gaps across multiple dimensions. While 17 tools are registered with names following verb_noun patterns (workspace_*, list_*, launch_*), many lack proper schema documentation and several have weak or missing parameter descriptions. The server does not provide output schemas, making it difficult for LLMs to plan downstream calls. Error handling is minimal, responses rely on plain text rather than structured recovery guidance. Parameter types are defined in some tools but descriptions are generic or incomplete. The workspace_* tools operate in a complex domain (human review gates, task workflows, desktop notifications) but the tool definitions do not clearly explain prerequisites, state transitions, or error recovery paths. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite many tools being destructive or requiring side effects.
Launch an application via normalized launch script.
List available launch scripts.
Ask the human a clarifying question via desktop notification with clickable buttons. Blocks until the human clicks an option or timeout is reached.
Block until human approves or rejects a task.
Update or create workspace documentation with gating.
Start (or revise) a workspace's implementation plan, blocking until a human verdict arrives on termpipe.workspace.status. First call for a fresh cwd: goal + plan_content required. Revise loop after REJECT: plan_content required, goal/task_items ignored. Returns APPROVE (with next-step hint to call workspace_task) or the unified-diff feedback on REJECT (with hint to revise and call again).
Missing output schemas on all 17 tools. LLMs cannot plan downstream calls without knowing response structure (field names, types, required vs optional). This is a CRITICAL gap for tool composition.
Enumerated parameters lack proper constraints. Parameters like 'status' (workspace_task_set_status), 'action' (workspace_task_update), 'task_type' (workspace_task_create), 'priority' (workspace_task_create), and 'app_name' (launch_app) accept free-form strings instead of enums. LLMs will hallucinate invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
List all workspaces with optional filtering.
Load a workspace from disk.
Override write gates for the current workspace.
Update workspace implementation plan with gating and override lifecycle management.
Get the current status of a workspace.
Create a new task in the workspace.
Query tasks in the workspace by status, priority, or type.
Request human review for a specific task by ID.
Set the status of a task with gating.
Update an existing task with gating.
Update workspace walkthrough documentation with gating.
Generic and undescriptive tool descriptions. Many descriptions are under 50 characters and do not explain WHEN to use the tool, prerequisites, or error recovery. Examples: 'Load a workspace from disk' (30 chars), 'Get the current status of a workspace' (37 chars), 'List all workspaces with optional filtering' (43 chars). These descriptions provide minimal context for LLM tool selection.
No error handling guidance. Tools return plain text (inferred from code) with no structured error classification (retryable vs fatal), actionable recovery steps, or field validation feedback. Example: workspace_task_set_status will fail silently if 'status' is invalid.
Destructive and write-gating tools (workspace_override, workspace_plan_update, workspace_task_update, workspace_task_set_status, launch_app) lack tool annotations. No destructiveHint, idempotentHint, or readOnlyHint annotations present. LLMs cannot determine safe retry semantics.
Mutual parameter dependencies undocumented. workspace_task_update has 'item_text' and 'item_id' that are mutually exclusive or dependent on 'action', but descriptions do not clarify. workspace_task_create has optional parameters that may or may not create a valid task.
No pagination support on list/query tools. workspace_task_query and workspace_list offer no limit, offset, or cursor parameters despite potentially returning many results. Large result sets will exceed context windows and degrade LLM reasoning.
Blocking tool semantics not clearly documented. workspace_init_and_review, workspace_await_task_approval, and workspace_ask block until human input. No description clarifies what 'blocking' means in an async context, whether timeout returns an error, or how the LLM should handle the wait.
Parameter descriptions are minimal. Many parameters have one-word or two-word descriptions ('Task title', 'Task description', 'Current working directory').
Tool naming lacks clarity in tool chain context. workspace_task_create, workspace_task_update, workspace_task_set_status all operate on tasks, but their distinctions are unclear. Does workspace_task_update handle status changes or does workspace_task_set_status? Parameters do not align across these tools for obvious chaining.