Terminator: Windows-Desktop-Automatisierung als MCP-Server für KI-Agenten

Welches Problem Terminator löst und für wen es gedacht ist

Klassische RPA-Werkzeuge erkennen Oberflächen über Koordinaten oder aufgezeichnete Klickpfade. Sobald ein Dialogfeld anders aussieht oder ein Button verschoben wird, bricht der Ablauf. Terminator setzt dagegen auf Element-Locators, die laut README Elemente über name, role oder window finden. Das ist der eigentliche Unterschied zu pixelbasierten Ansätzen. Die Zielgruppe sind Entwickler, die Abläufe über mehrere Windows-Programme hinweg automatisieren wollen, ohne für jedes Programm eine eigene Anbindung zu schreiben. Im README stehen drei Beispielanfälle: eine GCP-Instanz per CLI anlegen und verbinden, Vercel-Logs nach den häufigsten Fehlern durchsuchen, neue App-Features anhand aktueller Commits testen. Alle drei verbinden einen Browser oder ein Terminal mit einem Prüfschritt, der normalerweise manuelles Hinsehen erfordert. Der zweite Adressat sind Teams, die Prozesse ohne Programmierkenntnisse aufzeichnen und ausführen lassen wollen. Dafür verweist das README auf einen gehosteten Workflow-Builder unter mediar.ai. Wer nur eine einzelne Webseite scrapen will, braucht dieses Projekt nicht.

Wie der Kern aufgebaut ist: Rust, Locators und ein MCP-Agent als Vorschaltlayer

Die Automatisierungsprimitive liegen in Rust. Auf crates.io erscheinen terminator-rs und terminator-workflow-recorder als eigene Pakete, was nahelegt, dass der Kern und die Aufzeichnung getrennt versioniert werden. Der MCP-Agent liegt als eigenständiges Node-Paket terminator-mcp-agent vor und wird über npx gestartet. Damit ergibt sich eine klare Datenschichtung: ein MCP-Client wie Claude Code oder Cursor spricht JSON-RPC mit dem Agenten, der Agent ruft die Rust-Bibliothek auf, und diese führt Aktionen auf Fenstern, Elementen oder Displays aus. Das README beschreibt die Erkennung als mehrdimensional: Pixel, DOM und Accessibility-Tree werden kombiniert, um Elemente zuverlässig zu adressieren. Für Browserinhalte kommt eine Chrome-Erweiterung ins Spiel, die im Feature-Raster unter Browser Automation als Windows-Funktion geführt wird. Bemerkenswert ist die Aussage, dass Terminator die bestehende Browsersitzung nutzt und damit Cookies und Anmeldungen erhalten bleiben. Ein separater Browserkontext mit eigenem Profil entfällt. Ob das in jeder Umgebung ohne Neuanmeldung funktioniert, lässt sich aus dem Material nicht ableiten.

Der deterministische Anspruch und was das README dazu wirklich belegt

Das README formuliert den Kern so: Workflows werden als deterministischer Code vortrainiert, und KI wird nur zur Wiederherstellung aufgerufen, wenn ein Schritt fehlschlägt. Das ist ein nachvollziehbares Design. Ein aufgezeichneter Ablauf läuft als feste Sequenz, und ein Modell greift erst ein, wenn ein Locator ins Leere greift. Die Folgekosten sind geringer als bei einem Ansatz, der jeden Schritt von einem Modell planen lässt. Die Zahlen, die im README daneben stehen, sind allerdings nicht überprüfbar. Die Rede ist von 100x schneller als ChatGPT Agents, Claude, Perplexity Comet, BrowserBase und BrowserUse sowie von über 95 Prozent Erfolgsrate. Für keine dieser Angaben nennt das Repository eine Messmethode, eine Testsuite oder eine Umgebung. Wer diese Werte als Entscheidungsgrundlage nimmt, übernimmt eine Marketingaussage. Belastbar ist nur die Architekturbeschreibung: deterministische Ausführung mit KI-Fallback. Der Unterschied zu einem reinen LLM-Agenten ist damit struktureller Natur, nicht quantitativer.

Installation über MCP-Konfiguration

Für Claude Code nennt das README einen Einzeiler: claude mcp add terminator "npx -y terminator-mcp-agent@latest". Für andere Clients wie Cursor, VS Code oder Windsurf wird ein Eintrag in der MCP-Konfigurationsdatei gezeigt. Der Server heißt dort terminator-mcp-agent, als command steht npx, als args die Kombination -y und terminator-mcp-agent@latest. Optional lassen sich Umgebungsvariablen setzen: LOG_LEVEL auf info und RUST_BACKTRACE auf 1. Der zweite Wert ist ein Hinweis darauf, dass Fehler aus der Rust-Schicht bis in den Node-Prozess durchgereicht werden und dort als Backtrace sichtbar werden. Wer ohne npx arbeiten will, findet auf crates.io die Rust-Pakete; für Python existiert laut Feature-Raster ein Paket terminator, das über pip install terminator erreichbar ist, allerdings nur mit dem Status Partial. TypeScript wird über npm i @mediar-ai/terminator eingebunden und gilt als vollständig. Der MCP-Agent selbst verweist auf eine eigene README-Datei im Unterverzeichnis terminator-mcp-agent mit weiterführenden Setup-Schritten. Diese Datei lag nicht vor, deshalb bleiben Details zu Berechtigungen und Erstkonfiguration offen.

Plattformgrenze: Windows ja, alles andere nein

Das Feature-Raster ist eindeutig. Jede Zeile trägt unter Windows ein Yes, unter macOS und Linux ein No. Betroffen sind Element Locators, UI Actions wie click und type, Application Management, Window Management, Browser Automation, Workflow Recording, Monitor Management sowie Screen- und Element-Capture. Der Satz im README lautet: Terminator currently supports Windows only. Das ist keine Einschränkung am Rand, sondern die zentrale Randbedingung. Wer eine CI-Pipeline auf Linux-Runnern betreibt, kann den Automatisierungskern dort nicht einsetzen. Der macOS-Pfad führt laut README über die Webanwendung unter app.mediar.ai, also über einen gehosteten Dienst statt über die lokale Bibliothek. Damit verschiebt sich die Frage von der Bibliotheksintegration zur Datenhaltung: aufgezeichnete Workflows und Bildschirminhalte laufen dann über fremde Infrastruktur. Für regulierte Umgebungen ist das ein eigenständiger Bewertungspunkt, den die Repository-Beschreibung nicht auflöst.

Wo Terminator das falsche Werkzeug ist

Der Ansatz lebt von einer laufenden, entsperrten Windows-Sitzung mit sichtbaren Fenstern. Das README wirbt damit, dass Terminator den Cursor und die Tastatur nicht übernimmt und im Hintergrund arbeitet. Das ist ein Vorteil gegenüber Werkzeugen, die den Bildschirm blockieren, aber es bleibt eine Abhängigkeit von einer interaktiven Desktop-Session. Auf einem headless Server ohne Anmeldung ist das Modell nicht tragfähig. Ein zweiter Grenzfall: Aufgaben, die nur eine HTTP-Schnittstelle brauchen. Wer Vercel-Logs auslesen will, kommt mit der Vercel-API schneller und stabiler ans Ziel als mit einem Agenten, der eine Browseroberfläche bedient. Dasselbe gilt für GCP-Instanzen, für die es eine CLI und SDKs gibt. Terminator ist dann sinnvoll, wenn die Oberfläche die einzige Schnittstelle ist. Ein dritter Punkt betrifft die Zuverlässigkeit von Locators über Anwendungsupdates hinweg. Das README nennt name, role und window als Kriterien, aber keine Aussage darüber, wie sich Änderungen an einer Anwendung auf bestehende Aufzeichnungen auswirken. Wer Workflows über Jahre pflegen will, sollte diesen Punkt vor der Adoption klären.

Abgrenzung zu Playwright und zu LLM-gesteuerten Desktop-Agenten

Die Repository-Beschreibung nennt Terminator playwright for windows computer use. Der Vergleich ist aufschlussreich, weil er die Lücke markiert. Playwright steuert Browser über das DevTools-Protokoll und adressiert Elemente im DOM. Es kennt keine Windows-Fenster, keine nativen Dialoge und keine Anwendungen außerhalb des Browsers. Terminator erweitert die Reichweite auf den gesamten Desktop, verliert dabei aber die Plattformunabhängigkeit, die Playwright auszeichnet. Gegenüber reinen LLM-Agenten unterscheidet sich der Ansatz beim Ausführungsmodell: Ein LLM-Agent entscheidet bei jedem Schritt neu, welches Element gemeint ist, was flexibel, aber langsam und teuer ist. Terminator führt einen festen Ablauf aus und ruft das Modell nur zur Wiederherstellung. Das ist der eigentliche Architekturunterschied. Er hat einen Preis: Aufzeichnungen müssen gepflegt werden, und ein Ablauf, der nie aufgezeichnet wurde, kann nicht deterministisch laufen. Die Wahl hängt also davon ab, ob sich die Zielprozesse stabil genug beschreiben lassen, um sie einmal festzuhalten.

Wartung, Versionierung und Lizenz

Die Release-Historie zeigt einen kurzen Takt: v0.24.30 im März 2026, v0.24.31 und v0.24.32 Anfang April 2026, danach ein letzter Push Anfang Juni 2026. Die Versionsnummer steht noch bei 0.24, was auf eine Vorabphase hindeutet. Wer auf terminator-mcp-agent@latest setzt, zieht bei jedem Start die jeweils aktuelle Version. Das ist bequem und riskant zugleich, weil sich das Verhalten zwischen zwei Ausführungen ändern kann. Für reproduzierbare Umgebungen ist eine feste Versionsangabe statt latest die naheliegende Wahl; das README zeigt diese Variante nicht, sie ergibt sich aber aus der npm-Semantik. Die Lizenz ist MIT. Das erlaubt kommerzielle Nutzung, Änderung und Weitergabe, solange Lizenztext und Urheberrechtshinweis erhalten bleiben. Für Forks bedeutet das keine Einschränkung bei der Verbreitung. Markenrechte am Namen Terminator regelt die MIT-Lizenz nicht; wer das Projekt unter eigenem Namen weiterverbreitet, sollte das gesondert prüfen. Eine rechtliche Bewertung ersetzt dieser Absatz nicht.

Redaktionelles Fazit

Wer Windows-Anwendungen ohne GUI-Roboter-Framework automatisieren will und bereits einen MCP-fähigen Assistenten nutzt, findet hier einen schlanken Einstieg über npx -y terminator-mcp-agent@latest. Wer macOS oder Linux braucht, sollte nicht adoptieren: das README nennt Windows als einzige unterstützte Plattform. Vor dem Produktiveinsatz ist zu prüfen, ob der Browser-Teil die Chrome-Erweiterung voraussetzt und ob die eigene Umgebung mehr als einen Monitor umfasst, da Multi-Display-Support explizit als Windows-Feature gelistet ist. Die MIT-Lizenz erlaubt Forks, aber der Name Terminator und das Mediar-Branding bleiben davon unberührt.

Offizielle Quellen

1. License: MIT
2. mediar-ai/terminator on GitHub
3. Project website
4. README
5. Releases