Local-first MCP server for desktop automation: screenshots, mouse, keyboard
16 tools with complete schemas and descriptions, but quality is uneven. Most tools have adequate naming (verb-first) and parameter descriptions, but several lack depth. Browser tools (screenshot, navigate, click, type) are well-documented with clear risk levels and parameter constraints. UI accessibility tools (ui_tree, ui_find, ui_act) have minimal descriptions (20-50 chars) that fail to explain WHEN to use them or their relationship to browser tools. Output schemas are not documented, LLMs cannot predict return structures. Error handling is absent from descriptions; no recovery guidance. Composition is reasonable (tools chain via selectors/refs), but descriptions don't explain the chain. Average tool description ~80 chars, well below the 194-char baseline for A+ tools.
Navigate back in browser history
Click an element identified by selector
Navigate forward in browser history
Get an attribute value from an element
Navigate to a URL in the browser
Query the DOM for elements matching a selector, with pagination support
Read text content from an element or the entire page
UI accessibility tools (ui_tree, ui_find, ui_act, ui_wait, ui_windows) have minimal descriptions (20-50 chars) that fail to explain WHEN to use them vs browser tools, what they return, or how they chain. LLMs cannot determine tool selection.
No output schemas documented for any tool. LLMs cannot predict return structures, field names, or types. Downstream tool chaining requires guessing. Violates pattern:tool and pattern:response-shaper.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Reload the current page
Capture the full virtual screen (all monitors). Default is JPEG (~5x smaller than PNG).
Type text into an element, with optional human-like timing and submission
Perform an action on a ref, then re-read and return the element's state
Find elements matching role, name, or both. An empty match is ok.
Read an accessible tree, filtered and depth-capped
Block until a matching element appears or the timeout elapses (bounded)
List open top-level windows across all apps: app, title, active, ref, pid
Wait for an element matching a selector to reach a specific state
No error handling guidance in any tool description. LLMs receive raw errors with no recovery path. E.g., 'selector not found' should suggest fallback to ui_tree or screenshot. Violates pattern:recovery-guide.
Browser and UI tool relationship undocumented. Descriptions do not explain: use browser tools for web pages, UI tools for desktop apps. LLMs will misapply tools, wasting calls.
Parameter 'by' in query and click tools lacks enum constraint. Description says 'css (default) or other types' but does not list valid values. LLMs may hallucinate invalid selector types.