Chrome DevTools MCP — Anwendungsfälle, Installieren & Live-Demo

Warum nutzen

Hauptfunktionen

Echtes Chromium — rendert die Seite genauso wie Ihr Browser
Performance-Traces mit Insights (LCP, CLS, renderblockierende Ressourcen)
Vollständiger Netzwerk-Tab-Zugriff — Request/Response-Bodies, Timing, Redirects
DOM-Snapshots, Screenshots und Click/Type/Scroll-Aktionen
Konsolenprotokoll-Erfassung und Live-JS-Auswertung im Seitenkontext
Gepflegt von dem Chrome DevTools-Team bei Google

Live-Demo

In der Praxis

chrome-devtools.replay ▶ bereit

0/0

Installieren

Wählen Sie Ihren Client

~/Library/Application Support/Claude/claude_desktop_config.json · Windows: %APPDATA%\Claude\claude_desktop_config.json

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

Öffne Claude Desktop → Settings → Developer → Edit Config. Nach dem Speichern neu starten.

~/.cursor/mcp.json · .cursor/mcp.json

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

Cursor nutzt das gleiche mcpServers-Schema wie Claude Desktop. Projektkonfiguration schlägt die globale.

VS Code → Cline → MCP Servers → Edit

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

Klicken Sie auf das MCP-Servers-Symbol in der Cline-Seitenleiste, dann "Edit Configuration".

~/.codeium/windsurf/mcp_config.json

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

Gleiche Struktur wie Claude Desktop. Windsurf neu starten zum Übernehmen.

~/.continue/config.json

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

Continue nutzt ein Array von Serverobjekten statt einer Map.

~/.config/zed/settings.json

{
  "context_servers": {
    "chrome-devtools": {
      "command": {
        "path": "npx",
        "args": [
          "-y",
          "chrome-devtools-mcp"
        ]
      }
    }
  }
}

In context_servers hinzufügen. Zed lädt beim Speichern neu.

claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp

Einzeiler. Prüfen mit claude mcp list. Entfernen mit claude mcp remove.

Anwendungsfälle

Praxisnahe Nutzung: Chrome DevTools

Diagnostizieren Sie, warum eine Seite langsam ist, mit einem Lighthouse-ähnlichen Trace

👤 Frontend- und Performance-Ingenieure ⏱ ~20 min intermediate

Wann einsetzen: Eine Seite fühlt sich träge an und Sie möchten, dass Claude einen Trace ausführt und den tatsächlichen Engpass aufzeigt, anstatt zu raten.

Voraussetzungen

Ziel-URL lädt sich ohne Login (oder Sie führen Auth zuerst durch) — Nutzen Sie navigate_page mit einer URL; für Auth-gated-Seiten, melden Sie sich zuerst über chrome-devtools click/type Tools an

Ablauf

Führen Sie einen Performance-Trace aus

Öffnen Sie https://example.com/product/123. Führen Sie einen Performance-Trace mit 4x CPU-Drosselung und einem Slow-3G-Netzwerkprofil aus. Nennen Sie mir das LCP, CLS und TBT.✓ Kopiert

→ Drei Metrik-Zahlen plus eine Trace-Zusammenfassung
Finden Sie den Hauptverursacher

Welches einzelne Asset oder Skript trägt am meisten zur LCP-Verzögerung bei? Zeigen Sie das Request-Timing.✓ Kopiert

→ Spezifische URL identifiziert, mit Timing-Aufschlüsselung (DNS/Connect/TTFB/Download)
Schlagen Sie eine konkrete Lösung vor

Was ist die kostengünstigste Lösung, um das LCP unter 2,5s zu bringen? Schlagen Sie eine Änderung vor (preconnect, preload, defer, lazy oder bundle-split) mit spezifischen hinzuzufügenden Zeilen.✓ Kopiert

→ Actionbarer HTML/JS-Diff, nicht eine generische Liste

Ergebnis: Eine Performance-Regression mit einer benannten Ursache und einer spezifischen Lösung, überprüfbar durch erneutes Ausführen des Traces nach Anwendung.

Fallstricke

Trace variiert bei jedem Durchlauf — einmalige Zahlen täuschen — Führen Sie den Trace 3x aus und nehmen Sie den Median, bevor Sie zu einer Schlussfolgerung kommen
Lokale/Dev-Builds unterscheiden sich von der Produktion — Tracen Sie gegen eine Production-URL oder ein CDN-gehostetes Preview, nicht localhost ohne Kompression

Kombinieren mit: filesystem · github

Verifizieren Sie, dass die Funktion, die Claude gerade codiert hat, tatsächlich in einem Browser funktioniert

👤 AI-unterstützte Entwickler, die die Schleife bei ihrem Agent schließen ⏱ ~10 min beginner

Wann einsetzen: Claude hat gerade Frontend-Code bearbeitet. Bevor Sie 'fertig' sagen, möchten Sie, dass es die Seite öffnet, auf den Button klickt und bestätigt, dass es funktioniert.

Voraussetzungen

Dev-Server läuft — npm run dev in einem anderen Terminal; notieren Sie die URL

Ablauf

Öffnen Sie die Funktion und machen Sie einen Screenshot

Öffnen Sie http://localhost:3000/new-feature. Machen Sie einen Screenshot. Beschreiben Sie, was Sie sehen — entspricht das der Absicht?✓ Kopiert

→ Screenshot plus ehrliche Beschreibung (könnte flaggen 'Button wird off-screen gerendert')
Üben Sie die Interaktion aus

Klicken Sie auf den 'Submit'-Button mit Testdaten: {email: '[email protected]'}. Erfassen Sie die Netzwerk-Anfrage, die ausgeht, und die Antwort.✓ Kopiert

→ Netzwerk-Eintrag mit 200er Antwort und passendem Payload
Prüfen Sie die Konsole auf Fehler

Gibt es Konsolenfehler oder Warnungen während dieses Ablaufs? Beziehen Sie React-Hydratungs-Warnungen oder fehlende Key-Warnungen ein.✓ Kopiert

→ Saubere Konsole oder eine spezifische Lösung für gefundene Warnungen

Ergebnis: Eine selbst getestete Funktion mit Screenshot + Netzwerk-Trace als Beweis. Schließt die Lücke 'KI hat Code geschrieben, der nicht funktioniert'.

Fallstricke

Screenshot sieht gut aus, aber die Interaktion ist fehlerhaft — Üben Sie immer den User-Flow aus (click/type), nicht nur visuell inspizieren
HMR hat ein Race mit Claudes Screenshot — Nach der Navigation auf networkidle warten, bevor Sie etwas behaupten

Kombinieren mit: filesystem · github

Debuggen Sie, warum ein API-Aufruf von Ihrem Frontend fehlschlägt

👤 Vollstack-Entwickler, die einen 4xx/5xx jagen, der 'lokal nicht passiert' ⏱ ~15 min intermediate

Wann einsetzen: Die Browser-Konsole zeigt einen fehlgeschlagenen Fetch, und Sie vertrauen Ihrer eigenen Erinnerung über die gesendeten Headers/Body nicht.

Ablauf

Lösen Sie den fehlgeschlagenen Aufruf aus

Öffnen Sie die Seite, führen Sie die Aktion aus, die fehlschlägt. Erfassen Sie die URL, Methode, Headers und Body des fehlgeschlagenen Requests.✓ Kopiert

→ Exakte Request-Payload sichtbar — kein Raten
Vergleichen Sie mit dem Erwartet

Das Backend erwartet den Header X-Client-Id und einen JSON-Body mit dem Feld user_id. Was wird tatsächlich gesendet? Machen Sie einen Diff.✓ Kopiert

→ Spezifisches fehlendes oder falsches Feld identifiziert
Reparieren und erneut verifizieren

Reparieren Sie den Quellcode, damit der Request passt. Laden Sie dann die Seite erneut und bestätigen Sie, dass der Aufruf jetzt 200 zurückgibt.✓ Kopiert

→ Finaler Netzwerk-Eintrag zeigt 200, nicht den ursprünglichen Fehler

Ergebnis: Ein reparierter API-Aufruf mit Netzwerk-Tab-Beweis, dass er jetzt funktioniert — nicht mehr 'funktioniert auf meinem Rechner'.

Fallstricke

Session-Cookies oder CORS-Preflight maskieren die echte Anfrage — Schauen Sie sich nicht nur den fehlgeschlagenen Request an — prüfen Sie auch die Preflight OPTIONS und die Set-Cookie-Historie

Kombinieren mit: filesystem · postgres

Erkennen Sie visuelle Regressionsfehler nach einem CSS-Refactor

👤 Frontend-Entwickler, die Design-System-Migrationen durchführen ⏱ ~20 min intermediate

Wann einsetzen: Sie haben CSS/Token refaktoriert. Sie möchten vor dem Merge 'oh nein der Button ist jetzt pink' abfangen.

Ablauf

Snapshot-Schlüsselseiten auf main

Auf http://localhost:3000 (main branch), Screenshot /, /pricing, /dashboard. Speichern Sie in /tmp/visual/main/.✓ Kopiert

→ 3 Screenshots gespeichert
Snapshot-dieselben Seiten auf Ihrem Branch

Wechseln Sie zum Branch 'css-refactor' und starten Sie den Dev-Server neu. Screenshoten Sie dieselben 3 Seiten nach /tmp/visual/branch/.✓ Kopiert

→ 3 Screenshots mit passendem Pfad gespeichert
Diff und Beschreiben

Vergleichen Sie für jedes Paar visuell und beschreiben Sie alle Änderungen. Ignorieren Sie Pixel-Level Anti-Aliasing; flaggen Sie alles, was ein Designer bemerken würde.✓ Kopiert

→ Zusammenfassung der Diffs pro Seite, nicht 'sieht gleich aus'

Ergebnis: Ein review-ready Diff, der unbeabsichtigte visuelle Änderungen abfängt.

Fallstricke

Dynamischer Inhalt (Daten, zufällige Grüße) ändert sich zwischen den Shots — Stub die Zeit und fixieren Sie RNG, oder schneiden Sie diese Regionen heraus

Kombinieren mit: filesystem · github

Kombinationen

Mit anderen MCPs für 10-fache Wirkung

chrome-devtools + filesystem

Bearbeiten Sie die Quelle → laden Sie die Seite neu → verifizieren Sie, in einer engen Schleife

Öffnen Sie localhost:3000/checkout. Der Absende-Button des Formulars hat die falsche Farbe. Finden Sie die relevante CSS in src/ und beheben Sie sie, laden Sie dann neu und screenshoten Sie zur Bestätigung.✓ Kopiert

chrome-devtools + github

Reproduzieren Sie einen Bug aus einem Issue, verifizieren Sie die Lösung, öffnen Sie einen PR mit Screenshot

Issue #482 meldet einen Layout-Bug auf /pricing bei 375px Breite. Reproduzieren Sie ihn mit chrome-devtools (Screenshot bei 375px), beheben Sie das CSS, öffnen Sie einen PR mit den vorher/nachher Screenshots.✓ Kopiert

chrome-devtools + sentry

Reproduzieren Sie einen echten Benutzer-Fehler aus Sentry in Ihrem lokalen Browser

Für Sentry-Issue WEB-3a91 zeigen die Breadcrumbs, dass der Benutzer zu /cart navigierte und dann 'Checkout' klickte. Spielen Sie das in chrome-devtools ab und erfassen Sie, was tatsächlich fehlschlägt.✓ Kopiert

Werkzeuge

Was dieses MCP bereitstellt

Werkzeug	Eingaben	Wann aufrufen	Kosten
navigate_page	url: str, wait_for?: 'load'\|'networkidle'	Starten Sie beliebige Seiteninteraktion	free
take_screenshot	fullPage?: bool, selector?: str	Visuelle Bestätigung nach Navigation oder Interaktion	free
take_snapshot	keine	Strukturierter Seiteninhalt als Text — besser als Screenshots für Claude zum Nachdenken	free
click	selector: str \| uid: str	Klicken Sie auf ein Element nach CSS-Selector oder Snapshot-UID	free
fill	selector: str, value: str	Geben Sie in ein Eingabefeld ein	free
evaluate_script	script: str	Führen Sie beliebiges JS im Seitenkontext aus zur Inspektion	free
list_console_messages	keine	Lesen Sie Konsolenprotokolle und Fehler von der Seite	free
list_network_requests	filter?: str	Inspizieren Sie alle XHR/fetch, die passiert sind	free
get_network_request	requestId: str	Holen Sie sich die vollständigen Headers und Body eines Requests	free
performance_start_trace	reload?: bool, cpu_throttle?: number, network?: 'slow3g'\|'fast3g'	Beginnen Sie eine Performance-Aufzeichnung	free
performance_stop_trace	keine	Beenden und analysieren Sie einen laufenden Performance-Trace	free
emulate_cpu	rate: number	Simulieren Sie langsame Geräte (4x = Mid-Tier Mobile)	free
emulate_network	profile: 'slow3g'\|'fast3g'\|'offline'	Testen Sie unter eingeschränkten Netzwerken	free
new_page / close_page / select_page	verschiedenes	Verwalten Sie mehrere Tabs	free

Kosten & Limits

Was der Betrieb kostet

API-Kontingent: Keine — führt einen lokalen Browser aus
Tokens pro Aufruf: Snapshots und Netzwerk-Dumps können groß sein (5-30k Token); take_snapshot ist normalerweise Token-effizienter als vollständige Screenshots plus DOM-Dump
Kosten in €: Kostenlos
Tipp: Bevorzugen Sie take_snapshot gegenüber take_screenshot für Claude zum Nachdenken über Struktur — Snapshots sind kompakt und textbasiert. Speichern Sie Screenshots für menschliche Bewertung.

Sicherheit

Rechte, Secrets, Reichweite

Credential-Speicherung: Keine auf MCP-Ebene; wenn Sie sich bei einer Site während einer Sitzung anmelden, leben Cookies im Chromium-Profil, bis Sie es schließen

Datenabfluss: Das Chromium browsert das offene Web in Ihrem Namen — Ziele empfangen Ihre IP. Keine Telemetrie an Google über das, was Chromiums Standardwerte senden.

Niemals gewähren: zeigen Sie nie auf Ihr echtes Browser-Profil, das gespeicherte Logins/Passwörter enthält

Wenn Sie Claude bitten, sich bei Site X anzumelden, speichert es ein Session-Cookie im Browser-Profil. Isolieren Sie dieses Profil von Ihrem persönlichen.
Führen Sie niemals evaluate_script Code aus, den Sie nicht verstehen — er läuft in der Herkunft der Seite mit vollem Zugriff.

Fehlerbehebung

Häufige Fehler und Lösungen

Chromium wird nicht gestartet — fehlende Abhängigkeiten unter Linux

Installieren Sie fehlende System-Libs: sudo apt-get install -y libnss3 libatk1.0-0 libatk-bridge2.0-0 libxkbcommon0 libasound2. Das MCP bündelt Chromium, aber nicht alle seine Runtime-Abhängigkeiten.

Prüfen: Führen Sie `npx chrome-devtools-mcp --version` aus — Fehler nennen die fehlende Lib

navigate_page times out auf langsamer Seite

Übergeben Sie wait_for: 'load' anstelle des Standardwerts networkidle; oder erhöhen Sie das Timeout in der MCP-Konfiguration des Clients.

click fehlgeschlagen: Element nicht gefunden

Der Selector ist veraltet oder versteckt. Rufen Sie zuerst take_snapshot auf und verwenden Sie die frische UID aus dem Snapshot.

Performance-Trace ist leer

Sie müssen entweder die Seite während des Traces neu laden (reload: true) oder mit ihr interagieren — ein inaktiver Tab produziert keine Timeline.

Alternativen

Chrome DevTools vs. andere

Alternative	Wann stattdessen	Kompromiss
Playwright MCP	Sie benötigen Cross-Browser-Tests (Firefox, WebKit) oder bevorzugen die API-Oberfläche von Playwright	Ähnliche Kraft; chrome-devtools hat tieferes Perf-Tracing, playwright hat breitere Automatisierung
Puppeteer MCP	Sie möchten die Low-Level Puppeteer-API	Nur Chrome, überlappt stark mit chrome-devtools MCP
browser-tools MCP	Sie möchten sich mit Ihrem vorhandenen Chrome via DevTools Protocol-Erweiterung verbinden	Keine neuen Sandbox — nutzt Ihre echte Browser-Sitzung mit ihrem angemeldeten Status

Mehr

Ressourcen

📖 Offizielle README auf GitHub lesen

🐙 Offene Issues ansehen

🔍 Alle 400+ MCP-Server und Skills durchsuchen