Loading ToolBench
A Model Context Protocol server that provides access to interactive CLI programs via tmux. Supports both local and remote tmux sessions via SSH.
This server has 8 tools with adequate naming and basic descriptions, but suffers from incomplete parameter documentation, lack of output schema definitions, and missing error handling guidance. No tool has a documented return type or schema. Parameter descriptions are present but minimal (average ~40 chars, well below the 72-char baseline). Tools follow verb_noun naming convention correctly, but descriptions lack detail about when to use each tool and what context is needed. The server tracks session state in memory but does not expose session state or provide mechanisms for agents to understand what operations are safe to retry. Critical gap: no tools validate their assumptions (e.g., that a session exists before operating on it) or guide LLM recovery from common failures.
Attach to an existing tmux session (for sessions not created by this server)
Get current tmux connection info (local or remote SSH host)
List all tmux sessions being tracked by this server
Read the current output from a tmux session
Send a command or input to a tmux session
Send a special key to a tmux session (e.g., Ctrl+C, Tab, Escape)
Set SSH host for remote tmux access (call with no args to switch back to local)
No output schemas documented. Tools return plain strings rather than structured objects. Example: tmux_read_output returns a raw string instead of {lines: [string], count: int, truncated: bool}. LLMs cannot parse output reliably or chain results to downstream tools.
Insufficient parameter descriptions. 'args' in tmux_start_session is described as 'Optional arguments to pass to the program' (~40 chars) but lacks detail: are these shell-quoted? What characters are unsafe? Should complex args use shlex.quote? Parameter descriptions average 40 chars; baseline is 72 chars.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 56 | - | v1 |
Start a new tmux session with an interactive CLI program
No error handling guidance for common failures. When tmux_read_output is called on a non-existent session, the server returns 'Session not found' as a plain string. No recovery suggestion (e.g., 'Try tmux_list_sessions to see available sessions'). Agents cannot self-correct.
Missing idempotency and retry safety documentation. Operations like tmux_send_command and tmux_send_key are destructive (they send input to running processes). No indication whether they are safe to retry, whether they have side effects, or whether agents should use confirmation patterns. Tool descriptions lack 'if the tool modifies state' language.
tmux_list_sessions has no output schema documented. It returns a dict of {name: TmuxSession} but TmuxSession is a dataclass not visible to the LLM. The response format is not specified: is it JSON? A list of dicts with keys {name, program, created_at, last_accessed, is_remote}? The LLM cannot parse it without guessing the structure.
Parameter 'key' in tmux_send_key lacks format constraints. Description says 'e.g. C-c for Ctrl+C, Tab, Escape, Up, Down' but does not specify: Is 'C-c' or 'Ctrl-c' correct? Are keys case-sensitive? What is the complete set of valid keys? Agents will guess and fail, especially with obscure keys like 'S-PageUp'.
Tool composition issue: tmux_start_session and tmux_attach_session both track sessions in a global dict, but there is no way to remove or forget a session. If an agent starts 100 sessions, memory leaks. No 'close_session' or 'detach_session' tool exists. Agents cannot clean up state.