Puppeteer MCP: Seiten im lokalen Browser öffnen und die Konsole lesen

Für wen

Für alle, die ein Modell in einem echten lokalen Browser Webseiten öffnen, die Konsole lesen oder Screenshots hinterlassen lassen wollen. Die Evidenz besagt: Dies ist ein MCP-Server für Browserautomatisierung mit Puppeteer; das Modell kann mit Seiten interagieren, Screenshots machen und JavaScript in einer echten Browserumgebung ausführen.

Er läuft auf Ihrer Maschine und kann daher auch lokale Dateien und lokale/interne IPs erreichen. Nur anbinden, wenn Sie diese Privatsphäregrenze akzeptieren und sensible Daten im Blick behalten können. Die Evidenz nennt keine Client-Namen; abgedeckt ist nur: Sie haben bereits einen Client, der MCP konfigurieren kann, und können npx ausführen.

Die offizielle Seite liegt im Baum servers-archived. Die Evidenz nennt keinen separaten Wartungsstatus und keine Alternative; behandeln Sie das nicht als aktuelles, weiter gepflegtes Produkt.

Ersten Versuch in 3 Minuten abschließen

Gehen Sie den in der Evidenz genannten NPX-Pfad. In der MCP-Konfiguration des Clients verwenden:

"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-puppeteer"]

Machen Sie Docker nicht gleichzeitig zum Hauptpfad. Die Evidenz ergänzt nur: Docker nutzt headless Chromium; NPX öffnet ein Browserfenster.

Voraussetzungen: Node/npx ist lokal installiert; der erste Versuch öffnet nur eine öffentliche Seite, auf die Sie zugreifen dürfen, ohne Formular oder Login. Nach dem Start läuft ein Browser auf diesem Rechner und kann lokale Dateien und interne Adressen erreichen.

Konfigurationsort: die MCP-Serverkonfiguration des Clients (stdio-Befehl und Argumente). Nach dem Speichern Client neu starten oder neu laden.

Risikoarmer erster Aufruf: nur das vollständig geschriebene puppeteer_navigate aufrufen und zur gerade genannten URL navigieren. Die Evidenz gibt keine Parameterfelder; die collect-Zusammenfassung erwähnt auch screenshot, click, hover, fill, select, evaluate, aber die zugehörigen Locator sind nicht ausgeklappt — beim ersten Versuch nicht aufrufen.

Erfolgssignal: Auf dem NPX-Pfad sollte ein lokales Browserfenster öffnen und auf der angegebenen Adresse bleiben. Anschließend die Ressource console://logs (Text-Konsolenausgabe) oder screenshot://<name> (PNG) lesen. Erscheint kein Fenster, zuerst prüfen, dass Sie NPX und nicht Docker nutzen.

Anwendungsfälle

Fall 1: Das Modell eine bestimmte öffentliche Seite öffnen lassen. puppeteer_navigate aufrufen. Die Evidenz garantiert nur „zu einer beliebigen URL im Browser navigieren“; Timeouts, Redirects oder lokale Cookies stehen nicht darin. Bestätigen können Sie: Die Navigation geschieht im echten lokalen Browser; nehmen Sie keine isolierte Cloud-Sitzung an.

Fall 2: Nach dem Öffnen die Konsole prüfen oder einen Screenshot hinterlassen. Der erste Evidenzpunkt nennt Screenshots und JavaScript-Ausführung; die Ressourcen-Evidenz gibt console://logs (alle Browser-Konsolenmeldungen) und screenshot://<name> (PNG eines erfassten Screenshots). Die Evidenz nennt keinen Screenshot-Toolnamen, wie <name> entsteht, und keine evaluate-Parameter. Der zweite Schritt liest nur diese Ressourcen oder bleibt bei „die Evidenz garantiert nur Screenshot/JS“ — keine Selektoren oder Skripte erfinden.

Nutzungsgrenzen

Ein lokaler Browser kann lokale Dateien und lokale/interne IPs erreichen und sensible Daten austragen. NPX öffnet ein sichtbares Fenster; Docker ist headless Chromium. Das Verhalten unterscheidet sich; nicht mischen und dann ein Fenster als Erfolgssignal nehmen. Das einzige vollständig benannte Tool ist puppeteer_navigate; Interaktion (Klick, Ausfüllen) hat keinen parametrisierten Locator und hat Seiteneffekte. Ressourcen nennen nur Konsole und Screenshots; es gibt keinen Undo-, Cookie-Lösch- oder Browser-Schließschritt. Die Evidenz nennt keine Client-Liste, kein Berechtigungsmodell und kein Ersatzpaket nach der Archivierung.