Loading ToolBench
Pixel-level browser automation MCP server for WSL2 — drive a real Chrome with screenshot + xdotool, no CDP.
Server exposes 10 computer-use tools with complete input schemas and descriptions. Naming follows verb_noun convention (screenshot, move, left_click, dom_click, dom_type, dom_query). Descriptions are present and actionable (avg ~120 chars), explaining WHAT each tool does and WHEN to use it. However, descriptions lack explicit guidance on prerequisites, error recovery, and parameter constraints. Parameters have types and descriptions, but lack enums for constrained values (e.g., 'human' boolean could be clearer). Output schemas are not documented, callers must infer return types. Error handling is minimal: tools raise RuntimeError with messages but lack categorization (retryable vs fatal) or recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels (READ_ONLY vs WRITE). Missing idempotency guarantees and confirmation patterns for destructive ops (left_click, right_click, dom_click). Composition is sound, each tool has one responsibility and chains via coordinates/selectors.
Return the current mouse cursor (x,y).
Click the element matching the CSS selector. Faster and more reliable than pixel clicks on DOM-heavy pages — at the cost of flipping `navigator.webdriver=true` for the session. Fails if no element matches or more than one matches.
Read text content (default) or a named attribute from the first element matching the selector. Useful for verifying page state without a screenshot round-trip.
Set the value of an input / textarea / contenteditable matching the selector, then fire a proper input + change event so React/Vue/Svelte see the update.
Move to (x,y) then double left-click.
Move to (x,y) then single left-click.
No output schemas documented. Callers cannot infer return types (e.g., screenshot returns PNG bytes, dom_query returns string or null). LLMs must guess downstream field names.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint). Risk levels are documented in metadata but not exposed to MCP clients. Agents cannot distinguish safe reads from destructive writes.
Error handling lacks categorization and recovery guidance. RuntimeError messages are raw ('xdotool failed: ...') without actionable next steps. No distinction between retryable (timeout) vs fatal (invalid selector) errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Move the cursor to (x,y). Set human=False for an instant jump.
Move to (x,y) then single right-click.
Return the virtual display geometry and backend settings.
Capture the current Xvfb screen and return it as a PNG image.
Descriptions lack parameter constraint details. 'human' boolean parameter has no guidance on when to set false (instant jump vs interpolated movement). 'selector' parameter has no examples or validation rules for CSS selectors.
No confirmation or dry-run pattern for destructive operations (left_click, right_click, dom_click, dom_type). Agents can accidentally trigger irreversible actions without verification.