Loading ToolBench
Terminal multiplexer MCP server for AI agent workspace orchestration
This server has critical definition quality gaps that make it unsuitable for production use. While tools are registered with names and basic descriptions, the evaluation reveals systemic issues: (1) Tool definitions are inferred from site/components/tools.tsx, a React component used for website documentation, NOT from actual MCP server implementation code. The actual tool registration logic is not visible in the provided source. (2) Input schemas are present but lack critical details, most parameters have only a type string and basic description, with no enums, constraints, ranges, or validation rules. (3) Descriptions are extremely brief (10-20 characters in most cases), well below the 50-200 character baseline for LLM-optimized descriptions. (4) No output schemas are documented, leaving LLMs unable to plan downstream tool calls. (5) No error handling guidance is present, tools like close_surface and spawn_agent perform destructive/complex operations but provide no recovery paths or failure modes. (6) Several tools conflate multiple responsibilities (e.g., send_to accepts both 'text' and 'key' as optional mutually exclusive parameters, creating ambiguity). (7) Security-critical parameters are accepted but no mention of permission gating or input sanitization is evident.
Close a surface or managed agent with live-agent guards
Inspect socket, binary, process, and control-plane health
List addressable agents with lifecycle state
List workspace, pane, and surface topology
Read terminal output with parsed agent status
Escalate a blocker to the direct parent agent
Send text, commands, or keys to an agent or surface
Tool definitions inferred from React component, not actual server code. Only website documentation is visible.
All tool descriptions are under 20 characters, falling far below the 50-200 character baseline. Descriptions like 'Read terminal output with parsed agent status' (42 chars) lack operational context. No guidance on WHEN to use each tool, what parameters mean, or what to expect from results.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 40 | 2025-06-18+ | v2 |
Launch a Claude, Codex, Gemini, Cursor, or Kiro agent in a pane
Rename or move a terminal surface
Block until an agent reaches a target state
No input schemas visible in actual MCP server code. Schemas shown are inferred from parameter lists in React component. Missing: JSON Schema definitions, type constraints, enums for constrained inputs (e.g., agent_type accepts 'claude|codex|gemini|cursor|kiro' but no enum validation shown), min/max bounds for numeric params, format validators for strings.
No output schemas documented for any tool. LLMs cannot infer what fields to expect from list_surfaces, list_agents, or read_screen. This prevents downstream tool chaining (e.g., agent_id from list_agents used in wait_for or report_to_parent).
Destructive tools (close_surface with force=true, spawn_agent, send_to) have no error handling guidance, no confirmation steps, and no recovery paths. close_surface description says 'with live-agent guards' but guards are not explained. No mention of what happens on permission denial, invalid surface reference, or agent already running.
send_to tool accepts both 'text' and 'key' as optional parameters with no guidance on mutual exclusivity or what happens if both are provided. Description does not explain when to use text vs key (keystroke vs message text is inferred but not explicit).
Parameter descriptions are minimal and lack constraint documentation. Example: spawn_agent's 'model' param says 'Model to use for the agent (optional)' but does not enumerate valid models, warn about availability, or explain fallback behavior if model not found. Timeout param in wait_for has no guidance on valid range, units, or default value.
No security or permission model evident. Tools like close_surface, send_to, and spawn_agent can affect system state and running agents but lack any mention of permission checks, audit logging, or least-privilege scoping. 'live-agent guards' in close_surface is vague.
Parameter naming is sometimes ambiguous. 'surface' is used as a concept without clear explanation of what it is (pane? terminal? agent instance?). 'agent_type' enum values ('claude', 'codex', 'gemini', 'cursor', 'kiro') are not explained, LLMs may not know which to choose without additional discovery.
No pagination or result limiting documented. list_surfaces and list_agents could return unbounded lists, risking context window exhaustion. No description of what 'topology' means or how large results could grow.
Composition issue: spawn_agent requires 'workspace' and optionally 'pane' parameters, but list_surfaces/list_agents do not clearly explain how to obtain valid workspace and pane references. Agents may not know what values to pass without first understanding the topology.