Playwright MCP

Playwright MCP ist ein Model-Context-Protocol-Server, der Browser-Automatisierung über Playwright bereitstellt. Er wird von Microsoft im Repository microsoft/playwright-mcp gepflegt.

Anders als Ansätze, die Screenshots auswerten, arbeitet der Server auf dem Accessibility-Baum der Seite. Das Modell bekommt also eine strukturierte Darstellung der Seite statt eines Bildes.

Der Funktionsumfang umfasst laut Dokumentation unter anderem:

Navigieren, Klicken, Tippen, Hovern, Drag-and-drop, Datei-Uploads, Formulareingaben, Tastatureingaben, Screenshots, Snapshots und den Umgang mit Dialogen. Dazu kommen Tab-Verwaltung, das Mitschneiden und Simulieren von Netzwerkanfragen samt Offline-Modus, Zugriff auf Cookies, localStorage und sessionStorage, Video- und Trace-Aufzeichnung, Codegenerierung, koordinatenbasierte Mausaktionen, PDF-Ausgabe sowie Prüfungen für Tests.

Voraussetzung ist Node.js in Version 18 oder neuer. Der Server wird ohne vorherige Installation direkt per npx gestartet:

npx @playwright/mcp@latest

In einem MCP-Client wird er über die übliche Konfigurationsdatei eingebunden:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest"
      ]
    }
  }
}

Die Dokumentation beschreibt die Einrichtung für eine Reihe von Clients, darunter Codex, Claude Code, Cursor, VS Code, Copilot, Cline, Gemini CLI, LM Studio, Warp und Windsurf.

Warum der Accessibility-Baum statt Screenshots

Viele Browser-Automatisierungswerkzeuge für KI-Modelle setzen auf Screenshots: Das Modell bekommt ein Bild der Seite und muss darauf Koordinaten für Klicks schätzen. Playwright MCP geht laut Dokumentation den umgekehrten Weg und arbeitet mit dem Accessibility-Baum – derselben strukturierten Darstellung, die auch Screenreader nutzen. Das Modell erhält damit benannte Elemente wie Buttons, Links oder Formularfelder statt Pixel, was Klicks und Eingaben deutlich zuverlässiger macht und weniger Tokens verbraucht als ein Bild. Screenshots bleiben als zusätzliches Werkzeug verfügbar, etwa zur visuellen Kontrolle, sind aber nicht die primäre Grundlage der Steuerung.

Betriebsarten: stdio, HTTP und Docker

Für die meisten MCP-Clients läuft Playwright MCP als lokaler stdio-Prozess, der direkt über npx gestartet wird und keine offene Netzwerkverbindung benötigt. Für Szenarien, in denen mehrere Clients denselben Server nutzen sollen oder der Server auf einer anderen Maschine läuft, lässt sich stattdessen ein eigenständiger HTTP-Endpunkt starten, den Clients über eine URL ansprechen. Für den Betrieb in Containern stellt das Projekt ein Docker-Image bereit; die Dokumentation weist ausdrücklich darauf hin, dass im Container derzeit nur Chromium im Headless-Modus unterstützt wird, während lokal auch Chrome, Firefox, WebKit und Edge mit sichtbarem Fenster zum Einsatz kommen können.

Für wen sich Playwright MCP eignet

Der Server eignet sich für alle, die einen KI-Agenten reale Weboberflächen bedienen lassen wollen: End-to-End-Tests aus der Beschreibung heraus statt aus festem Testcode, wiederkehrende Datenerfassung von Websites ohne offizielle API, das Ausfüllen mehrstufiger Formulare oder das automatisierte Prüfen, ob eine Seite nach einer Änderung noch wie erwartet funktioniert. Wegen des Accessibility-Baum-Ansatzes eignet sich Playwright MCP außerdem gut für Barrierefreiheitsprüfungen, weil sich exakt die Struktur auswerten lässt, die auch assistive Technologien sehen. Für reines Auslesen von Webinhalten ohne Interaktion ist ein einfacherer Fetch-Server oft die leichtere Wahl, weil kein Browserprozess gestartet werden muss.

Häufige Fragen

Braucht Playwright MCP eine separate Browser-Installation? Nein, die benötigten Browser werden von Playwright selbst verwaltet und bei Bedarf automatisch heruntergeladen. Funktioniert der Server ohne sichtbaren Bildschirm? Ja, im Headless-Modus läuft er auch auf Servern ohne grafische Oberfläche; für Docker ist aktuell ohnehin nur der Headless-Betrieb vorgesehen. Bleiben Anmeldedaten zwischen Sitzungen erhalten? Im Standardprofil ja, im isolierten Modus wird der Sitzungszustand beim Schließen verworfen.

Node.js 18 oder neuer und ein MCP-Client. Für einen sichtbaren Browser braucht die Laufzeitumgebung eine grafische Sitzung; alternativ kann der Server headless oder als eigenständiger HTTP-Dienst gestartet werden.

Den Server direkt über npx starten und den Befehl in der MCP-Konfiguration des Clients hinterlegen. Eine globale Installation ist nicht erforderlich.

Für einen eigenständigen lokalen HTTP-Endpunkt den Server mit --port 8931 starten und im Client http://localhost:8931/mcp als URL eintragen. Für reproduzierbare Installationen kann statt @latest die unten genannte Version festgeschrieben werden.

npx @playwright/mcp@latest

Der lokale stdio-Server verlangt keine eigene Anmeldung. Anmeldungen an besuchten Websites laufen über das Browserprofil, einen importierten Storage State oder die Browser-Erweiterung. Ein per HTTP bereitgestellter Endpunkt besitzt keine eingebaute Benutzeranmeldung und muss bei Zugriff über ein Netzwerk zusätzlich abgesichert werden.

Benötigt Netzwerkzugriff zu den automatisierten Websites und die Berechtigung, einen Browserprozess zu starten. Datei-Uploads und Ausgaben greifen standardmäßig nur auf MCP-Roots beziehungsweise das aktuelle Arbeitsverzeichnis zu. Zusätzliche Browserrechte wie Zwischenablage oder Standort werden nur über --grant-permissions freigegeben.

Der Server verarbeitet Seiteninhalte als Accessibility-Snapshots sowie – je nach aktivierten Werkzeugen – Screenshots, Konsolen- und Netzwerkdaten, Formulareingaben, Downloads, Videos und Traces. Im Standardprofil bleiben Cookies, localStorage, sessionStorage und Anmeldestatus lokal erhalten; im isolierten Modus wird der Sitzungszustand beim Schließen verworfen. Bei HTTP-, Proxy- oder CDP-Betrieb können diese Daten zusätzliche Systeme passieren.

Webseiten können schädliche oder irreführende Anweisungen enthalten. Ein Agent kann mit einer angemeldeten Browsersitzung reale Aktionen auslösen, vertrauliche Inhalte auslesen oder Daten hochladen. Dauerhafte Profile und gespeicherte Traces können Sitzungstokens oder personenbezogene Daten enthalten. Nur benötigte Hosts, Roots und Browserrechte freigeben, für sensible Aufgaben isolierte Profile verwenden und HTTP-Endpunkte nicht ungeschützt ins Netz stellen.