Loading ToolBench
Playwright MCP for TUI apps - MCP server for headless TUI automation
This TUI driver MCP server provides 24 well-structured tools for terminal automation. Strengths: all tools have explicit descriptions (150-300 chars), clear verb-noun naming (tui_launch, tui_press_key, tui_screenshot), comprehensive input schemas with types and descriptions, and consistent parameter naming (session_id threading). Weaknesses: limited error guidance (responses appear to return success/found flags without actionable recovery instructions), output schemas only partially documented (LaunchResult, TextResult, SnapshotResult are defined but many tools' actual return structures are not visible in source), no tool annotations (destructiveHint, idempotentHint, readOnlyHint missing despite many tools being write/irreversible operations marked in metadata), minimal dependency documentation (e.g., tui_run_code's JavaScript context is not fully documented), and no permission/scope declarations. The tool set is well-composed and idempotent-friendly (session-based, repeatable), but lacks the LLM-optimized recovery patterns and explicit output documentation expected of production-grade tools.
Click on an element by reference ID in a TUI session
Click at specific coordinates in a TUI session
Close a TUI session and clean up resources
Double-click on an element by reference ID in a TUI session
Drag from one element to another by reference IDs in a TUI session
Get raw input buffer (escape sequences sent to process) from a TUI session
Get raw output buffer (PTY output) from a TUI session
No tool annotations (destructiveHint, idempotentHint, readOnlyHint). Many tools are marked WRITE/IRREVERSIBLE in metadata (tui_send_text, tui_press_key, tui_send_signal, tui_run_code) but lack explicit MCP hints to guide LLM behavior and safeguard against accidental misuse.
Limited error guidance and recovery paths. Tool descriptions and visible return types (SuccessResult, WaitResult with boolean flags) do not include actionable error messages or recovery instructions. Errors appear to return bare booleans (success: false, found: false) without context on why the operation failed or what the agent should do next.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Get scrollback line count from a TUI session
Hover over an element by reference ID in a TUI session
Launch a new TUI application session. Supports optional working directory (cwd), environment variables (env), and session recording.
List all active TUI sessions
Press a single key in a TUI session
Press multiple keys in sequence in a TUI session
Resize the terminal in a TUI session
Right-click on an element by reference ID in a TUI session
Execute JavaScript code with access to TUI automation functions
Take a screenshot of the current TUI session
Send a signal to the process in a TUI session
Send raw text to a TUI session
Get information about a TUI session
Get an accessibility-style snapshot of the current screen
Get the current text content of a TUI session
Wait for a TUI session screen to become idle (stable)
Wait for text to appear in a TUI session
Output schemas only partially documented. LaunchResult, TextResult, SnapshotResult, ScreenshotResult are defined in tools.rs, but many tools lack visible return type documentation in the server implementation (server.rs). Agents cannot infer what fields to expect from tui_session_info, tui_list_sessions, or others without parsing implementation code.
tui_run_code JavaScript execution context is under-documented. Description states 'Execute JavaScript code with access to TUI automation functions' but does not specify: which functions are available, what the global scope contains, whether async/await is supported, or what happens if code throws an exception. This forces LLMs to guess and risks invalid code submission.
No permission or scope declarations. Tools like tui_send_signal (kill process) and tui_run_code (arbitrary code execution) have no documented permission requirements or scope declarations. Cannot audit what authority the calling agent needs or implement least-privilege controls.
Recording configuration is optional but lacks guidance on when to use it. RecordingParams has enabled/outputPath/includeInput fields, but the description does not explain the performance impact, whether recordings survive session close, or how large they grow with long-running sessions.