Computer use for Claude Code on Windows: screenshot and input control as an MCP server
winuse-mcp provides 14 tools for desktop automation with consistent naming (verb_noun pattern: screenshot, left_click, type, etc.) and clear descriptions (avg ~120 chars). All tools have input schemas with typed parameters and descriptions. However, output schemas are undocumented, no structured return types specified for any tool. Error handling is minimal; tools lack recovery guidance. Descriptions are functional but lack LLM-optimization details (e.g., when to use scroll vs mouse_move, coordinate system constraints). No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles. Parameter descriptions are adequate but sparse on constraints (e.g., scroll amount capped at 20, but not stated in description).
Current mouse position in screenshot coordinates.
Double left-click at (x, y) in screenshot coordinates.
Press a key or chord, e.g. 'enter', 'ctrl+s', 'alt+f4', 'ctrl+shift+t'. Key names follow pyautogui: enter, esc, tab, space, backspace, delete, up/down/left/right, home, end, pageup, pagedown, f1-f24, win, ctrl, alt, shift, printscreen, and single characters.
Left-click at (x, y) in screenshot coordinates.
Hold left button at start and drag to end, in screenshot coordinates.
Middle-click at (x, y) in screenshot coordinates.
Move the mouse to (x, y) in screenshot coordinates without clicking.
No output schemas documented. Tools lack structured return type definitions, forcing LLMs to guess what fields are returned (e.g., screenshot returns PNG bytes, but format/dimensions undocumented). Breaks tool chaining and context planning.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint). Tools like left_click, type, key are clearly destructive/write operations, but lack annotations. Agents cannot distinguish safe reads from risky writes without manual reasoning.
Parameter constraints not fully documented in descriptions. scroll.amount capped at 20, record.duration_seconds capped at 15, record.max_frames capped at 8, but these limits are not stated in parameter descriptions, only in tool description. LLMs may not respect undocumented constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Watch the screen for a period and return evenly spaced frames. Use to observe animations, loading states, or anything that changes over time. duration_seconds is capped at 15, max_frames at 8.
Right-click (context menu) at (x, y) in screenshot coordinates.
Take a screenshot of the primary monitor. Returns a downscaled PNG. All coordinates passed to the other tools must be in this downscaled image's pixel space.
Scroll at (x, y) in screenshot coordinates. direction: up, down, left, or right. amount is in wheel clicks. Horizontal scrolling is sent as shift+wheel.
Triple left-click (select line/paragraph) at (x, y) in screenshot coordinates.
Type text at the current keyboard focus. ASCII is typed key by key; anything else is pasted via the clipboard (previous clipboard contents are restored afterwards).
Wait before the next action, e.g. for a window or page to settle. Capped at 10 seconds.
No error handling or recovery guidance. Tools lack descriptions of failure modes (e.g., what if click coordinates are out of bounds? What if clipboard paste fails?). Agents have no guidance on retry or fallback strategies.
Ambiguous tool selection guidance. Multiple click variants (left_click, double_click, triple_click, right_click, middle_click) lack clear descriptions of when to use each. LLMs may pick wrong click type without explicit guidance.