Playwright MCP einrichten: Browsertests mit KI-Agenten

Microsofts Playwright-MCP-Server verbindet Agenten wie Claude Code, Codex, Cursor und den Copilot-Agenten in VS Code mit dem Framework zur Browserautomatisierung Playwright. Meine Empfehlung: zunächst für explorative Prüfungen und die Fehlersuche einsetzen, anschließend wichtige Erkenntnisse in überprüfte, wiederholbare Tests überführen.

Was leistet Playwright MCP?

Der Agent erhält Werkzeuge zur Browsersteuerung und eine strukturierte Beschreibung der Seite. MCP steht für Model Context Protocol und stellt die Verbindung her, über die der Agent diese Werkzeuge aufrufen kann. Der Server führt die Browseraktionen aus; der Agent entscheidet, welche Aktion er als Nächstes anfordert.

Ein Accessibility-Snapshot lässt sich mit dem Wegweiser in einem Gebäude vergleichen: Er beschreibt Räume und Türen anhand ihrer Funktion und ihres Namens. Ein Seiten-Snapshot erfasst entsprechend Schaltflächen, Links, Textfelder und deren zugängliche Namen. Der Agent wählt sein Ziel aus dieser Struktur aus, statt die richtige Klickposition in einem Bild zu erraten. Der Standardablauf benötigt kein Vision-Modell. Microsofts Überblick

Vor der Installation steht eine Grundsatzentscheidung an. Microsoft verweist Nutzer von Coding-Agenten inzwischen auch auf Playwright CLI mit Skills. MCP beschreibt Microsoft dagegen als sinnvoll, wenn der Browserzustand erhalten bleiben und die Seitenstruktur wiederholt untersucht werden soll. MCP passt zu Workflows, die diese fortlaufende Interaktion brauchen. Arbeitet der Agent bereits gut mit Shell-Befehlen, lohnt sich der Vergleich mit der CLI. Keine der beiden Varianten belegt für sich genommen, dass ein Kundenablauf erfolgreich geprüft wurde. Microsofts Vergleich von MCP und CLI

Weitere Bausteine für den eigenen Tool-Stack finden sich in unserer Übersicht der besten MCP-Server für 2026.

Einrichtung in Claude Code, Codex, Cursor und VS Code

Voraussetzung sind Node.js 18 oder neuer und ein Client mit MCP-Unterstützung. Die folgenden Befehle und Konfigurationen entsprechen den Beispielen aus Microsofts README. Es genügt die Anleitung für den verwendeten Client; die Varianten sind Alternativen und keine Schritte, die in jedem Editor nacheinander auszuführen wären. Voraussetzungen und Einrichtung

Claude Code

Diesen Befehl unverändert ausführen:

claude mcp add playwright npx @playwright/mcp@latest

Codex

Diesen Befehl unverändert ausführen:

codex mcp add playwright npx "@playwright/mcp@latest"

Alternativ lässt sich folgende Konfiguration in ~/.codex/config.toml ergänzen:

[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]

Cursor

Der manuelle Weg aus der README führt über Cursor Settings -> MCP -> Add new MCP Server. Einen Namen vergeben, den Typ command auswählen und Folgendes eingeben:

npx @playwright/mcp@latest

Über Edit lässt sich die Konfiguration prüfen oder um Argumente ergänzen. Die README enthält außerdem eine Schaltfläche zur Installation in Cursor.

VS Code

Diesen Befehl für die VS-Code-CLI unverändert verwenden:

code --add-mcp '{"name":"playwright","command":"npx","args":["@playwright/mcp@latest"]}'

Anschließend steht der Server dem GitHub-Copilot-Agenten in VS Code zur Verfügung. Microsofts README verlinkt zudem Installationsschaltflächen und die Anleitung zur MCP-Einrichtung in VS Code.

Die gemeinsame JSON-Konfiguration

Für Clients, die die Standardkonfiguration im JSON-Format aus der README verwenden, lautet das unveränderte Beispiel:

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

Wo diese Konfiguration hingehört, richtet sich nach der jeweiligen Client-Anleitung oben. Die alternative Konfiguration für Codex verwendet TOML, nicht dieses JSON. Bei der Wahl des passenden Agenten hilft unsere Übersicht zu KI-Coding-Agenten mit Browsertests.

Browser und Zugriff auf die Seiteninhalte wählen

Für den Einstieg empfehlen sich ein sichtbares Browserfenster, ein isoliertes Profil und Snapshots. Optionen werden in der Argumentliste des Servers nach @playwright/mcp@latest ergänzt. Die folgenden Angaben stammen aus Microsofts Konfigurationsreferenz.

Snapshot oder Vision bezeichnet die Art der Interaktion. Im Standardablauf dient browser_snapshot dazu, Ziele zu identifizieren. browser_take_screenshot hält den sichtbaren Zustand fest; ein Screenshot allein aktiviert jedoch keine Klicks auf Koordinaten. Für --caps=vision nennt die README die Werkzeuge browser_mouse_click_xy, browser_mouse_down, browser_mouse_drag_xy, browser_mouse_move_xy, browser_mouse_up und browser_mouse_wheel. Client und Modell müssen die zurückgegebenen Bilder für die visuelle Auswertung nutzen können. Werkzeugreferenz

Bei gewöhnlichen Formularen und der Navigation beginne ich mit Snapshots. Eine visuelle Prüfung ist sinnvoll, wenn das Erscheinungsbild zählt oder die Seitenstruktur ein Bedienelement nicht ausreichend beschreibt. Ein Accessibility-Snapshot liefert nützliche Belege zur Struktur, kann aber nicht bestätigen, dass die Seite korrekt aussieht.

Die wichtigsten Werkzeuge für Browser Testing

Die Kernwerkzeuge decken Navigation, Interaktion und das Sammeln von Belegen ab. Die Tabelle ordnet die in der README beschriebenen Kernwerkzeuge für Automatisierung und Tabs nach Aufgaben. Microsofts Werkzeugliste

Snapshot-basierte Aktionen verwenden eine Zielreferenz aus dem Seiten-Snapshot oder einen eindeutigen Selektor. Ein Selektor identifiziert ein Element auf der Seite. Nach einer wesentlichen Seitenänderung sollte der Snapshot aktualisiert werden, statt sich darauf zu verlassen, dass eine frühere Zielreferenz noch passt.

Zusätzliche Funktionen müssen ausdrücklich aktiviert werden. Die Optionstabelle nennt vision, pdf und devtools; in den Werkzeugabschnitten sind außerdem config, network, storage und testing ausdrücklich dokumentiert:

• PDF: --caps=pdf ergänzt browser_pdf_save.
• Belege für die Fehlersuche: --caps=devtools umfasst Tracing, Video, Aktionsaufzeichnung, Anmerkungen, Hervorhebungen und das Fortsetzen einer pausierten Ausführung. Beispielsweise markieren browser_start_tracing und browser_stop_tracing Anfang und Ende eines Traces.
• Prüfbedingungen: --caps=testing ergänzt browser_generate_locator, browser_verify_element_visible, browser_verify_list_visible, browser_verify_text_visible und browser_verify_value. Eine Assertion legt fest, welche Bedingung erfüllt sein muss.
• Netzwerksimulation: --caps=network ergänzt browser_network_state_set, browser_route, browser_route_list und browser_unroute für Offline-Verhalten und simulierte Anfragen.
• Speicher: --caps=storage ergänzt Funktionen zum Prüfen und Bearbeiten von Cookies, Local Storage und Session Storage sowie browser_storage_state und browser_set_storage_state.
• Effektive Einstellungen: --caps=config ergänzt browser_get_config.

Das sind die in der README dokumentierten Gruppen. Daraus folgt nicht, dass jeder Client sofort jedes Werkzeug bereitstellt. Fehlt ein Werkzeug, sollten die Werkzeugliste des installierten Pakets und die aktivierten Funktionen mit der README abgeglichen werden. Vollständige Werkzeugbeschreibungen

Drei sinnvolle Aufgaben für den Geschäftsalltag

Vorrang haben Abläufe, deren Ausfall Umsatz verhindert oder Kunden daran hindert, Kontakt aufzunehmen. Die folgenden Beispiele sind Vorschläge für Workflows, keine Aussagen über gemessene Einsparungen.

Den Weg zum Kauf absichern

Ein Shop-Entwickler könnte den Agenten beauftragen, in der Staging-Umgebung den Gast-Checkout durchzugehen: prüfen, ob der ausgewählte Artikel im Warenkorb landet, fiktive Lieferdaten eingeben und vor jeder echten Zahlung stoppen. Der Nutzen liegt darin, einen kaufverhindernden Fehler vor dem Kunden zu entdecken.

Eine zweite sinnvolle Aufgabe für dasselbe Team ist die Prüfung der Fehlerkorrektur: unvollständige Lieferdaten absenden, die Verständlichkeit der Fehlermeldung prüfen, die Angaben korrigieren und bestätigen, dass der Kunde fortfahren kann. Wer nur den Idealfall testet, übersieht den Kunden, der sich bei einer Eingabe vertippt.

Die Website nach einem Deployment prüfen

Nach einer Änderung an der Landingpage könnte ein Gründer den Agenten die neue Version öffnen, dem wichtigsten Call to Action folgen und prüfen lassen, ob er auf der vorgesehenen Registrierungs- oder Kontaktseite landet. Zum Auftrag gehören Belege aus der Seite sowie relevante Konsolenausgaben oder fehlgeschlagene Anfragen.

Ein Agenturentwickler könnte anschließend mit einem schmaleren Viewport prüfen und die Navigation wiederholen. So lassen sich möglicherweise verdeckte Menüs oder unerreichbare Schaltflächen erkennen. Der Screenshot bleibt eine Grundlage für die Prüfung, kein automatischer Nachweis visueller Qualität.

Formulare mit Testdaten durchspielen

Ein SaaS-Entwickler könnte bei einem ohne Anmeldung zugänglichen Registrierungsformular die Pflichtfelder, Validierungsmeldungen und den Korrekturablauf in einer lokalen oder Staging-Umgebung prüfen. Der Ablauf endet vor dem Anlegen eines echten Kontos, sofern die Eingaben nicht an ein eigens dafür vorgesehenes Testziel gehen.

Ein Entwickler für Betriebsabläufe könnte ein langes Formular in der Staging-Umgebung mit synthetischen Daten ausfüllen. Dabei werden Dropdowns, bedingte Felder und das Hochladen einer Testdatei geprüft, bevor die Daten an einen simulierten Endpunkt gesendet werden. Das hilft, Fehler bei der Feldzuordnung aufzudecken, ohne Kundendatensätze zu versenden oder einen echten Prozess auszulösen.

Praxisbeispiel: Der Gast-Checkout bleibt vor der Zahlung hängen

Der Agent braucht eine klar begrenzte Aufgabe und muss seine Schlussfolgerung belegen. Dies ist ein illustratives End-to-End-Beispiel mit einem bewusst angenommenen Fehler. Es handelt sich nicht um einen Testbericht aus einem echten Shop.

Die Beispielanwendung besteht aus einem Gastwarenkorb, einem Versandformular und einer Zahlungsseite. Das Versandformular übermittelt die Postleitzahl irrtümlich als postal, während das Backend postalCode erwartet. Als Testumgebung dient eine lokale oder Staging-Anwendung ohne Anmeldung, mit fiktiven Daten und ohne echte Zahlungsanbindung.

Der folgende Auftrag lässt sich an den Agenten geben. Die URL in eckigen Klammern wird durch die eigene Testumgebung ersetzt:

Die Isolation muss in der Serverkonfiguration mit --isolated aktiviert werden. Eine entsprechende Anweisung im Prompt allein konfiguriert den Server nicht.

In diesem Beispiel enthält der Anfrageinhalt postal, und die Antwort meldet das fehlende postalCode. Das stützt die Vermutung eines Zuordnungsfehlers. Bevor die Ursache als behoben gilt, sollte der Entwickler dennoch die Serialisierung des Formulars und die vom Backend erwartete Datenstruktur prüfen.

Beispiel für einen Agentenbericht:

Im nächsten Schritt wird die Zuordnung korrigiert. Anschließend werden sowohl der Ablauf mit ungültigen als auch der mit gültigen Eingaben erneut geprüft. Ist das Verhalten bestätigt, kann der Agent einen Playwright-Regressionstest entwerfen. Dessen Assertions werden überprüft, bevor der Test in den vorhandenen Test-Runner aufgenommen wird. Dieser letzte Schritt gehört zum Entwicklungsprozess; die MCP-Unterhaltung allein ist noch keine Regressionstestsuite.

Wo die Grenzen liegen und worauf der Browser-Agent zugreifen kann

Die schwächsten Prüfungen entstehen durch unklare Ziele oder eine unsichere Umgebung. Bei „Checkout prüfen“ muss der Agent die Erfolgskriterien selbst erfinden. „Bestätigen, dass gültige Lieferdaten zur Zahlungsseite führen, ohne eine Zahlung abzusenden“ ist dagegen ein überprüfbarer Auftrag.

In der Praxis gelten folgende Grenzen:

• Uneindeutige Seitenstruktur: Unbenannte Bedienelemente und stark Canvas-basierte Oberflächen machen den strukturierten Wegweiser weniger brauchbar. Meine Empfehlung: In der eigenen Anwendung zugängliche Beschriftungen korrigieren und visuelle Belege heranziehen, wo die Struktur nicht ausreicht.
• Wechselnder Zustand: Ein erneutes Rendern, ein Popup oder ein verzögerter Übergang kann die nächste Annahme des Agenten entkräften. Vor dem Fortfahren den entstandenen Zustand prüfen und auf den erwarteten Text oder Übergang warten.
• Profilkonflikte: Ein dauerhaft gespeichertes Profil kann jeweils nur von einer Browserinstanz genutzt werden. Microsoft empfiehlt isolierte Sitzungen oder unterschiedliche Werte für --user-data-dir, wenn mehrere Clients gleichzeitig denselben Arbeitsbereich nutzen.
• Abweichende Umgebung: Die Docker-Implementierung aus der README unterstützt ausschließlich Headless Chromium. Die Browserauswahl der allgemeinen CLI-Tabelle lässt sich daher nicht vollständig auf diesen Container übertragen.
• Unvollständige Abdeckung: Eine erreichte Seite belegt nicht, dass jede Validierung, jeder Browser, jedes Gerät und jedes Backend-Ergebnis funktionieren. Auch ein Screenshot beweist nicht, dass eine Bestellung korrekt gespeichert wurde. Das sind Grenzen des hier vorgeschlagenen Prüfablaufs.

Die Einschränkungen für Profile und Docker sind in Microsofts README dokumentiert.

Browserzugriff ist echter Zugriff. Microsoft stellt ausdrücklich klar, dass Playwright MCP keine Sicherheitsgrenze bildet. Das Standardprofil speichert den Browserzustand dauerhaft; die optionale Chrome-/Edge-Erweiterung kann sich mit vorhandenen Tabs und angemeldeten Sitzungen verbinden. Für die hier beschriebenen Aufgaben empfiehlt sich eine isolierte Sitzung ohne importierte Cookies und ohne Verbindung zum alltäglich genutzten Browser. Profile und Verhalten der Erweiterung

Der Agent kann Seiten abrufen, die aus der Browserumgebung erreichbar sind. Dazu können je nach Netzwerk neben öffentlichen Websites auch Entwicklungsserver oder interne Dienste gehören. Origin-Regeln ersetzen keine Netzwerkisolation: --allowed-origins und --blocked-origins schränken Weiterleitungen nicht ein und bilden ausdrücklich keine Sicherheitsgrenze. --allowed-hosts steuert die Host-Prüfung eingehender Verbindungen zum MCP-Server; die Option ist keine Liste erlaubter Websites für den Browser. Konfiguration und Sicherheit

Beim Dateizugriff ist dieselbe Sorgfalt nötig. Laut Dokumentation sind Dateien standardmäßig auf die Stammverzeichnisse der Arbeitsbereiche beschränkt, und die Navigation zu file:// ist gesperrt. --allow-unrestricted-file-access lockert diese Regeln. Microsoft beschreibt die Dateiprüfungen als Schutzvorkehrungen, nicht als sichere Abschottung. Noch weiter reicht browser_run_code_unsafe: Dieses Werkzeug führt JavaScript im Serverprozess aus und verfügt damit über dessen Zugriffsmöglichkeiten. Der Zugriff auf das Werkzeug sollte über die Client-Berechtigungen gesteuert und die Serverumgebung eingeschränkt werden. Konfigurationsschema und Werkzeuge

Screenshots, Seitentexte, Konsolenausgaben und Anfrageinhalte können Daten an den Agenten weitergeben. Deshalb fiktive Datensätze und reine Testendpunkte verwenden. Vor einer echten Abbuchung, Nachricht, Kontoerstellung oder einer anderen folgenreichen Übermittlung stoppen, sofern genau diese Aktion nicht ausdrücklich autorisiert wurde.

Playwright MCP, Chrome DevTools MCP oder Browserbase?

Die Wahl hängt von der Aufgabe und davon ab, wo der Browser laufen soll. Die Produkte überschneiden sich, übernehmen aber unterschiedliche Rollen.

Microsoft bietet außerdem --cdp-endpoint für die Verbindung zu einem Browser-Endpunkt an. Die Schnittstelle des Agenten und der Ausführungsort des Browsers sind deshalb getrennte Entscheidungen. Browserbase ist kein anderer Name für Microsofts Server. Unsere Übersicht der besten Browser für KI-Agenten behandelt diese übergeordnete Auswahl.

Was kostet der Einsatz, und welche zwei Angebote lohnen einen Versuch?

Ein sinnvoller Kostenvergleich betrachtet den bisherigen Prüfprozess und den gesamten automatisierten Workflow. Das Repository von Playwright MCP steht unter einer Apache-Lizenz. Die Installation liefert weder das Agentenmodell noch Rechenleistung, Testumgebungen oder menschliche Prüfung mit.

Für die Rechnung zählen die eigenen Werte:

• Vorher: Stunden für manuelle Prüfungen × Vollkosten pro Arbeitsstunde, zuzüglich vorhandener Testabonnements.
• Nachher: Agentennutzung + Browserinfrastruktur + menschliche Prüfung + Pflege von Testumgebungen und Tests.

Als konkreter Anhaltspunkt für Hostingkosten: Browserbase nennt für den Developer-Tarif $20/Monat mit 100 Browserstunden, danach $0.12 pro Browserstunde. Das sind Kosten für die Browserinfrastruktur, kein Gesamtpreis für den Checkout-Test eines Agenten. Browserbase-Preise

Die stärkste Geschäftsidee: Release-Abnahme als Dienstleistung

Eine kleine Agentur könnte vereinbarte Kundenabläufe nach jedem Deployment des Kunden prüfen. Für die kleinste sinnvolle Variante genügen eine Staging-URL und eine Abnahmecheckliste. Die erlaubten Abläufe ohne Anmeldung werden durchgespielt; daraus entsteht ein überprüfter Bericht mit Belegen und ausdrücklich benannten Lücken in der Testabdeckung. Der Kunde bezahlt dafür, dass jemand die Verantwortung für die Release-Prüfung übernimmt.

Das Nachfragesignal ist überschaubar: Die im Oktober 2026 abgerufenen DataForSEO-Schätzungen für englischsprachige Suchanfragen in den USA weisen 110 monatliche Suchanfragen für „automated browser testing“ und 10 für „checkout testing“ aus. Das sind Suchanfragen, keine Käufer. Die Zahlen sprechen dafür, zunächst eine klar eingegrenzte Dienstleistung mit bestehenden Kunden zu erproben, bevor Geld in ein breiter angelegtes Softwareprodukt fließt.

Der Haken liegt in der Pflege: Veränderte Abläufe, unklare Prüfbedingungen und Fehlalarme können die erhoffte Arbeitsersparnis aufzehren. Ein belastbarer Wettbewerbsvorteil entsteht durch eine nützliche Abnahmecheckliste und eine verlässliche Bewertung der Befunde, nicht durch die Installation eines öffentlich verfügbaren MCP-Servers.

Die zweite Geschäftsidee: Ein Formularprüfer für Staging-Umgebungen

Eine Webagentur könnte einen Prüfer entwickeln, der Formulare mit synthetischen Werten ausfüllt, Pflichtfeldfehler auslöst und bestätigt, dass eine korrigierte Übermittlung ein simuliertes Ziel erreicht. Der Einstieg gelingt am besten mit Formularen auf Websites, die die Agentur bereits betreut, und einem Bericht, dessen Ergebnisse ein Entwickler reproduzieren kann.

Derselbe englischsprachige US-Datensatz von DataForSEO schätzt 10 monatliche Suchanfragen für „website form testing“. Als eigenständiger Kanal zur Kundengewinnung ist das ein schwaches Signal. Meine Empfehlung: die Leistung zunächst als Ergänzung zur Website-Wartung verkaufen und wiederkehrende Nachfrage nachweisen, bevor daraus ein separates Produkt entsteht.

Der Haken liegt im empfangenden System. Eine scheinbar erfolgreiche Seite beweist nicht, dass eine Anfrage ihr Ziel erreicht hat. Das MVP benötigt neben den Browserbelegen einen Testendpunkt oder eine andere erlaubte Möglichkeit, den Eingang zu bestätigen.

Häufige Fragen zur Einrichtung

Der nächste Schritt am Montag: den Gastablauf mit dem unmittelbarsten Umsatzbezug auswählen, das erwartete Ergebnis und den Haltepunkt aufschreiben und den vorhandenen Coding-Agenten damit in die Staging-Umgebung schicken. Bevor der Umfang erweitert wird, die Belege gemeinsam mit dem Entwickler prüfen, der diesen Ablauf verantwortet.

Für einen auf den eigenen Release-Prozess abgestimmten Workflow zur Browserprüfung entwickeln wir KI-Agenten für Geschäftsprozesse.