Windows-MCP: Windows-Desktop-Automation über MCP, ohne Computer Vision
MCP-Server für Computernutzung unter Windows. Verwenden Sie ein beliebiges LLM (Vision optional). Im Gegensatz zu vielen Automatisierungstools basiert Windows-MCP nicht auf herkömmlichen Computer-Vision-Techniken oder spezifischen, fein abgestimmten Modellen. Es funktioniert mit allen LLMs und reduziert die Komplexität und Einrichtungszeit.
Auf einen Blick
- Was ist das?
- CursorTouch/Windows-MCP ist ein Python-basierter MCP-Server, der LLMs den Zugriff auf Windows-Oberflächen ermöglicht. Der Text ordnet den UIA-Ansatz, das Werkzeugset, die Installation per uvx und die Anbindung an Claude Desktop ein.
- Für wen ist es gedacht?
- Windows-MCP passt für Windows-Nutzer, die einem LLM Dateinavigation, App-Steuerung und UI-Interaktion erlauben wollen, ohne ein vision-fähiges Modell oder ein trainiertes Detectoren-Set zu betreiben. Weniger geeignet ist es für Produktionsumgebungen mit strengen Sicherheitsanforderungen, denn ein Agent, der Maus und Tastatur simuliert, braucht klare Grenzen.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Was Windows-MCP ist und wen es anspricht
Windows-MCP von CursorTouch ist ein leichtgewichtiger, quelloffener MCP-Server, der KI-Agenten mit dem Betriebssystem Windows verbindet. Das Projekt zählt zu den Aufgaben, die es abdeckt: Dateinavigation, Anwendungssteuerung, Interaktion mit UI-Elementen und QA-Tests. Der Server ist in Python geschrieben, steht unter der MIT-Lizenz und läuft laut README auf Windows 7, 8, 8.1, 10 und 11.
Das Alleinstellungsmerkmal liegt in der Modellunabhängigkeit. Viele Automationswerkzeuge setzen auf klassische Computer-Vision-Verfahren oder auf feinabgestimmte Spezialmodelle. Windows-MCP braucht laut eigener Beschreibung weder das eine noch das andere und funktioniert mit beliebigen LLMs, was Komplexität und Einrichtungsaufwand senkt. Ein vision-fähiges Modell ist optional, keine Voraussetzung.
Die Reichweite des Projekts lässt sich an ein paar Zahlen ablesen: rund 6.800 Sterne und 831 Forks auf GitHub, plus die selbst berichtete Angabe, über 2 Millionen Nutzer im Claude-Desktop-Verzeichnis erreicht zu haben. Solche Werte stammen aus dem README und sind Werksangaben, keine unabhängigen Messungen. Für die technische Bewertung zählen eher die im Folgenden beschriebenen Mechanismen.
UIA statt Pixelanalyse: der technische Ansatz
Statt Screenshots zu analysieren, arbeitet Windows-MCP direkt mit den nativen UI-Elementen von Windows. Der Server öffnet Anwendungen, steuert Fenster, simuliert Tastatur- und Mauseingaben und liest den Zustand von Fenstern und Oberflächen aus. Weil die Informationen strukturiert aus der Benutzeroberfläche kommen, muss das LLM keine Pixel interpretieren; ein textbasiertes Modell reicht aus.
Für Browserautomation gibt es einen eigenen Modus: Der State-Tool kennt die Option use_dom=True, die sich ausschließlich auf den Inhalt einer Webseite konzentriert und Browser-UI-Elemente herausfiltert. Das ergibt sauberere Ausgaben für Webautomation. Unterstützt werden Chrome, Edge und Firefox, wobei Firefox laut README einen IAccessible2-Fallback nutzt, weil es RootWebArea nicht über UIA preisgibt. Diese Einschränkung ist ein Detail, das man kennen sollte, bevor man Firefox in einen Automationslauf einplant.
Die Reaktionszeiten nennt das README ebenfalls konkret: Zwischen zwei Aktionen, etwa von einem Mausklick zum nächsten, liegen typischerweise 0,2 bis 0,5 Sekunden. Die Werte schwanken je nach Anzahl aktiver Anwendungen, Systemlast und Inferenzgeschwindigkeit des Modells. Für Batch-Verarbeitung ist das brauchbar, für interaktive Sitzungen sollte man die Verzögerung einkalkulieren.
Installation per uvx und Dauerbetrieb als geplante Aufgabe
Voraussetzungen sind Python 3.13 oder neuer sowie der Paketmanager uv, installierbar mit pip install uv oder dem Skript von astral.sh. Danach genügt der Aufruf uvx windows-mcp serve, um den Server ad hoc zu starten. Für Netzwerkbetrieb gibt es Transportvarianten wie --transport sse oder --transport streamable-http, jeweils mit --host und --port, zum Beispiel --host localhost --port 8000.
Wer den Server dauerhaft haben will, nutzt windows-mcp install. Dieser Befehl legt eine benutzerspezifische geplante Aufgabe namens windows-mcp-server an und schreibt ein Wrapper-Skript nach ~/.windows-mcp/start-server.cmd. Entfernen lässt sich die Installation mit windows-mcp uninstall, Protokolle landen in ~/.windows-mcp/server.log und ~/.windows-mcp/server.error.log. Damit ist der Standardpfad für die Fehlersuche klar umrissen.
Zwei Hinweise aus dem README verdienen Beachtung: Beim ersten Start dauert die Installation wegen der Abhängigkeiten aus pyproject.toml ein bis zwei Minuten, und der Server kann beim ersten Lauf einen Timeout melden, den man ignoriert und durch einen Neustart behebt. Außerdem empfiehlt das Projekt, Windows auf Englisch als Standardsprache zu betreiben; bei anderen Sprachen soll man das App-Tool des Servers deaktivieren. Das ist eine ungewöhnliche Einschränkung, die man bei mehrsprachigen Systemen vorab prüfen sollte.
Anbindung an Claude Desktop inklusive MSIX-Sonderweg
Der dokumentierte Weg in Claude Desktop läuft über die claude_desktop_config.json. Der empfohlene Eintrag setzt als Kommando uvx mit den Argumenten windows-mcp und serve. Wer lieber aus dem Quellcode arbeitet, klont das Repository und nutzt uv mit --directory auf den Projektordner. Danach ist ein vollständiger Neustart von Claude Desktop nötig, damit der Server in der Werkzeugliste erscheint.
Die Windows-Store-Version von Claude Desktop bringt eine eigene Stolperfalle mit. Die MSIX-Paketierung virtualisiert %APPDATA%, weshalb die Konfigurationsdatei nicht unter %APPDATA%\Claude\ liegt, sondern unter %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json. Eine Installation aus dem Claude-Verzeichnis scheitert in dieser Umgebung, weil die Variable ${__dirname} auf einen nicht virtualisierten Pfad aufgelöst wird.
In der MSIX-Sandbox erben Electron-Anwendungen zudem nicht den System-PATH, weshalb die Konfiguration den vollständigen absoluten Pfad zu uvx.exe oder windows-mcp.exe braucht, etwa C:\Users\<user>\.local\bin\uvx.exe. Den korrekten Pfad findet man mit where uvx. Wer diese Details kennt, spart sich eine frustrierende Debuggingrunde, denn nichts an der Serverkonfiguration selbst ist falsch, wenn der Store-Client nur die falschen Pfade sieht.
Erweiterbarkeit, Releases und Grenzen laut Dokumentation
Das Werkzeugset umfasst laut README Grundoperationen für Tastatur und Maus sowie das Erfassen von Fenster- und UI-Zuständen. Das Projekt beschreibt sich als anpassbar und erweiterbar, Werkzeuge lassen sich eigenen Automations- oder Integrationsbedürfnissen anpassen. Wer tiefer einsteigen will, findet mit windows-use auf PyPI zusätzlich einen Agenten, der selbst auf Windows-MCP aufbaut, und den Eintrag des Servers im MCP Registry.
Der Release-Verlauf zeigt aktive Pflege: v0.8.0 erschien im Mai 2026, v0.8.2 im Juni 2026 und v0.8.5 am 1. August 2026. Zwischen zwei und drei Monaten zwischen den Ausgaben ist ein Rhythmus, der kontinuierliche Arbeit nahelegt. Auf GitHub stehen 21 offene Issues, was bei dieser Projektgröße ein überschaubarer Rückstand ist.
Grenzen benennt das README nur teilweise. Es nennt keine feste Kompatibilitätsmatrix über die Windows-Versionen hinaus, keine Leistungsgarantie und keinen dokumentierten Umgang mit Zugangsdaten oder sensiblen Anwendungen. Die sprachabhängige Einschränkung des App-Tools ist dokumentiert, die Auswirkungen eines Agenten mit vollem Eingriffszugriff auf Maus und Tastatur muss man jedoch selbst bewerten. Für einen Testlauf empfiehlt sich ein isoliertes Konto, in dem uvx windows-mcp serve ohne Schadenspotenzial läuft.
Fazit: Für wen Windows-MCP in Frage kommt
Windows-MCP füllt eine Lücke zwischen Bildschirm-basierten Automationsagenten und klassischen UI-Testframeworks. Der Verzicht auf Computer Vision senkt die Anforderungen an Modell und Hardware, und der strukturierte Zugriff über UIA liefert dem LLM verlässlichere Zustandsinformationen als Pixelinterpretation. Wer beliebige LLMs an Windows anbinden will, bekommt hier einen schlanken, MIT-lizenzierten Weg mit dokumentierter Dauerbetriebsoption.
Nicht ideal ist das Projekt für Umgebungen, in denen Agents strikte Berechtigungen brauchen oder in denen Windows in einer anderen Sprache als Englisch läuft und das App-Tool unverzichtbar ist. Auch wer eine breite Kompatibilitätsdokumentation oder Sicherheitsauditberichte erwartet, sucht vergebens. Die Entscheidung sollte auf einem eigenen Test basieren: Server starten, Werkzeugliste im Client ansehen, einen begrenzten Automationslauf ausführen und die Logs unter ~/.windows-mcp/server.error.log auf Fehler prüfen.
Redaktionelles Fazit
Windows-MCP passt für Windows-Nutzer, die einem LLM Dateinavigation, App-Steuerung und UI-Interaktion erlauben wollen, ohne ein vision-fähiges Modell oder ein trainiertes Detectoren-Set zu betreiben. Weniger geeignet ist es für Produktionsumgebungen mit strengen Sicherheitsanforderungen, denn ein Agent, der Maus und Tastatur simuliert, braucht klare Grenzen. Vor dem Einsatz sollte man uvx windows-mcp serve in einem Testkonto ausführen, die Werkzeugliste im MCP-Client prüfen und die Logs unter ~/.windows-mcp/server.log auf Fehler kontrollieren.
Community-Notizen