Windows-MCP: An MCP Server That Lets Any LLM Drive Windows Without Vision Models
MCP Server for Computer Use in Windows. Use Any LLM (Vision Optional) Unlike many automation tools, Windows-MCP doesn't rely on any traditional computer vision techniques or specific fine-tuned models; it works with any LLMs, reducing complexity and setup time.
At a glance
- What is it?
- Windows-MCP is a Python-based MCP server that exposes Windows UI automation tools to any LLM, relying on native UI elements rather than computer vision. It targets Windows 7 through 11 and is licensed under MIT.
- Who is it for?
- Adopt Windows-MCP if you are building an AI agent that must operate on Windows desktops and you want to avoid vision-model overhead. Its reliance on native UI elements means it works only on Windows, and the README warns that non-English locales may require disabling the App-Tool.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Windows-MCP Actually Solves
Windows-MCP addresses a specific gap: giving an LLM a way to interact with the Windows desktop without requiring a vision model or custom fine-tuning. Most automation tools rely on screenshots and object detection, which adds complexity and setup time. Windows-MCP instead exposes tools that read the native UI tree and simulate input. The README claims it 'works with any LLMs, reducing complexity and setup time.' That is the core promise. The intended audience is developers building AI agents that need to navigate files, launch applications, click buttons, and type text on a Windows machine, for tasks like QA testing or general desktop automation. The project is a Model Context Protocol (MCP) server, meaning it plugs into any MCP-compatible client, such as Claude Desktop, and exposes a set of tools the LLM can call.
The Mechanism: Native UI Elements, Not Pixels
The key design choice is that Windows-MCP does not use computer vision. Instead, it interacts with the Windows UI automation framework to read the accessibility tree of the desktop. This is why vision is optional. The server provides a 'State-Tool' that captures the current window or UI state, and the README mentions a DOM mode for browsers. In DOM mode, the State-Tool focuses exclusively on web page content, filtering out browser UI elements. This works for Chrome and Edge via the RootWebArea exposed by UIA, and for Firefox it uses an IAccessible2 fallback because Firefox does not expose RootWebArea. That distinction matters: the mechanism is tightly coupled to Windows accessibility APIs. The practical effect is that the LLM receives structured state information rather than raw images, which reduces the need for a vision-capable model and lowers inference cost. The trade-off is that anything the UI framework cannot see, the tool cannot act on. Non-standard controls or custom-drawn interfaces may be invisible to the tool.
Installation and Configuration: Commands and Config Keys
The README gives concrete installation steps. You need Python 3.13 or later and the uv package manager. The server runs via uvx, so the simplest start command is `uvx windows-mcp serve`. You can also specify a transport: `uvx windows-mcp serve --transport sse --host localhost --port 8000` or `--transport streamable-http`. For running at login, the command is `windows-mcp install`, which creates a per-user Scheduled Task named `windows-mcp-server` and a wrapper script at `~/.windows-mcp/start-server.cmd`. Logs go to `~/.windows-mcp/server.log` and `server.error.log`. To remove it, use `windows-mcp uninstall`. For Claude Desktop, the README shows adding a server entry to `claude_desktop_config.json` with the command set to `uvx` and args `["windows-mcp", "serve"]`. For the Microsoft Store version of Claude Desktop, you must use the full absolute path to `uvx.exe` or `windows-mcp.exe` because the MSIX sandbox does not inherit PATH. The README warns that the config file location differs for the MSIX version: it is under `%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json`.
First-Run Timeout and Other Operational Caveats
A notable warning in the README is about the first run. It says: 'When you install this MCP server for the first time it may take a minute or two because of installing the dependencies in pyproject.toml. In the first run the server may timeout ignore it and restart it.' That is an unusual admission. Most tools do not tell you to expect a timeout. This suggests that the dependency installation is not fully handled by the MCP client's startup handshake, and you may need to manually restart the server after the first launch. Another caveat is the language requirement. The README states that 'English as the default language in Windows preferred else disable the App-Tool in the MCP Server for Windows with other languages.' That means if your system locale is not English, the App-Tool may not work correctly, and you must disable it. That is a real limitation for non-English users. Also, the README notes that typical latency between actions ranges from 0.2 to 0.5 seconds, but that depends on the number of active applications, system load, and the LLM's inference speed. So the latency is not a fixed guarantee.
Supported Transports and Browser Automation Scope
The server supports three MCP transports: stdio (the default), SSE, and streamable HTTP. The README shows commands for SSE and streamable HTTP, both with host and port arguments. This is useful if you need to run the server on a remote machine or if your MCP client cannot use stdio. For browser automation, the README highlights a 'DOM Mode' that focuses on web content and filters out browser UI. It supports Chrome, Edge, and Firefox, but with a caveat: Firefox uses an IAccessible2 fallback because it does not expose RootWebArea via UIA. That means Firefox support is not as direct as Chrome or Edge. The practical implication is that if your automation target is a web app, you should prefer Chrome or Edge for the most reliable state extraction. The DOM Mode is a different approach from screenshot-based browser agents; it relies on the accessibility tree, so it may miss dynamically rendered content that is not exposed to the accessibility API.
Alternatives and How They Differ
The most direct alternative to Windows-MCP is a vision-based desktop automation tool, such as a screenshot-driven agent that uses a vision-language model to interpret screen pixels. The difference is fundamental: Windows-MCP reads the UI tree, so it does not need a vision model, but it also cannot see anything that is not exposed through accessibility APIs. Vision-based tools can handle arbitrary graphical content, including games or custom-rendered interfaces, but they require a vision-capable LLM and often more compute. Another alternative is using a dedicated RPA tool like Power Automate Desktop, which has a visual designer and does not require an LLM at all. Power Automate is not MCP-based, so it does not integrate with Claude or other LLM agents natively. The choice depends on whether you want LLM-driven flexibility or a more traditional rule-based automation flow. Windows-MCP is the only one of these that plugs directly into an MCP client and works with any LLM.
Maintenance, Upgrade Path, and License
The project is under active development, with recent releases v0.8.5 (August 2026), v0.8.2 (June 2026), and v0.8.0 (May 2026). The README does not describe a specific upgrade procedure, but since it is distributed on PyPI, you can update by running `uvx windows-mcp` again, which will fetch the latest version. The project is not archived, and the last push was August 2026, so it appears to be maintained. The license is MIT, which means you can use, modify, and distribute the code freely, including in commercial projects, as long as you retain the copyright notice. The README does not mention any paid tiers or enterprise support, so you are on your own for troubleshooting beyond the GitHub issues and Discord link. The dependency footprint is described as minimal, but the first-run installation can be slow, which is a maintenance consideration for automated deployments.
Editorial conclusion
Adopt Windows-MCP if you are building an AI agent that must operate on Windows desktops and you want to avoid vision-model overhead. Its reliance on native UI elements means it works only on Windows, and the README warns that non-English locales may require disabling the App-Tool. Do not use it if you need cross-platform automation or if you expect the server to survive first-run timeouts; the README says to ignore the timeout and restart. Before adopting, verify that your LLM client can handle the MCP transport you choose (stdio, SSE, or streamable HTTP) and that your Windows version supports the UI Automation APIs it depends on. Also confirm that Python 3.13 and uv are available, since older Python versions are not supported.
Community notes