Loading ToolBench
MCP server for AutoGUI multi-node control
This server provides 12 tools for GUI automation with HTTP transport via FastMCP. Most tools have descriptions and basic parameter schemas, but critical gaps exist: (1) Parameter descriptions lack detail on constraints, ranges, and expected formats, e.g., 'button' parameter accepts 'left', 'right', 'middle', 'double_click', 'double_left' but only the description mentions these enums; JSON Schema lacks enum constraint. (2) Output schemas are not documented, tools return types.TextContent wrapping dict results, but the LLM cannot see what fields the dict contains. (3) No error handling guidance, failures return generic handle_error() without recovery steps. (4) Tool descriptions are adequate (90-150 chars) but lack dependency hints (e.g., when to call take_screenshot before mouse operations). (5) No parameter validation rules in descriptions, numeric coordinates lack min/max, scroll_amount lacks bounds. All tools follow verb_noun naming convention, which is strong.
Click the mouse button at the specified coordinates.
Drag the mouse from source coordinates to target coordinates. This performs a complete drag operation: press at source, move to target, then release.
Get the current position of the mouse cursor.
Get the size of the screen.
Move the mouse cursor to the specified coordinates.
Press a keyboard key or key combination.
Press down a mouse button at the specified coordinates without releasing it. Useful for drag operations.
Output schemas not documented. Tools return types.TextContent(text=...) or dict, but LLM cannot see what fields are in the response. For take_screenshot, the response should document that it returns base64-encoded PNG. For coordinate/size queries, responses should document field names (x, y, width, height, etc.). Without this, agents cannot chain tools or extract structured data.
Enum constraints missing from schemas. The 'button' parameter in click_mouse, press_mouse, release_mouse accepts only 'left', 'right', 'middle', 'double_click', 'double_left', but the JSON Schema has type string with no enum constraint. LLMs may pass invalid values like 'center' or 'forward'. Similarly, scroll_direction in scroll should be an enum [up, down, left, right].
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Release a mouse button at the specified coordinates. Usually called after press_mouse to complete a drag operation.
Scroll the mouse wheel at the specified coordinates.
Take a screenshot of the current screen and return as base64-encoded PNG image.
Type the specified text using clipboard paste.
Wait for a specified duration in milliseconds.
Numeric parameters lack bounds. Coordinates (x, y) and scroll_amount have no min/max constraints in descriptions. This allows LLMs to pass negative values, zero, or absurdly large coordinates (e.g., x=99999) without validation guidance. Parameter descriptions should specify 'x: integer, 0 to screen_width' or similar.
Error handling provides no recovery guidance. All failures route through handle_error(), which likely returns a generic error string. Error responses should tell the LLM what to do next, e.g., 'Failed to take screenshot. Try waiting 1 second and retrying, or check if display is connected.' Without guidance, agents get stuck.
Tool descriptions lack dependency and prerequisite hints. E.g., move_mouse and click_mouse should suggest taking a screenshot first to understand the UI. press_key should explain valid key names (e.g., 'enter', 'shift', 'ctrl a'). take_screenshot should explain that coordinates are relative to screen (0,0) top-left. These hints prevent wasted calls.
Parameter 'press_key' accepts arbitrary key names with no enum. The description says 'e.g., enter, ctrl c, alt tab' but these are examples, not constraints. LLMs may pass invented key names like 'super_key' or 'alt_enter'. Should document valid key names (or provide a reference) or add an enum constraint.
Coordinate parameters use default 0,0 (current position) when x=0, y=0. This is ambiguous, the LLM cannot tell if 0,0 is intentional (move to top-left) or an accident (forgot to specify). Consider requiring explicit x, y for clarity, or documenting the default behavior in EVERY parameter that uses it. Current descriptions only mention '(default: 0, uses current position)' once per tool.
take_screenshot output schema is not documented. The tool claims it returns 'base64-encoded PNG image' in the description, but the response object structure is not shown. The LLM cannot extract the image data or know if the field is called 'image', 'data', 'screenshot', or 'base64'. Output schema must be explicit.