Was ist Playwright MCP?
Mit Playwright MCP kann ein Agent in einem echten Browser Seiten öffnen, klicken, tippen, Formulare ausfüllen und Inhalte lesen. Statt Screenshots gibt er dem Modell den Accessibility-Snapshot von Playwright mit einer Referenz für jedes Element, sodass auch ein reines Textmodell auf der Seite handeln kann.
Die Installation erfolgt mit npx @playwright/mcp@latest (Node.js 18 oder neuer). Der Browser hält standardmäßig ein dauerhaftes Profil auf der Festplatte; --isolated hält es im Arbeitsspeicher, --extension verbindet sich mit deinem laufenden Chrome oder Edge, und --port stellt ihn über HTTP bereit. Rund 25 Kern-Tools werden standardmäßig geladen, 47 weitere für Netzwerk, Speicher, DevTools, Klicks nach Koordinaten, PDF und Test-Assertions lassen sich über --caps zuschalten.
Das aktuelle Release ist 0.0.83 vom 28. September 2026. Das README von Microsoft lenkt Coding-Agenten inzwischen zu seiner Playwright CLI mit Skills, die laut Microsoft sparsamer mit Tokens umgeht, und positioniert MCP für lang laufende Browser-Schleifen mit Zustand.
Playwright MCP installieren
npx @playwright/mcp@latestLohnt sich Playwright MCP?
Playwright MCP bleibt der Standard-Browser-Server für Agenten, und der Grund ist das Snapshot-Modell. Tools wie browser_navigate, browser_click und browser_snapshot arbeiten mit Elementreferenzen aus dem Accessibility-Baum, nicht mit Bildschirmkoordinaten. So kann jedes Textmodell den Browser steuern, und Aktionen landen auf dem richtigen Element. Er betreibt Chromium, Firefox und WebKit, was Chrome DevTools MCP nicht kann.
Die Kosten sind Tokens, und Microsoft sagt das auch. Das README empfiehlt Coding-Agenten inzwischen die separate Playwright CLI mit Skills, weil die CLI keine Tool-Schemas und keine ausführlichen Accessibility-Bäume in den Kontext lädt, und reserviert MCP für explorative Automatisierung, selbstheilende Tests und lang laufende Workflows. Es gibt Abhilfen: browser_find durchsucht einen Snapshot, statt ihn ganz zurückzugeben, und --mobile emuliert ein Pixel 10 oder iPhone 17, was laut README meist leichtere Seiten bedeutet.
Die Standardeinstellungen verdienen einen Blick. Das Browserprofil bleibt auf der Festplatte erhalten, alles, wo sich der Agent anmeldet, bleibt also angemeldet, und ein Profil kann nicht zwei Clients gleichzeitig bedienen. Der Dateizugriff ist auf Workspace-Roots beschränkt, und file://-URLs sind gesperrt, sofern du nicht --allow-unrestricted-file-access übergibst. --allowed-origins und --blocked-origins gibt es, aber laut Dokumentation ist keines davon eine Sicherheitsgrenze, und beide gelten nicht für Weiterleitungen. Der HTTP-Modus bindet an localhost, sofern du nicht --host 0.0.0.0 setzt, was das Docker-Beispiel tut.
Die Versionsnummern 0.0.x verkaufen ein Projekt unter Wert, das 38.500 GitHub-Sterne hat und alle ein bis zwei Wochen ein Release bringt; die Korrekturen im September betrafen Dialoge während des Seitenladens und verwaiste Browserprozesse in Docker. Gegenüber Browserbase tauschst du lokale Kontrolle und keine Rechnung gegen einen gehosteten Browser, der mit Skalierung und Bot-Erkennung besser zurechtkommt.
Wo es sich lohnt
Eine QA-Engineerin in einem Web-Team mit einer unzuverlässigen Playwright-Testsuite
Einen Agenten einen fehlschlagenden Checkout-Ablauf nachstellen und einen stabilen Locator vorschlagen lassen
Sie startet den Server mit --isolated und --caps=testing, damit der Agent den Ablauf Schritt für Schritt durchgehen und die Assertion-Tools nutzen kann. Es kostet nur Modell-Tokens, allerdings treibt jeder Snapshot einer großen Checkout-Seite diese in die Höhe.
Ein Operations-Analyst in einem Logistikunternehmen mit 30 Beschäftigten
Wöchentliche Zahlen aus einem Lieferantenportal ohne API abrufen
Er nutzt ein gespeichertes Profil, damit der Agent angemeldet bleibt, und eine dotenv-Datei über --secrets, damit das Passwort nicht in den Chat getippt wird. Das Risiko: Das dauerhafte Profil hält diese Sitzung für jede spätere Aufgabe, es sollte also ein eigenes Konto sein.
Eine Frontend-Entwicklerin, die einem Layoutfehler nachgeht, der nur in Safari auftritt
Sehen, wie eine Seite in WebKit dargestellt wird, ohne einen Mac zu besitzen
Sie startet den Server mit dem WebKit-Browser und lässt den Agenten zur defekten Komponente navigieren und einen Snapshot machen. Chrome DevTools MCP kann das nicht, weil es nur Chrome unterstützt.
Bevor du dich festlegst
- Einrichtung
- npx @playwright/mcp@latest in einem beliebigen MCP-Client; das README enthält Installationsschritte für Claude Code, Codex, Copilot CLI, Cursor, VS Code, Gemini CLI und weitere. Ein erster browser_navigate-Aufruf klappt innerhalb von Minuten, sobald ein Browser installiert ist.
- Integrationen
- Standardmäßig rund 25 Tools, darunter browser_navigate, browser_click, browser_type, browser_fill_form und browser_snapshot; --caps ergänzt Tools für network (4), storage (17), devtools (13), vision (6), testing (5), pdf und config.
- Daten und Datenschutz
- Läuft lokal; nichts geht an Microsoft. Seiten sind nicht vertrauenswürdige Eingaben, die Prompt Injection enthalten können, das dauerhafte Profil behält Cookies, und das README stellt klar, dass der Server keine Sicherheitsgrenze ist.
- Kosten im großen Maßstab
- Kostenlos; die Kosten sind Modell-Tokens für Snapshots, die Microsoft nicht beziffert. Gemeinsames Hosting heißt Docker-Image, und das unterstützt nur Headless-Chromium.
- Grenzen
- Ein dauerhaftes Profil pro Browserinstanz, parallele Clients brauchen also --isolated oder ein separates --user-data-dir; browser_wait_for begrenzt Wartezeiten auf 30 Sekunden; der Extension-Modus funktioniert nur mit Chrome und Edge.
Was gut ist
- Elementreferenzen aus Accessibility-Snapshots, kein Vision-Modell nötig
- Chromium, Firefox und WebKit
- Zuschaltbare Funktionsgruppen halten den Standardsatz bei rund 25 Tools
- Isolierter, dauerhafter und Extension-Modus
Was nicht
- Snapshots voller Seiten sind lang und wiederholen sich nach jeder Aktion
- Das standardmäßig dauerhafte Profil hält Logins zwischen den Läufen
- Allow- und Blocklisten für Origins sind keine Sicherheitsgrenze
- Microsoft verweist Coding-Agenten stattdessen auf seine CLI
Am besten für
Entwickler und QA-Engineers, die einen Agenten Web-Apps über mehrere Browser-Engines hinweg erkunden, testen oder automatisieren lassen wollen.
Alternativen zu Playwright MCP
Playwright MCP: häufige Fragen
- Lohnt sich Playwright MCP?
- Playwright MCP ist der Browser-Server für den Einstieg, sofern du lange Snapshots einplanst und dir merkst, dass Microsoft ihn ausdrücklich nicht als Sicherheitsgrenze bezeichnet. Wir bewerten es mit 4.7 von 5.
- Was kostet Playwright MCP?
- Kostenlos und unter der Apache-2.0-Lizenz; du bezahlst nur die Modell-Tokens, die die Snapshots verbrauchen.
- Welche Nachteile hat Playwright MCP?
- Snapshots voller Seiten sind lang und wiederholen sich nach jeder Aktion; Das standardmäßig dauerhafte Profil hält Logins zwischen den Läufen; Allow- und Blocklisten für Origins sind keine Sicherheitsgrenze; Microsoft verweist Coding-Agenten stattdessen auf seine CLI.
- Für wen eignet sich Playwright MCP?
- Entwickler und QA-Engineers, die einen Agenten Web-Apps über mehrere Browser-Engines hinweg erkunden, testen oder automatisieren lassen wollen.
- Was kostet Playwright MCP für ein Team oder im Produktivbetrieb?
- Kostenlos; die Kosten sind Modell-Tokens für Snapshots, die Microsoft nicht beziffert. Gemeinsames Hosting heißt Docker-Image, und das unterstützt nur Headless-Chromium.
- Ist Playwright MCP sicher für Firmendaten?
- Läuft lokal; nichts geht an Microsoft. Seiten sind nicht vertrauenswürdige Eingaben, die Prompt Injection enthalten können, das dauerhafte Profil behält Cookies, und das README stellt klar, dass der Server keine Sicherheitsgrenze ist.
- Was sind die besten Alternativen zu Playwright MCP?
- Die nächsten Alternativen, die wir getestet haben, sind Chrome DevTools MCP und Browserbase MCP.
Antworten geprüft am 22. Okt. 2026.