MCP server: drive the Windows desktop and SEE the result immediately. Every action returns the new state of the screen in the same reply, so work is look -> act -> look instead of writing a script blind and inspecting the outcome minutes later.
Server has 13 tools with consistent naming (verb_noun pattern: desktop_*) and reasonable descriptions (avg ~100 chars). All tools have input schemas with type definitions. However, parameter descriptions are sparse or missing context. Output schemas are not documented. Error handling is minimal, no recovery guidance or actionable error messages. Tool composition is sound (each does one thing), but descriptions lack LLM-optimization details (e.g., when to use desktop_click vs desktop_double_click, what each returns). No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification (READ_ONLY vs WRITE).
Click at a point on the screen.
Double-click at a point on the screen.
Press one or more keys.
List monitors. Coordinates are shared across all screens and can be negative on secondary monitors -- every x/y below lives in that space.
Move the cursor to a point.
Start recording a screencast. Returns the session ID.
Stop recording and return the event log.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear risk stratification. Tools marked READ_ONLY (desktop_monitors, desktop_windows, desktop_screenshot) and WRITE (all others) should declare this via annotations for agent safety.
Output schemas not documented. Tools return Image, event logs, or window lists, but LLMs cannot see the structure. desktop_screenshot returns Image(data, format), not documented. desktop_record_stop returns 'event log', structure undefined. desktop_windows returns list of dicts with fields (title, size, position, class), not formally specified.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | 2026-07-28+ | v2 |
Render a recorded take into a video file.
Right-click at a point on the screen.
Grab a screenshot of the whole screen or a window.
Scroll the mouse wheel.
Type text at the current cursor position.
List visible windows: title, size, position, class.
Parameter descriptions lack actionable context. 'window' param across 10 tools says 'Window title; empty = last window touched' but does not explain: What if no window was touched yet? What happens if the title is ambiguous? How does partial matching work? LLMs cannot infer these details.
No error handling guidance. Code raises ValueError('no window given and none used yet') and ValueError('no visible window matching ...') but these are not documented in tool descriptions. LLMs cannot know what to do if a window lookup fails, retry? Ask user? Call desktop_windows first?
desktop_key parameter 'keys' is an array but lacks enum constraint. Description lists examples ('enter', 'ctrl', 'shift', ...) but does not forbid invalid values. LLMs may hallucinate key names like 'return' (should be 'enter') or 'command' (Windows has no command key). Should be an enum or strict pattern.