Loading ToolBench
Windows UI automation with computer use capabilities - click, screenshot, type, drag, OCR, and verify native Windows UI via MCP. FastMCP 3.2.0 agentic sampling.
This Windows automation MCP server exhibits moderate tool definition quality with significant gaps. Of 20 tools evaluated, naming is generally good (verb-prefixed, clear intent), and descriptions are present for all tools. However, critical structural issues severely impact overall quality: (1) Input schemas are either missing entirely or severely under-specified, most tools lack proper JSON Schema type definitions for their parameters; (2) Parameter descriptions are present but often generic and lacking constraint information (ranges, enums, format details); (3) Output schemas are completely undocumented, the response structure for each tool is not specified, making it impossible for LLMs to plan downstream chains; (4) No error handling guidance is visible, tools provide no recovery hints or error classification; (5) Security concerns around clipboard access and system automation are not addressed; (6) No tool annotations (readOnly/destructive hints) despite tools having clear read/write semantics. The codebase shows these are archived tools in a FastMCP 3.4.4 framework, suggesting active maintenance, but the tool definitions themselves fall short of production patterns.
Bring a window to the foreground by its title.
Click at specific screen coordinates.
Check if a UI element exists.
Find an image on the screen using template matching.
Get current mouse cursor position.
Get the position and size of a UI element.
Get comprehensive help and documentation for all available tools.
Missing or incomplete output schemas, no documented return structure for any tool. LLMs cannot plan chains without knowing what fields are returned.
Input schemas lack proper JSON Schema type definitions, most numeric parameters (x, y, timeout, amount, confidence) are declared with type but lack min/max constraints; 'selector' parameters accept either string or object but no discriminator or concrete type guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2025-06-18+ | v2 |
Get a list of running processes.
Get the current content of the system clipboard.
Get text at the current cursor position using OCR.
Check if the PyWinAuto MCP server is running and operational.
List all visible windows on the desktop.
Move mouse to specific coordinates.
Scroll mouse wheel at current or specified position.
Set the content of the system clipboard.
Take a screenshot of the screen or a specific region.
Verify that an element contains the expected text.
Wait for the specified number of seconds.
Wait for a UI element to appear.
Wait for a window with the specified title to become active.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic differences, write tools (click_at_position, move_mouse, scroll_mouse, set_system_clipboard, bring_window_to_foreground) are indistinguishable from read tools in schema. This violates current MCP spec (2026-07-28) which requires tool annotations.
No error handling guidance, tools provide no recovery hints, error categorization, or actionable error messages. A parameter validation failure or timeout returns nothing to guide the LLM toward self-correction.
Clipboard tools (get_system_clipboard, set_system_clipboard) expose sensitive data access without documented security model, audit trail, or permission gates. No indication whether these are restricted or available to any MCP client.
Parameter descriptions lack specificity, 'region' is described as 'Optional dict with left/top/width/height' but does not specify coordinate origin (top-left? center?), units (pixels?), or whether coordinates are relative to screen or window.
No documented limits or pagination, list_windows, get_process_list, find_image_on_screen have unbounded output potential. Returning hundreds of items will exhaust token budgets.
Selector parameter design is ambiguous, element_exists, wait_for_element, verify_text, get_element_rect all accept 'selector' as string or dict but schema does not clarify when each is valid or how to construct them. This forces LLM to guess selector syntax.
No tool composition chains documented, e.g., it's unclear how output from list_windows feeds into wait_for_window (does it return the exact title needed?), or how get_element_rect output enables click_at_position.