Playwright MCP: Die erste Browser-Navigation im Client abschließen

Für wen das ist

Dieser Leitfaden richtet sich an Menschen, die bereits einen MCP-Client nutzen und bereit sind, auf diesem Rechner einen Browser zu starten, um Seiten zu automatisieren. Zu entscheiden ist, ob Playwright MCP jetzt an den aktuellen Client angebunden werden soll – nicht, ob zuerst eine lange Einführung gelesen werden muss. Die harte Voraussetzung ist Node.js 18 oder neuer auf diesem Rechner; bei einer zu alten Version die Konfiguration nicht weiter schreiben. Das Repository beschreibt es als MCP-Server, der Browserautomatisierung bereitstellt und Seiten über Accessibility-Snapshots versteht, nicht über Screenshots. Zwei Punkte müssen akzeptiert werden: Auf diesem Rechner erscheinen browserbezogene Prozesse, und die angegebenen Adressen werden wirklich aufgerufen. Wer nur das Repository durchstöbern und den Client keinerlei Browseraktionen ausführen lassen will, ist auf diesem Weg falsch. Die Belege nennen keine Branchen, Rollen oder Teamgrößen; hier werden auch keine erfundenen Nutzerbilder ergänzt.

Ersten Versuch in 3 Minuten abschließen

Nur den offiziellen Standard-MCP-Konfigurationsweg verwenden. Die Serverkonfiguration im gerade genutzten MCP-Client öffnen – die Belege nennen keinen konkreten Dateinamen, also den MCP-Einstieg dieses Clients nutzen – und einen Dienst namens playwright hinzufügen, Befehl npx, Argument @playwright/mcp@latest. Keine zweite primäre Installationsmethode daneben stellen.

Zuerst prüfen, dass der Rechner Node.js 18 oder neuer erfüllt, dann das folgende JSON unverändert in die Konfiguration schreiben, byteidentisch, ohne geänderte Schlüsselnamen und ohne geänderte Leerzeichen:

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

Speichern, dann den Client neu starten oder neu laden. Das Erfolgssignal ist, dass die Namen browser_navigate und browser_navigate_back in der Werkzeugliste erscheinen. Erst wenn diese Namen sichtbar sind, gilt die Verbindung; ein aufpoppendes Browserfenster oder eine geöffnete Seite nicht als abgeschlossene Installation werten.

Nach der Verbindung nur einen Probeaufruf machen: browser_navigate verwenden. Die Belege halten nur den Werkzeugnamen fest – keine Parametertabelle, keine Beispiel-URL, keinen Undo-Pfad. Was ausgefüllt wird, darf sich nur nach der Werkzeugbeschreibung richten, die der Client gerade zeigt; Parameter oder Endpunkte nicht selbst erfinden. Dieser Aufruf lässt den lokalen Browser die angegebene Adresse besuchen, erzeugt Netzwerkanfragen und Seitenladevorgänge und hinterlässt browserbezogene Prozesse auf dem Rechner. Es ist keine reine Leseoperation und kein Nullrisiko. Vor dem Aufruf muss feststehen, dass die Adresse selbst gewählt wurde und dass sie einen Besuch akzeptieren kann. Nach dem Aufruf ist der Prüfpunkt, ob dieser Aufruf zurückkehrt. Wird anschließend browser_navigate_back verwendet, ändert das ebenfalls die aktuelle Seite des Browsers und kann erneut Netzwerkanfragen erzeugen. Vor dem Aufruf prüfen, dass die aktuelle Sitzung bereits eine Historie hat, in der zurückgegangen werden kann.

Anwendungsfälle

Fall 1: Mit browser_navigate eine ausdrücklich selbst gewählte Seite öffnen. Der Zeitpunkt ist, wenn beide Werkzeugnamen bereits erschienen sind und eine Adresse vorliegt, die einen Besuch akzeptieren kann. Die Belege lassen sich nur auf diesen Werkzeugnamen abbilden; es gibt keine Beispiel-URL und keine ausgeschriebenen Parameterfelder. Nebenwirkung ist echte Navigation und Netzwerkzugriff. Die Adresse vor dem Aufruf erneut prüfen, nach dem Aufruf sehen, ob dieser Aufruf beendet ist. Das nicht als lokale Offline-Vorschau verstehen und nicht annehmen, dass der Seiteninhalt nicht gelesen wird.

Fall 2: Mit browser_navigate_back zur vorherigen Seite zurückkehren. Der Zeitpunkt ist, wenn in derselben Browsing-Sitzung gerade eine Navigation abgeschlossen wurde. Die Belege nennen wieder nur diesen Werkzeugnamen – keine Historienlisten-API und keinen Rückgängig- oder undo-Pfad. Ohne erfolgreiche Vorwärtsnavigation kann der Zurückgang scheitern oder auf einer unerwarteten Seite landen; die Belege beschreiben den Zustand nach einem Fehlschlag nicht. Der Aufruf ändert ebenfalls die aktuelle Seite und kann erneut das Netzwerk anfragen. Vor dem Aufruf bestätigen, dass tatsächlich navigiert wurde; Prüfpunkt bleibt, ob dieser Aufruf zurückkehrt.

Nutzungsgrenzen

Die untere Laufzeitschwelle ist Node.js 18 oder neuer; eine niedrigere Version nicht erzwingen. Die Fähigkeit endet bei der Browserautomatisierung; beschrieben wird die Nutzung von Accessibility-Snapshots statt Screenshots. In den Belegen tauchen keine Screenshot-Werkzeuge auf und auch keine Befehle zum Schließen des Browsers, Bereinigen der Sitzung, Deinstallieren oder undo. Nicht annehmen, es gebe kein Netz, kein lokales Lesen und keine Privatsphäregrenze: Nach der Navigation wird die Zielseite aufgerufen, Seiteninhalt kann in den Clientkontext gelangen, und auf dem Rechner erscheinen Browserprozesse. Scheitert der erste Versuch, zuerst die Node-Version und die Byteidentität des JSON mit dem offiziellen Fragment prüfen, dann sehen, ob die beiden Werkzeugnamen erschienen sind. Nicht auf eine Installationsmethode wechseln, die in den Belegen nicht vorkommt. Fähigkeiten, die in den Belegen nicht genannt sind, nicht als bereits unterstützt behandeln.