Der blinde Fleck: Chrome DevTools MCP Server

Ein Agent schreibt eine Zeile CSS, die ein Layoutproblem beheben soll. Der Linter schweigt, der Commit geht durch, die Tests sind grün. Im Browser rutscht das Element trotzdem eine Reihe zu weit nach rechts, weil ein Elternelement irgendwo im Baum position:relative; gesetzt hat, wovon im generierten Code selbst nichts zu sehen war. Der Agent hat richtig geschrieben und trotzdem falsch gehandelt. Dazwischen lag kein Fehler, dazwischen lag eine Wand.

Diese Wand beschreibt Google in der Ankündigung des Chrome DevTools MCP Servers ungewöhnlich unverblümt für einen Konzernblog: KI-Coding-Assistenten seien faktisch „mit verbundenen Augen am Werk" (1). Seit September 2025, als der Server in die öffentliche Vorschau ging, lässt sich dieser Zustand beheben, zumindest teilweise. Der Mensch, der bisher als Sinnesorgan seines Agenten arbeitete, Konsole las, Netzwerk-Panels beschrieb und Screenshots in Worte fasste, kann diese Rolle abgeben. Die alte Arbeitsteilung, die Maschine denkt und der Mensch guckt, war ohnedies die falsche.

Ein Sprachmodell kann syntaktisch einwandfreien Code produzieren, ohne je zu erfahren, was dieser Code tut, sobald ihn ein Browser interpretiert. Das ist keine Schwäche eines bestimmten Modells. Es ist eine strukturelle Eigenschaft von Textgeneratoren, die die Welt nur aus der Beschreibung kennen, nie aus der Beobachtung.

Genau hier setzt das Model Context Protocol an, über das wir im Artikel zur Agententopologie ausführlich geschrieben haben: der offene Standard, der einem Agenten Werkzeuge in die Hand gibt, statt ihm nur mehr Text vorzulesen. Der Chrome DevTools MCP Server ist ein solches Werkzeug, ein offizielles Google-Projekt, verteilt als npm-Paket, und technisch eine Brücke zum Chrome DevTools Protocol, derselben Schnittstelle, die auch die eingebauten Entwicklertools und Automatisierungswerkzeuge wie Playwright ansteuern (2). Für die Ausführung nutzt der Server Puppeteer, was einen unscheinbaren, aber praktisch bedeutsamen Vorteil hat: Die Bibliothek wartet auf Seitenladevorgänge und DOM-Bereitschaft, bevor sie handelt. Der Agent klickt nicht ins Leere, wie es naive Automatisierungsskripte gern tun. Nach der Installation genügt in Claude Code der Befehl /mcp, um zu prüfen, ob die Verbindung steht.

Für eine Agentur, die täglich zwischen einem Dutzend Kundenprojekten wechselt, ist das mehr als ein Komfortgewinn. Jeder Layoutfehler, der sich automatisiert verifizieren lässt, ist ein Telefonat weniger mit einem verunsicherten Kunden. Ein Modell, das nur programmiert, bleibt blind für die eine Instanz, in der sein Code tatsächlich lebt: den Browser eines Menschen.

Der naheliegendste Weg, einem Agenten Zugang zum Browser zu geben, wäre, ihm Bildschirmfotos vorzulegen und ihn Pixel für Pixel lesen zu lassen. Genau das ist hier nicht die primäre Methode. Der Server liefert stattdessen strukturierte Daten: den Accessibility Tree einer Seite als Text, die Liste aller Netzwerk-Requests mit Status und Timing, die Konsolenausgabe samt quellcode-referenzierter Stacktraces. Ein einziger Aufruf von list_console_messages beantwortet, wofür ein Mensch früher zwischen drei Tabs wechseln musste.

Der Unterschied zwischen einem Agenten, der eine Webseite sieht, und einem, der sie versteht, liegt in der Datenstruktur, die ihm zur Verfügung steht. Ein Bild zeigt, dass ein Button rot ist. Ein Accessibility Tree sagt, dass er aria-disabled ist, obschon er leuchtet, als wäre er anklickbar. Erst diese zweite Information lässt sich in einen Fix übersetzen. Ein Bild zeigt, was auf einer Seite ist. Ein Accessibility Tree zeigt, was eine Seite bedeutet.

Praktisch sieht das so aus: Ein Prompt wie „Prüfe die Performance von urbanstudio.de mit dem Chrome DevTools MCP Server" genügt, damit der Agent eine Chrome-Instanz startet, zur URL navigiert, einen Performance-Trace aufzeichnet und daraus Kennzahlen wie den Largest Contentful Paint extrahiert, samt konkreter Optimierungsvorschläge. Die Frage, warum eine Seite langsam lädt, beantwortete ein Sprachmodell bisher aus Erfahrungswissen, also mit den üblichen Verdächtigen von Bildgrößen bis Renderblocking. Jetzt benennt es die tatsächliche Ursache, etwa eine konkrete LCP-Ressource, die zu spät angefordert wird. Der Unterschied ist der zwischen einer Vermutung und einem Befund.

Noch wichtiger als der einzelne Befund ist der Arbeitszyklus. Bisher endete die Verantwortung des Agenten mit dem Schreiben des Codes; ob die Änderung wirkte, musste der Mensch prüfen und zurückmelden. Mit Browserzugriff verifiziert der Agent seine eigene Arbeit: Fix schreiben, Seite laden, Konsole prüfen, gegebenenfalls nachbessern. Aus einem offenen Ende wird eine Schleife, und die Schleife ist der eigentliche Qualitätssprung, denn sie verlagert die Fehlerkorrektur dorthin, wo sie am billigsten ist: vor die Rückmeldung an den Menschen. Das Werkzeugarsenal dafür wächst im Wochentakt; rund dreißig Tools umfasst der Server inzwischen, von der Performance-Analyse über Formularinteraktion bis zur Emulation mobiler Endgeräte, dazu ein schlanker --slim-Modus für alle, die nur schnell einen Screenshot oder eine einzelne Interaktion brauchen.

Im Dezember 2025 hat Google die vielleicht folgenreichste Erweiterung nachgelegt: Seit Chrome M144 kann sich der Server per autoConnect-Option in eine bereits laufende Browsersitzung einklinken, nach expliziter Freigabe durch einen Berechtigungsdialog (3). Das klingt nach einem Detail, verändert aber den Charakter der Zusammenarbeit. Der Agent kann Probleme untersuchen, die hinter einem Login liegen, ohne sich selbst anmelden zu müssen. Und er kann dort weitermachen, wo der Mensch aufgehört hat: Wer im Netzwerk-Panel einen fehlschlagenden Request entdeckt, markiert ihn und übergibt die Untersuchung an den Agenten. Manuelles und maschinelles Debugging werden Stationen desselben Vorgangs.

Wer einem Agenten erlaubt, den eigenen Browser zu inspizieren, öffnet mehr als nur die Website, an der gerade gearbeitet wird. Cookies, angemeldete Sitzungen, offene Tabs mit privater Korrespondenz: All das liegt im selben Sichtfeld. Die Entwickler wissen das und sagen es im Repository unverstellt: Wer sensible Daten nicht mit MCP-Clients teilen wolle, solle sie dem Browser, den der Agent sieht, erst gar nicht preisgeben. Google hat das Berechtigungsmodell erkennbar ernst genommen, jede Verbindung zu einer laufenden Sitzung muss bestätigt werden, aber die Verantwortung für den Umgang mit produktiven Accounts bleibt beim Menschen. Erwähnenswert ist auch, dass der Server standardmäßig Nutzungsstatistiken an Google sendet; wer das nicht möchte, schaltet es per Flag ab.

Und ein Agent mit Augen ist noch kein Agent mit Urteilsvermögen. Er erkennt, dass ein Kontrast rechnerisch ausreicht, aber nicht, ob eine Seite verständlich ist. Er misst, dass der LCP unter zweieinhalb Sekunden liegt, aber nicht, ob die Seite ihren Zweck erfüllt. Die Werkzeuge liefern Befunde, keine Bewertungen. Das ist keine Schwäche des Servers. Es ist die alte Grenze zwischen Messung und Urteil, die auch dieses Werkzeug nicht verschiebt. Sichtbarkeit ist keine Funktion, die sich zuschalten lässt. Sie ist eine Entscheidung, die jemand treffen muss, bevor der Agent den ersten Blick auf den Bildschirm wirft.

Für unsere eigene Arbeit ist diese Entwicklung weniger überraschend, als sie klingt. Mit urbanaudits testen wir Barrierefreiheit seit Längerem mit Playwright in echten Browsern, aus derselben Überzeugung heraus: Was im Browser passiert, lässt sich nur im Browser prüfen, nicht im Quelltext erraten. Der Chrome DevTools MCP Server generalisiert dieses Prinzip und verlagert es an eine neue Stelle, direkt in den Arbeitszyklus des Coding-Agenten. Aus einem Skript, das gepflegt werden muss, wird ein Gespräch, das geführt wird. Die Prüfung ist damit kein nachgelagerter Schritt mehr, den man ansetzen oder vergessen kann; sie wird Bestandteil der Erzeugung selbst.

Man kann darin ein Muster erkennen, das über dieses eine Werkzeug hinausweist. Die erste Generation der Coding-Agenten hat beeindruckt, weil sie schreiben konnte. Die nächste wird sich daran messen lassen, ob sie prüfen kann, was sie geschrieben hat. Werkzeuge wie dieses verschieben die Grenze zwischen beidem, und sie tun es an der richtigen Stelle: nicht beim Versprechen, sondern beim Beleg.

Sehen ist billig geworden. Hinsehen bleibt eine Entscheidung.