Loading ToolBench
expose a PC's capabilities as MCP tools over streamable HTTP
Server exposes 15 tools with complete input schemas and descriptions. Naming follows verb_noun convention (shell_exec, read_file, write_file, etc.). Descriptions are present and substantive (100-300 chars), explaining what each tool does and key constraints (timeouts, size limits). However, descriptions lack actionable error guidance and recovery hints. Parameter descriptions are adequate but sparse on format constraints. Output schemas are not formally documented, responses are inferred from code. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. Error handling returns basic messages without recovery guidance. Composition is sound: each tool has one responsibility, and tool chains are feasible (e.g., start_process → get_process_output → kill_process). Security: shell_exec and file operations accept user input but lack explicit injection warnings in descriptions.
Click the mouse at the specified coordinates.
Download a file from a URL and save it locally. Files larger than REMOTE_PC_MCP_MAX_DOWNLOAD_BYTES (default 2 GB) are rejected.
Get stdout and stderr from a process started with start_process. Returns empty strings if the process is still running.
Kill a process and all of its children.
List files and directories in a path. Returns name, type (file/dir), size, mtime.
Move the mouse to the specified coordinates.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. Tools marked IRREVERSIBLE (shell_exec, start_process, click, move_mouse, type_text, press_key, scroll) and DESTRUCTIVE (kill_process) should declare these hints so agents understand consequences.
Error messages lack recovery guidance. Descriptions state constraints (e.g., 'Files larger than 50 MB rejected') but error responses do not guide the agent on what to do next. E.g., read_file should return 'File too large (X MB > 50 MB limit). Try reading a smaller file or splitting the read.' instead of a bare error.
Output schemas not formally documented. Responses are inferred from code (e.g., shell_exec returns {stdout, stderr, exit_code, timed_out}). LLMs need explicit schema documentation to plan downstream calls and extract fields reliably.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Press a keyboard key or key combination.
Read a file as text, with base64 fallback for binary files. Files larger than REMOTE_PC_MCP_MAX_READ_BYTES (default 50 MB) are rejected.
Scroll the mouse wheel at the current position.
Run a shell command. Returns stdout, stderr, exit_code. timeout is capped at REMOTE_PC_MCP_MAX_SHELL_TIMEOUT (default 600s). The blocking subprocess runs in a thread so /health and other tool calls keep being served while a long command is in flight.
Start a process and return its PID. Stdout/stderr are captured to temp files and can be retrieved with get_process_output.
Get system information: OS, CPU, memory, disk, uptime, hostname.
Take a screenshot of the primary display and return it as base64-encoded PNG.
Type text at the current cursor position.
Write content to a file. Set base64_encoded=True for binary data. Content larger than REMOTE_PC_MCP_MAX_WRITE_BYTES (default 50 MB) is rejected.
Parameter descriptions lack format constraints. E.g., 'key' in press_key accepts 'enter', 'escape', 'ctrl+c' but description does not enumerate valid values or regex pattern. LLMs cannot validate input without explicit constraints.
No dry-run or confirmation step for irreversible operations. shell_exec, kill_process, and file write operations can cause data loss or system damage. Agents should be able to preview consequences before committing.