Chrome DevTools MCP installieren

Chrome DevTools MCP gibt einem Coding-Agenten Zugriff auf einen echten Chrome-Browser samt DevTools-Fähigkeiten wie Performance-Traces, Netzwerkanalyse und Konsolenzugriff. Für die Einrichtung ist keine Vorab-Installation nötig: Der Server wird per npx gestartet und lädt sich dabei selbst.

Voraussetzungen für Chrome DevTools MCP

Eine LTS-Version von Node.js und eine aktuelle stabile Chrome-Version. Ob Node passt, zeigt:

node --version

Chrome DevTools MCP in den Client einbinden

MCP-Clients lesen ihre Server aus einer JSON-Konfiguration. Der Eintrag für Chrome DevTools MCP sieht so aus:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

Wo diese Datei liegt, unterscheidet sich je nach Client. Der offizielle Client-Konfigurationsleitfaden beschreibt die Einrichtung unter anderem für Claude Code, Cursor, Codex, VS Code/Copilot, Gemini CLI, Windsurf und Cline.

Slim-Modus für einfachere Aufgaben

Wer nur grundlegende Browser-Aufgaben braucht, kann den Werkzeugumfang mit --slim reduzieren, optional kombiniert mit --headless:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest", "--slim", "--headless"]
    }
  }
}

Nutzungsstatistiken und CrUX-Abfragen deaktivieren

Standardmäßig sammelt Google anonyme Nutzungsstatistiken und Performance-Werkzeuge können Trace-URLs an die Chrome-User-Experience-Report-API (CrUX) senden. Beides lässt sich per Flag abschalten:

npx -y chrome-devtools-mcp@latest --no-usage-statistics --no-performance-crux

Verbindung prüfen

Nach dem Neustart des Clients mit einer einfachen Aufgabe testen, etwa „Öffne example.com und mache einen Screenshot", um zu bestätigen, dass der Browser startet und der Agent eine Antwort erhält. Passiert nichts, prüfen, ob Chrome (oder Chrome for Testing) tatsächlich installiert und aus der Laufzeitumgebung erreichbar ist – der Server bringt keine eigene Browser-Binärdatei mit.

Flags für CI-Umgebungen kombinieren

In Continuous-Integration-Umgebungen ohne Display-Server ist --headless zusätzlich zu --slim erforderlich, wenn nur grundlegende Automatisierung benötigt wird; ohne dieses Flag kann der Server scheitern, ein sichtbares Browserfenster zu öffnen, und mit einem Fehler abbrechen. Für das Debugging fehlgeschlagener CI-Läufe kann es helfen, --headless lokal auf einer Maschine mit Bildschirm vorübergehend zu entfernen, um das Problem visuell nachzuvollziehen, statt es rein aus Logs zu diagnostizieren.

Verbindung an einen bestehenden Chrome-Prozess anschließen

Statt jedes Mal einen neuen Browser zu starten, lässt sich der Server über die Option --browserUrl mit einem bereits laufenden Chrome-Prozess verbinden, sofern dieser mit aktiviertem Remote-Debugging-Port gestartet wurde. Das spart Startzeit bei wiederholten Testläufen und erlaubt es, denselben Browserzustand über mehrere Agentensitzungen hinweg beizubehalten.

Fehlerbehebung bei fehlenden Werkzeugen

Zeigt der Client nach der Konfiguration keine Chrome-DevTools-Werkzeuge an, liegt es meist an einer fehlerhaften JSON-Syntax in der Konfigurationsdatei oder an einer zu alten Node.js-Version. Ein zweiter häufiger Fall ist, dass Chrome zwar installiert, aber nicht im Systempfad auffindbar ist – dann lässt sich der Pfad zur Chrome-Binärdatei explizit über --executablePath angeben.

Quelle: github.com/ChromeDevTools/chrome-devtools-mcp, geprüft am 05.09.2026.