Loading ToolBench
An MCP server for remote-controlling and observing TUI programs via a real PTY and an embedded terminal emulator.
TUI MCP demonstrates solid tool design with 22 well-named, action-verb-prefixed tools (start, stop, send_key, screen, wait_text, etc.). All tools have descriptions (avg ~120 chars, within 10-1024 baseline). Input schemas are comprehensive with typed parameters and descriptions. However, output schemas are not explicitly documented in the source, responses are inferred from code logic rather than declared. Error handling is present but lacks recovery guidance (e.g., 'try X if Y fails'). No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Parameter descriptions are generally good but some lack format/constraint details (e.g., 'key' in send_key lists examples but no formal enum). Composition is excellent, tools chain well (e.g., start → send_key → screen → wait_text). Security: no secrets in params (good). Overall: strong naming, descriptions, and schemas; weak on output documentation and error recovery guidance.
Report which binary is serving this session: executable path and mtime, server version and process uptime. Use it after reloading the server to confirm the running process picked up your rebuild.
Send a mouse action to the session.
Paste text into the session, respecting bracketed paste mode if enabled.
Read buffered output from a piped stream (stdout or stderr).
Resize the terminal in PTY mode.
Read the current screen content from the session.
Write a PNG screenshot of the current screen to a file.
Read scrollback history from the session.
Output schemas not explicitly documented. Tool descriptions state what is returned (e.g., 'screen' returns 'current screen content') but formal JSON Schema output types are absent from source. LLMs cannot reliably plan downstream tool calls without knowing response field names and types.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications in metadata. Tools like 'stop', 'send_key', 'signal' are destructive; 'screen', 'wait_text', 'scrollback' are read-only. Annotations enable agents to reason about side effects and retry safety.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | <=2025-11-25 | v2 |
Search scrollback history with a regular expression.
Send raw bytes with C-style escapes to the session.
Send a single key press to the session.
Send a sequence of key presses in order.
Send literal text typed verbatim into the program.
Send a signal to the session process.
Sleep for a specified duration.
Start a new TUI session with a program under a PTY or piped mode.
Stop a running session and clean up resources.
Wait for the screen to change.
Wait for the session process to exit.
Wait for text to appear in piped output (stdout or stderr).
Wait for the screen to stabilize (remain unchanged for a duration).
Wait for text to appear or disappear on the screen.
Error handling lacks recovery guidance. No tool description explains what to do if a call fails (e.g., 'If session not found, call start() first'). Error responses are inferred to be raw error codes rather than actionable messages with next steps.
Parameter constraints documented informally. 'send_key' lists key examples ('enter', 'tab', 'esc') in description but no formal enum. 'signal' lists signal names as examples. LLMs may hallucinate invalid values; formal enums are machine-parseable and prevent this.
Pagination not documented for 'scrollback' and 'search'. Both accept 'page' and 'page_size' but descriptions do not explain total count, whether pages are 0-based or 1-based, or what happens at boundaries. Agents cannot reliably iterate through results.