windows2-mcp
# wincore-mcp
MCP server exposing Windows desktop UI Automation as tools for AI agents, built on top of [appium-wincore-driver](https://github.com/verisoft-ai/appium-wincore-driver).
Previously shipped as `desktop-driver-mcp` inside `appium-wincore-driver`; now split into its own package so the MCP server and the Appium driver can be installed, versioned, and released independently.
## Prerequisites
- An Appium server running with `appium-wincore-driver` installed:
```bash
npm install -g appium
appium driver install --source=npm appium-wincore-driver
appium --port 4723
```
## Install
```bash
npm install -g wincore-mcp
```
or run directly with `npx wincore-mcp`.
## Configure
Environment variables (read at startup):
| Variable | Default | Description |
|---|---|---|
| `APPIUM_HOST` | `127.0.0.1` | Host of the running Appium server |
| `APPIUM_PORT` | `4723` | Port of the running Appium server |
## MCP client config
```json
{
"mcpServers": {
"wincore-mcp": {
"command": "npx",
"args": ["-y", "wincore-mcp"],
"env": {
"APPIUM_HOST": "127.0.0.1",
"APPIUM_PORT": "4723"
}
}
}
}
```
## Tools
See [docs/TOOLS.md](docs/TOOLS.md) for the full tool reference (~85 tools across session
management, element discovery, interaction, UIA patterns, window management, vision, and more),
generated from the current tool source.
## Development
```bash
npm install
npm run build
npm run test
npm run lint
```
## License
Apache-2.0
TDQS
Scored across 90 tools
The descriptions are unusually careful about distinguishing near-neighbors: maximize_current_window vs maximize_window, get_windows vs get_window_handles, click_element vs advanced_click vs invoke_element, and set_value vs set_element_value all carry explicit guidance. A few pairs (get_windows/get_window_handles, get_attribute/get_element_info/get_element_value/get_text) still overlap enough that misselection is plausible, but the docs largely resolve them.
The vast majority follow a clean snake_case verb_noun pattern (find_element, switch_to_window, set_clipboard, start_recording_screen) with a consistent is_* prefix for predicates. Minor deviations exist—bare verbs (hover, scroll) and adjective-prefixed names (advanced_click, find_by_vision)—but overall the convention is predictable.
90 tools is far too many to present as a coherent set, well past the 25+ threshold where selection burden becomes real. The domain (full Appium Windows driver surface) is broad and the extension-command fallback shows curation effort, but the count is still excessive for practical agent use.
Coverage is essentially exhaustive for Windows UI automation: session lifecycle, element discovery and interaction, UIA pattern operations, window/frame/webview context switching, input simulation, file and clipboard I/O, screen recording, vision fallbacks, and raw PowerShell escape hatch. No obvious dead ends for the stated purpose.