Loading ToolBench
Native Windows computer-use MCP server for desktop automation and control
ControlFreak defines 22 tools with consistent naming (verb_noun pattern: get_, list_, capture_, click_, etc.) and complete input schemas. All tools have descriptions (avg ~100 chars). However, parameter descriptions are minimal (often single phrases like 'The ID of the display'), lacking context on constraints, ranges, or when to use each tool. Output schemas are not documented, LLMs cannot predict what fields to expect. Error handling is present but generic. No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification (READ_ONLY vs WRITE). Composition is sound: tools chain well (e.g., list_displays → capture_display). Security: no secrets in params. Overall: solid foundation, but descriptions and output documentation need expansion to meet production LLM-agent standards.
Capture a screenshot of a display with optional cursor inclusion and width scaling
Capture a screenshot of a specific region on a display
Capture a visual baseline of a region for later comparison
Capture a screenshot of a specific window
Click the mouse at a specified position
Find and click on text on the screen
Drag the mouse from one position to another
Find text on the screen using OCR and return matching regions
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination). Tools like capture_display, list_windows, find_text lack documented return types, forcing agents to guess at field names for downstream chaining.
Parameter descriptions lack constraint details. E.g., 'max_width' has no min/max bounds, 'timeout_ms' has no range guidance, 'difference_threshold' (float) has no valid range (0.0 - 1.0?). LLMs cannot validate inputs without explicit constraints.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint). Tools are marked READ_ONLY or WRITE in metadata, but MCP tool definitions lack these hints. Agents cannot infer safety/retry semantics from the tool definition alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
Focus a window by its ID
Get the current status of the ControlFreak server, including safety indicator, session information, version, instance ID, process ID, security context, and recent operations
List all available displays on the system
List all virtual desktops and their windows
List all available windows on the desktop
Move the mouse pointer to a specified position
Press a combination of keyboard keys
Read text from a specified region using OCR
Scroll the mouse wheel at a specified position
Switch to a different virtual desktop
Type text into the focused window
Wait for a visual change since a previously captured baseline
Wait for a visual change in a specified region of a display within a timeout period
Wait for a window to appear or meet specified conditions
Parameter descriptions are minimal (single phrases). E.g., 'observation' param in move_mouse, click_mouse, etc. is described as 'Observation options' with no detail on what options exist or when to use it. Agents cannot reason about optional parameters without context.
No error recovery guidance. Tools lack descriptions of failure modes (e.g., 'display_id not found', 'timeout waiting for visual change'). Error responses should guide LLMs on retry vs. user correction, but this is not documented.