Windows control server for the Model Context Protocol
MCPControl provides 21 well-defined tools with consistent naming conventions (verb_noun pattern: get_*, click_*, move_*, etc.) and complete input schemas using Zod validation. Tool descriptions are substantive (ranging 75-250 chars) and explain what each tool does. However, output schemas are not documented, tool responses are not specified in the code, making it impossible to verify what fields agents should expect. Error handling guidance is absent; tools do not indicate what happens on failure or how to recover. Parameter descriptions are clear but sparse in some cases (e.g., 'Key to press' lacks specifics on valid key names). No tool annotations (readOnlyHint, destructiveHint) are present despite ~60% of tools being destructive (mouse clicks, keyboard input, clipboard writes, window manipulation). Security concerns exist: clipboard operations expose raw system state; no indication of permission gates, rate limits, or audit logging. Overall, definitions are above-average in structure and naming clarity but weak in output specification, error guidance, and security declaration.
Clear the clipboard content
Move mouse to coordinates, click, then return to original position
Click the mouse at the current position
Double click at current or specified position
Drag the mouse from one position to another
Focus a specific window by its title
Get information about the currently active window
Output schemas are not documented. Tool response structures are not specified, forcing LLMs to infer what data they return. This violates pattern:tool and makes it impossible to verify field names, types, pagination, or required IDs for chaining.
No error handling guidance. Tools do not describe failure modes, recovery steps, or error classification (retryable vs fatal). LLMs have no actionable guidance if a tool call fails.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get the current content of the clipboard
Get the current cursor position
Get the screen dimensions
Take a screenshot optimized for AI readability, especially for text-heavy content. Uses default settings: JPEG format, 85% quality, grayscale enabled, and 1280px width (preserving aspect ratio). Supports region capture, format options, quality adjustment, and custom resize settings.
Check if the clipboard contains text
Hold or release a keyboard key with optional duration
Move the mouse cursor to specific coordinates
Press a specific keyboard key
Press multiple keys simultaneously (e.g., keyboard shortcuts)
Move a specific window to new coordinates
Resize a specific window by its title
Scroll the mouse wheel up or down
Set the content of the clipboard
Type text using the keyboard
No tool annotations (destructiveHint, readOnlyHint, idempotentHint). 13 tools perform destructive or mutation operations (clicks, keyboard input, clipboard writes, window manipulation) but are not annotated. LLMs cannot distinguish read-only tools from destructive ones, risking unintended side effects.
Parameter 'key' in press_key, hold_key lacks specificity. Description says 'Key to press (e.g., enter, tab, escape)' but does not enumerate valid key names, case sensitivity, or modifier key syntax. LLMs must guess whether to pass 'enter' or 'Return', 'shift' or 'Shift', etc.
Clipboard tools (get_clipboard_content, set_clipboard_content, clear_clipboard) expose raw system clipboard state with no permission gates, rate limits, or audit logging. Sensitive data (passwords, tokens, PII) could be read or overwritten without safeguard. No scope declaration (read:clipboard, write:clipboard).
Mouse and keyboard tools lack idempotency guarantees. click_at, move_mouse, type_text do not declare whether repeated calls with the same input produce the same result. Agents retry on ambiguous failures, non-idempotent tools risk duplicate clicks or duplicated text.
Short, generic descriptions on read-only tools. get_screen_size ('Get the screen dimensions'), get_cursor_position ('Get the current cursor position'), get_active_window ('Get information about the currently active window') lack context for when an LLM should call them instead of alternatives. No explanation of what 'screen dimensions' or 'cursor position' return or when they are useful.