Windows-MCP: an MCP server that drives the Windows UI without computer vision

The problem Windows-MCP solves, and who it is for

Most desktop automation stacks answer one question first: how does the agent see the screen? The common answer is a screenshot plus a vision model, or a fine-tuned model trained on UI screenshots. Windows-MCP takes the other branch. The README states that it "doesn't rely on any traditional computer vision techniques or specific fine-tuned models; it works with any LLMs". The agent reads the Windows accessibility tree instead of pixels.

That choice defines the audience. If you already have an MCP client such as Claude Desktop or an editor with MCP support, and you want that client to open applications, move windows, send keystrokes and read UI state on a Windows machine, this server is the adapter. It is not a framework for building agents, and it is not a cross-platform tool. The pyproject classifiers list Windows 10 and Windows 11, while the README's supported operating systems section also names Windows 7, 8 and 8.1. Treat the classifier list as the more conservative claim.

The second audience is QA and scripted UI testing. The README names QA testing as a use case, and the toolset (keyboard, mouse, window and UI state capture) maps onto that. What it does not give you is a record-and-replay harness. There is no assertion language and no test runner in the repository layout; the tests/ directory is for the project's own code.

How the server turns UI Automation into tool calls

The mechanism is Windows UI Automation (UIA), reached through comtypes and pywin32, both listed in pyproject.toml. The server walks the UIA tree of the foreground window and returns a text representation of it, which the model reads as a tool result. Actions come back the other way: the model picks a target from that text and the server performs the click or keystroke against the corresponding UIA element.

This is why the project can claim vision is optional. A button has a name, a control type and an automation ID in the UIA tree; a vision model has to infer all three from pixels. The trade is that anything UIA does not expose is invisible to the agent. Custom-drawn canvases, games and some Electron surfaces are the usual casualties.

The DOM mode is a targeted exception. The README describes `use_dom=True` on the State-Tool as focusing "exclusively on web page content, filtering out browser UI elements". It covers Chrome, Edge and Firefox, and notes that Firefox uses an IAccessible2 fallback because it does not expose `RootWebArea` through UIA. That fallback is a good illustration of the whole design: the project prefers one accessibility API and degrades to a second rather than falling back to screenshots.

On latency, the README gives a range of 0.2 to 0.5 seconds between actions such as consecutive mouse clicks, and attributes variation to active applications, system load and the inference speed of the LLM. That figure covers the gap between actions, not the model's own thinking time.

Installing Windows-MCP and running it as a login task

Prerequisites from the README: Python 3.13 or newer, and uv from Astral. Note the mismatch with pyproject.toml, which sets `requires-python = ">=3.14"`. Trust the packaging metadata, since that is what the installer enforces. The README also asks for English as the Windows default language, and says to disable the App-Tool if you use another language.

Install uv if you do not have it:

pip install uv

The README warns that the first install can take a minute or two while dependencies from pyproject.toml are fetched, and that the server may time out on that first run. If your client reports a failure, restart it rather than debugging the config.

The quickest path is to run the server directly from PyPI with uvx. The README gives three forms:

uvx windows-mcp serve
uvx windows-mcp serve --transport sse --host localhost --port 8000
uvx windows-mcp serve --transport streamable-http --host localhost --port 8000

The first speaks stdio, which is what a desktop MCP client expects. The other two expose the server over HTTP on port 8000, bound to localhost.

If you want the server running whenever you log in, the README documents an install command that creates a per-user Scheduled Task named `windows-mcp-server` plus a wrapper script at `~/.windows-mcp/start-server.cmd`:

windows-mcp install
windows-mcp install --transport sse --host 127.0.0.1 --port 8000

`windows-mcp uninstall` removes it. Logs land in `~/.windows-mcp/server.log` and `~/.windows-mcp/server.error.log`. Those two files are the first place to look when a client shows the server as disconnected.

For Claude Desktop, the README's recommended configuration runs the published package through uvx:

{
  "mcpServers": {
    "windows-mcp": {
      "command": "uvx",
      "args": ["windows-mcp", "serve"]
    }
  }
}

After editing `claude_desktop_config.json`, restart Claude Desktop fully and check that the server appears in the MCP tools list. If you installed Claude Desktop from the Microsoft Store, the README documents a wrinkle: the MSIX package virtualizes `%APPDATA%`, so the config lives under `%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\`, and Electron apps in that sandbox do not inherit the system PATH. You must use an absolute path to `uvx.exe` or `uv.exe` in the config.

Where Windows-MCP breaks down

The English-language requirement is the sharpest limitation, and it is not a soft one. The README says to set English as the default Windows language, otherwise disable the App-Tool. The App-Tool is the part that opens and manages applications, so on a non-English Windows install you lose a chunk of the surface area. The repository does not document what else degrades when UI element names are localized.

The second limitation is the accessibility tree itself. Because the agent reads UIA rather than pixels, applications that draw their own controls without exposing UIA providers are effectively opaque. The README does not claim otherwise, and there is no screenshot fallback described for the main State-Tool outside DOM mode.

Third, there is no sandbox. The server runs as the user who launched it and drives the real desktop. Nothing in the README describes a permission model, an allowlist of applications, or a confirmation step before an action executes. If you point an agent at this on your daily-driver machine, the agent's reach is your reach.

Finally, the Python floor. pyproject.toml requires 3.14, and the classifiers name only Python 3.14. If your environment is pinned to 3.12 or 3.13, uvx will resolve a different interpreter or fail; the README's "Python 3.13+" line will not save you.

Windows-MCP against screenshot-driven automation

The obvious alternative is an automation stack that screenshots the desktop and lets a vision-capable model reason over the image. The difference is not cosmetic. A screenshot pipeline needs a model that accepts images and is good at spatial grounding, and it needs a coordinate system stable enough that a click at (x, y) still lands on the same control after a window moves. A UIA pipeline addresses elements by their place in the accessibility tree, so a moved window does not invalidate the target.

The cost is coverage. Screenshots see everything a human sees, including a canvas that exposes no accessibility data. UIA sees only what the application publishes. For a browser or an Office document that is plenty. For a game or a bespoke drawing surface it is close to nothing.

Windows-MCP also differs from generic desktop-commander style MCP servers in scope. It is Windows-only by construction, built on comtypes, pywin32 and UIA, and it does not pretend to be portable. If your fleet is mixed, that is a real constraint, not a detail.

Upgrade path, licence and what the repository does not say

The project ships as a PyPI package, so the usual upgrade is re-resolving the version: uvx pulls the latest by default, and `uv tool install windows-mcp` pins a tool environment you control. Releases are tagged in the repository, with v0.8.5 dated 2026-08-01, v0.8.2 dated 2026-06-09 and v0.8.0 dated 2026-05-19. The last push to main was on 2026-08-01, which is the same day as the v0.8.5 release. There is no changelog file in the repository layout, so the release notes on the tag are the only upgrade documentation.

Licensing is MIT, declared both in the README and in the pyproject license field pointing at LICENSE.md. MIT is permissive: you can use, modify and redistribute the code, including commercially, provided the copyright notice and permission notice travel with it. That is a summary of the licence text, not legal advice; if you redistribute the server inside a product, have counsel read LICENSE.md.

One dependency deserves a second look before you deploy. posthog is a direct dependency in pyproject.toml. The README does not describe what is sent, to where, or how to turn it off. That is not an accusation, but it is a gap: a server with desktop control privileges that also links an analytics client should document its telemetry, and this one does not.

Editorial conclusion

Adopt Windows-MCP if you already run an MCP client on Windows 10 or 11, your Windows display language is English, and you want an agent to click, type and read UI state without a vision model. Do not adopt it if you need headless Linux or macOS automation, if you cannot run Python 3.14, or if you expect a sandbox: this server drives the real desktop with the privileges of the user who started it. Before wiring it into anything long-lived, verify three things: that your MCP client starts the server (the README notes the first run can time out while dependencies install), that your Windows language is English or that you have disabled the App-Tool, and that the command in your client config points at a real uvx.exe path on MSIX-packaged Claude Desktop.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes