Loading ToolBench
MCP stdio server that gives an AI computer-use + CLI/console control of a ruOS desktop (screenshot + keyboard/mouse + shell + system actions + resolution), attached over SSH
ruos-mcp provides 16 tools with explicit schemas and descriptions visible in source. However, most descriptions are terse (10-50 chars), parameter descriptions lack detail on constraints/ranges, and output schemas are undocumented. Tool names are action-oriented (screenshot, mouse_move, type_text) but lack verb prefixes on some (screen_size, cursor_position, desktop_resolution). No error recovery guidance, no input validation hints, and destructive tools (run_shell, system_action) lack confirmation patterns. Schemas are present but minimal, most parameters have type but no range/format constraints. This is typical of a functional but not production-hardened tool surface.
Return the current mouse position as 'x y'.
Change the desktop resolution AFTER launch (server-side, via xrandr on the ruOS virtual display) — not a client-window resize. Give either width+height, or a preset (720p|1080p|qxga|1440p). Optional refresh (default 60 Hz). Custom sizes are bounded (even, 640..3840 x 480..2160) and rejected if they exceed the dummy driver's ~300 MHz pixel-clock ceiling.
Double left-click. If x,y given, move there first.
Press a key or chord in xdotool syntax, e.g. 'Return', 'ctrl+c', 'alt+Tab'.
Left-click. If x,y given, move there first.
Press left at (x,y), drag to (to_x,to_y), release.
Descriptions are uniformly terse (10 - 60 chars). Baseline for A+ tools is 50 - 200 chars. LLMs cannot determine when to select tools or how they differ from similar ones. E.g., 'screen_size' and 'screenshot' both query display state but serve different purposes, the descriptions do not explain the distinction.
Parameter descriptions lack constraint details. E.g., 'x' and 'y' say 'X pixel (0 = left)' but do not specify valid ranges (0 - screen_width). 'amount' in scroll has no bounds. 'ms' in wait says 'max 10000' in description but this is not enforced in schema. LLMs cannot validate inputs without explicit min/max/enum constraints.
Destructive tools (run_shell, system_action) lack confirmation or dry-run patterns. run_shell accepts arbitrary shell commands with no validation, sanitization, or recovery guidance. system_action can install/restart systems. No error messages guide recovery if a command fails.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Middle-click. If x,y given, move there first.
Move the mouse to (x, y).
Right-click. If x,y given, move there first.
Run an arbitrary shell command on the desktop and return its output. Full CLI/console access.
Return the screen resolution as 'WIDTH HEIGHT'.
Capture the desktop and return it as a PNG image.
Scroll the wheel. direction up|down|left|right, amount = clicks.
Run a named ruOS system action via the desktop executor. action = install|optimize|update|status|restart; args = e.g. a tool name ('codex') or 'storage'.
Type a string of text at the current focus.
Sleep for ms milliseconds (max 10000).
Output schemas are not documented. Tools return text responses but LLMs do not know the structure. E.g., does screenshot return base64 PNG or a file path? Does run_shell return stdout, stderr, or both? Does system_action return JSON or plain text? Undocumented outputs force LLMs to guess.
Naming inconsistency: some tools lack action verbs. 'screen_size', 'cursor_position', 'desktop_resolution' are nouns/adjectives. Baseline: 90% of A+ tools start with action verbs (get_, set_, move_, etc.). Rename to get_screen_size, get_cursor_position, set_desktop_resolution for clarity.