Chrome DevTools MCP server

Chrome DevTools MCP bringt das DevTools-Panel, das du schon kennst, vor einen AI-Agenten. Während es bei den meisten Browser-Servern ums Klicken und Tippen geht, dreht sich hier alles darum, herauszufinden, warum eine Seite langsam ist, was sie loggt, welche Requests sie stellt und was sie im Speicher behält. Es wird von der ChromeDevTools-Organisation auf GitHub veröffentlicht, hat 55.670 Stars und steht unter Apache-2.0-Lizenz.

Wir haben Version 1.13.0 installiert, veröffentlicht am 11. November 2026, und am 14. November 2026 zwei Dinge gemacht: die Tools mit verschiedenen Optionen über MCP Inspector aufgelistet und den Server mit einem kleinen MCP-Client gesteuert, um einen Performance-Trace aufzuzeichnen und Lighthouse auf hostedmcp.org, unserer eigenen Seite, laufen zu lassen. Die Zahlen unten stammen aus diesen Läufen.

Installieren

Du brauchst Node.js 20.19 oder neuer und Chrome. Der Browser startet beim ersten Tool-Aufruf, der ihn benötigt, nicht wenn der Server startet.

Claude Code:

claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --isolated --no-usage-statistics

Cursor, Claude Desktop, Windsurf und andere Clients, die über JSON konfiguriert werden:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["chrome-devtools-mcp@latest", "--isolated", "--no-usage-statistics"]
    }
  }
}

Codex:

codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --isolated --no-usage-statistics

Die beiden Flags sind unsere Empfehlung, keine Defaults. --isolated gibt jeder Session ein temporäres Profil; ohne das Flag behält der Server ein persistentes Profil unter ~/.cache/chrome-devtools-mcp/chrome-profile, das zwischen den Läufen nicht geleert wird. --no-usage-statistics schaltet die Usage-Statistiken ab, die der Server standardmäßig an Google sendet. Unser Config-Builder schreibt denselben Eintrag für mehrere Clients.

Der im README vorgeschlagene erste Prompt ist ein guter Test: "Check the performance of https://developers.chrome.com".

Die Tools, gezählt

tools/list auf 1.13.0 gab ohne Optionen 33 Tools zurück, und die Tool-Definitionen kamen auf 31.498 Bytes. Mit --slim gab es drei zurück: navigate, evaluate und screenshot, in 1.042 Bytes.

Jede Gruppe lässt sich mit einem Flag wie --categoryEmulation=false abschalten. Andere sind aus, bis du sie einschaltest: Netzwerk-Mocking, Extensions, PWA-Automatisierung, virtuelle WebAuthn-Authentifikatoren und Tools, die eine Seite selbst über WebMCP bereitstellt. Schalte nur ein, was eine Aufgabe braucht; 31 KB an Definitionen sind wenig im Vergleich zu manchen Servern, aber sie werden mit jeder Anfrage gesendet.

Was ein Trace zurückgibt

Wir haben den Server headless gestartet, https://hostedmcp.org/ mit new_page geöffnet und dann performance_start_trace mit aktiviertem reload und autoStop aufgerufen, zum Schluss lighthouse_audit.

Der Trace-Aufruf dauerte etwa 6 Sekunden und lieferte 9.436 Bytes Text zurück. Gemeldet wurde:

Danach kamen die gefundenen Insights, jeweils mit Erklärung und, wo zutreffend, einer geschätzten Einsparung: LCP-Aufschlüsselung, render-blockierende Requests (25 ms bei FCP und LCP), der Network Dependency Tree, Image Delivery, Third Parties, Cache Lifetimes und Legacy JavaScript. Der Agent kann für Details performance_analyze_insight auf jedes davon anwenden. Die Antwort endet mit einer Beschreibung des eigenen Call-Tree-Formats, damit das Modell die folgenden Flame-Chart-Daten lesen kann.

lighthouse_audit dauerte etwa 7 Sekunden und lieferte 6.687 Bytes: Accessibility 94, Best Practices 100, SEO 100 und eine vierte Kategorie, Agentic Browsing, mit 67. Vier Audits sind fehlgeschlagen. Das erste war Color Contrast: zwölf Elemente, darunter das Suchlabel in unserem Header, bei einem Verhältnis von 4,33, wo 4,5 nötig sind. Das Tool hat also seinen Job gemacht; wir haben einen Fix zu erledigen.

Zwei Dinge zu diesen Zahlen. Die 0,8 ms Time to First Byte bedeuten, dass die Seite aus einem warmen Edge-Cache kam; ein kalter Request wäre langsamer. Und weil wir --no-performance-crux übergeben haben, meldete der Trace keine Felddaten von echten Nutzern; standardmäßig schlägt der Server die URL der Seite in Googles CrUX-Datensatz nach.

Die pageId-Falle

Unser erster Lauf hat about:blank gemessen. In 1.13.0 nehmen Page-Tools eine pageId, und eine neue Session startet mit einer leeren Seite als Nummer 1. Unser new_page-Aufruf öffnete die Seite als Seite 2 und markierte sie als ausgewählt, aber wir haben 1 übergeben. Der Trace meldete brav einen CLS von 0 für eine leere Seite. Agents rufen normalerweise zuerst list_pages auf und machen das richtig; wenn ein Trace about:blank meldet, liegt es daran.

Eigenes Chrome verwenden

Standardmäßig startet der Server sein eigenes Chrome. Er kann sich aber auch an ein bereits laufendes anhängen:

• --autoConnect verbindet sich mit Chrome 144 oder neuer, nachdem du das Remote-Debugging unter chrome://inspect/#remote-debugging aktiviert hast.
• --browserUrl http://127.0.0.1:9222 verbindet sich mit einem Chrome, das mit --remote-debugging-port=9222 gestartet wurde.

Wenn du dich an deinen Alltagsbrowser anhängst, bekommt der Agent deine Logins, Cookies und offenen Tabs. Genau das willst du, wenn er eine Seite hinter einem Login debuggen soll, und genau das ist das Risiko in jedem anderen Fall. Nutze dafür ein separates Chrome-Profil.

Datenschutz und Sicherheit

Der Server gibt beim Start eine Warnung aus: Er „exposes content of the browser instance to the MCP clients allowing them to inspect, debug, and modify any data in the browser or DevTools“. Nimm das wörtlich. Drei Defaults solltest du ändern:

• Nutzungsstatistiken gehen an Google, außer du übergibst --no-usage-statistics. Sie sind auch aus, wenn die Umgebungsvariable CI gesetzt ist.
• CrUX-Lookups: Performance-Tools können die URLs, die du tracest, an Googles CrUX API senden. Nutze --no-performance-crux für interne oder Staging-URLs.
• Profil: Das Default-Profil bleibt bestehen. Nutze --isolated, außer du brauchst State zwischen Sessions.

evaluate_script führt JavaScript in der Seite aus, und Seiten können Text enthalten, der auf das Modell abzielt. Navigation zu unbekannten Sites gibst du selbst frei. Uns ist außerdem aufgefallen, dass 1.13.0 Datei-Lese- und -Schreibvorgänge, etwa gespeicherte Traces und Screenshots, auf den System-Temp-Ordner beschränkt, wenn der Client seine Workspace-Roots nicht teilt; --allow-unrestricted-paths hebt das auf. Lass es aktiviert. Mehr in MCP security.

Chrome DevTools MCP oder Playwright MCP

Keines der beiden Projekte hat einen Vergleich veröffentlicht, diese Aufteilung stammt also von uns: Playwright MCP, wenn der Agent die Website nutzen soll, Chrome DevTools MCP, wenn es darum geht zu verstehen, warum sich die Website so verhält, wie sie es tut. Beide funktionieren parallel; unseren Playwright MCP Guide behandelt die andere Hälfte.

Wenn es nicht funktioniert

Die Chrome DevTools-Server in unserem Katalog, mit Check-Scores, sind oben auf dieser Seite aufgelistet.