Loading ToolBench
The server provides 13 tools with consistent naming conventions and basic descriptions, but has critical gaps in schema documentation, parameter validation, error handling, and output structure definition. All tool names follow verb_noun patterns (click, type_text, move_to, etc.), which is good. However, output schemas are entirely undocumented, LLMs cannot predict return types. Most parameters have descriptions, but parameters like 'text' in type_text and 'keys' in hotkey lack format constraints. Error handling is minimal: all tools catch exceptions silently and return boolean/string defaults (-1, -1) instead of actionable recovery guidance. This is typical of community STDIO servers (median 45-55 range).
Perform a mouse click at the given (x, y) coordinates. Returns true if success, else false.
Perform a double-click at the given (x, y) coordinates. Returns true if success, else false.
Get the current (x, y) coordinates of the mouse. Returns (x, y). The string will have negative values if failed.
Get the name of the current operating system (e.g., 'Windows', 'macOS', 'Linux'). Returns OS name or 'Unknown' on failure.
Get the RGB color of the pixel at (x, y). Returns a string in the format (r, g, b). On failure it returns (-1, -1, -1)
Get the screen resolution as (width, height). Returns a string in the format 'width, height'. On failure it returns '-1, -1'
Output schemas entirely undocumented. Tools return booleans, tuples-as-strings, and fallback values (-1, -1) without schema declarations. LLMs cannot predict return structure, making downstream tool chaining impossible.
Silent exception handling with no error guidance. All exceptions caught, no recovery hints provided. When get_mouse_position returns '(-1, -1)', the LLM does not know why it failed or what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Press multiple keys together (e.g., 'ctrl+c'). Keys should be space-separated. Returns true if success, else false.
Move the mouse to the given (x, y) coordinates. Returns true if success, else false.
Press and release a single key (e.g., 'enter', 'space', 'a'). Returns true if success, else false.
Perform a right-click at the given (x, y) coordinates. Returns true if success, else false.
Scroll the mouse up (positive amount) or down (negative amount). Returns true if success, else false.
Take a screenshot and save it to the specified filename. Returns true if success, else false.
Type the given text using the keyboard. Returns true if success, else false.
Parameter constraints missing. 'text' in type_text and 'keys' in hotkey accept free-form strings with no format documentation. No validation that 'text' is non-empty, or that 'keys' are valid PyAutoGUI key names. LLMs will hallucinate invalid inputs.
Coordinate parameters (x, y) lack bounds documentation. No mention of valid ranges relative to screen size. LLMs might pass negative or out-of-bounds coordinates without guidance.
No documentation of whether tools are idempotent or have side effects. click(100, 100) called twice might double-click or click twice at different moments. No clarity on retry safety.
String return formats are inconsistent and fragile. get_mouse_position returns str((x, y)), get_screen_size returns str((width, height)), get_pixel_color returns str((r, g, b)). These are not JSON, they are Python repr() strings. LLMs must parse tuple syntax, error-prone.
take_screenshot filename parameter has no validation. No guidance on valid paths, permissions, or file format. LLMs might pass absolute paths they cannot write, or relative paths that fail silently.
No confirmation or dry-run pattern for destructive/risky operations. Tools like click and type_text modify system state. No way for an agent to preview or confirm before execution.