desktop-touch-mcp
Related Servers
Alternatives to desktop-touch-mcp
- AlicenseAqualityAmaintenanceAllow AI agents to see and control a real Windows PC you own: observe (UIA + screenshots), click/type/drag/scroll, launch apps, owner Live View. BYOH — your machine, your key.16Apache 2.0
Related Servers
- FlicenseAqualityCmaintenanceWindows desktop automation MCP server enabling screenshot capture, precise visual locating of UI elements via vision models, and automated mouse clicking.41-
- FlicenseNot gradedqualityBmaintenanceMCP server that lets an LLM see and drive any running Windows app: attach a window, screenshot it, read its UI Automation tree, and send clicks, typed text, and key presses with pixel coordinates.-
- AlicenseNot gradedqualityCmaintenanceGUI automation MCP server that enables AI agents to see and control the Windows desktop using a local Vision LLM (Ollama), supporting screenshot analysis, mouse/keyboard actions, and autonomous task execution.4MIT
- AlicenseNot gradedqualityBmaintenanceMCP server providing AI-friendly computer-use primitives (capture, detect, click) to let LLM agents drive desktop GUI applications on Windows, macOS, and Linux.1MIT
- FlicenseAqualityAmaintenanceCross-platform desktop automation MCP server that lets AI agents capture screenshots, run OCR with UI-element classification, control mouse/keyboard, and launch programs on Linux, macOS, and Windows.201-
- AlicenseNot gradedqualityAmaintenanceA Windows computer use agent — FastMCP server that gives AI assistants hands on the real desktop: windows, UI elements, mouse, keyboard, screenshots, OCR, shortcuts, dialogs, and outcome verification.44MIT
TDQS
Scored across 30 tools
Each browser_* tool has a distinct purpose (open/click/fill/eval/overview/search/navigate/locate) and native tools split cleanly along click/keyboard/mouse/scroll/focus lines. However there is real overlap between browser_click vs browser_locate, mouse_click vs click_element, and screenshot vs workspace_snapshot vs desktop_state, and several tools (click_element, keyboard, desktop_state) lean on desktop_discover/desktop_act that aren't in the surface, muddying boundaries.
The browser_* and mouse_* families use a consistent namespace_verb pattern, but the rest mixes verb_noun (click_element, focus_window, run_macro, wait_until, scroll) with noun_verb (window_dock, workspace_launch, notification_show) and bare nouns (keyboard, clipboard, terminal, screenshot, excel). Names remain readable, but no single predictable convention governs the set.
30 tools is heavy and exceeds the typical 3-15 sweet spot, but the domain genuinely spans browser automation, native desktop control, terminal, Excel VBA, clipboard, and credential management, so most tools earn their place. Still, several are marginal (server_status, screenshot_gc, notification_show) making the surface feel padded.
The surface covers a broad lifecycle (navigate, act, observe, wait, snapshot, macro orchestration) with few obvious domain gaps. The notable hole is that descriptions repeatedly instruct agents to call desktop_discover/desktop_act for UIA discovery and value-setting, yet neither tool appears in the set, creating dead-end workflows.