Chrome DevTools Protocol + Claude Code: Das Muster, an dem Open Source Teams jahrelang gearbeitet haben

Ich gebe es zu: Neugier ist bei mir Fluch und Segen zugleich.

Jede App, die du täglich nutzt, kann mehr als das, was sie dir zeigt. Oft verstecken sich Beta-Features hinter einem Flag, undokumentierte Endpoints, die laufen und leise antworten.

Ich habe Claude Code auf eine lokale Ghost-Instanz mit Chrome DevTools als MCP-Server angesetzt. An einem Nachmittag fand der Agent 27 Endpoints, die in der offiziellen Dokumentation nirgends erwähnt werden. Detaillierte Member-Statistiken, ein vollständiges Audit-Log, ein Datenbank-Export mit einem einzigen Call. All das war da. Von Anfang an.

Hier geht es um Ghost, aber entscheidend ist: Die Methode funktioniert bei jeder App (auch bei kommerziellen...). Und was früher die Obsessiven hinter yt-dlp wochenlang beschäftigt hat, schafft heute ein Solo-Dev mit einem Agent zwischen Kaffee und Mittagspause.

Disclaimer: Experimente an Open-Source-Software, die ich lokal betreibe. Proprietäre Tools? Erst die AGB checken. Ich teile eine Methode, keine Rechtsberatung.

Die Dokumentation ist die Kinderkarte

Du gehst ins Restaurant und bekommst die Kinderkarte. Sechs Gerichte, große Schrift, Bilder von glücklichen Hühnchen. Währenddessen führt die Küche eine komplette 40-Gerichte-Karte mit Sachen, die du tatsächlich bestellen wollen würdest. Niemand versteckt das vor dir. Sie dachten nur, du würdest nicht fragen.

So ist das mit App-Dokumentation. Eine kuratierte Auswahl, kein technisches Inventar.

Drei Kräfte sorgen dafür. Features, die noch nicht "bereit" für die Öffentlichkeit sind, aber intern bereits funktionieren (das Admin-UI nutzt sie, du kannst nur nicht). Funktionen hinter Premium-Tarifen, die technisch jedem antworten, der den richtigen Endpoint trifft. Und Zeug, das das Team für eigene Operationen gebaut und nie dokumentiert hat, weil es nicht für dich gedacht war.

Fairerweise gibt es einen soliden Grund dafür. Jeder Endpoint in den Docs wird zu einem impliziten Stabilitätsvertrag. Brich ihn, und tausend Entwickler öffnen ein GitHub-Issue, bevor du deinen Morgenkaffee ausgetrunken hast. Also dokumentieren Teams das absolute Minimum und machen weiter. Das ist nicht böswillig. Es ist nur teuer, es anders zu machen.

Die Docs zeigen dir, was sie wollen, dass du nutzt. Nicht, was die App kann.

Die Obsessiven vor uns

Bevor Agents ins Spiel kamen, war Reverse Engineering interner APIs bereits eine Sache. Eine großartige, schmerzhafte, zeitaufwändige Sache.

Nimm yt-dlp. Hunderte Contributors pflegen eine Software, deren einziger Zweck es ist, YouTubes interne API zu verstehen. Jedes Mal, wenn Google etwas ändert (was ständig passiert, manchmal scheinbar aus Trotz), muss jemand den neuen Flow herausfinden, patchen, shippen. Es funktioniert. Aber es ist auch ein Vollzeitprojekt für eine kleine Armee von Freiwilligen.

Dann war da Nitter. Ein wunderschönes alternatives Twitter-Frontend, komplett auf reverse-engineerten Endpoints aufgebaut. Funktionierte großartig, bis Elon die APIs dichtmachte und es vorbei war. Jahre der Arbeit, weg durch eine Policy-Änderung. Merk dir das, es kommt später zurück.

Diese Projekte bewiesen etwas Wichtiges: Die undokumentierten Fähigkeiten sind real, nützlich, und Leute bauen bemerkenswerte Dinge darauf auf. Aber der Preis war absurd. Wochenlange manuelle Traffic-Inspektion. Tiefe Protokoll-Expertise. Ständige Wartung gegen sich bewegende Ziele. Es war ein Sport für Obsessive (ich erinnere mich ans Debuggen von Spielen in ASM auf dem Amstrad CPC, also verstehe ich den Reiz, aber trotzdem).

yt-dlp hat hunderte Contributors für ein einziges Reverse-Engineering-Projekt. Ich brauchte null.

Ein AI-Agent kollabierte gerade Wochen zu Minuten

Der fundamentale Wandel geht nicht um bessere Tools. Es geht darum, wer die Explorationsarbeit macht.

Hier das technische Setup. Chrome DevTools Protocol (CDP) exponiert alles, was der Browser weiß: DOM-Tree, Network-Requests, Console-Output, Performance-Metriken. Normalerweise interagierst du damit über die DevTools-GUI oder via Puppeteer-Style-Automation. Ein MCP-Server verpackt CDP in ein Protokoll, das AI-Agents nativ sprechen. Der Agent bekommt drei Fähigkeiten, die hier wichtig sind: javascript_tool (beliebiges JS im Page-Context ausführen, inklusive fetch()-Calls mit den aktiven Session-Cookies), computer (warten, klicken, navigieren), und Zugang zum kompletten Network-Waterfall.

Diese Kombination ändert das Spiel. Der Agent liest nicht nur über APIs. Er macht Live-Calls innerhalb einer authentifizierten Session, inspiziert die Responses und iteriert. All die Dinge, die du manuell mit offenem Network-Tab machen würdest, nur dass der Agent es systematisch macht und sich nach Endpoint Nummer sieben nicht langweilt.

Dass Google Chrome DevTools als offiziellen MCP-Server im März 2026 shipped, macht das nicht zu einem Hack, sondern zu einem unterstützten Workflow. Das Unternehmen, das den Browser baut, entschied, dass AI-Agents Live-Zugang zu DOM, Network-Tab und Console zu geben, es wert ist, zu maintainen. Das ist ein Industrie-Signal, kein Community-Experiment.

Vorher waren Agents im Wesentlichen blind für Runtime-Verhalten. Sie konnten Dokumentation lesen, Code generieren, bekannte APIs callen. Aber sie konnten nicht beobachten, was eine Anwendung tatsächlich auf der Leitung macht. Jetzt können sie. Der Agent liest den Traffic, nicht die Docs. Bei Open Source ist das dein fundamentales Recht. Bei proprietärer Software variiert deine AGB-Laufleistung, weshalb der Disclaimer da oben existiert.

Google machte das Pattern gerade offiziell. Agents lesen jetzt Network-Traffic, nicht Dokumentation.

Ghost, 27 Endpoints, ein Nachmittag

Das Setup: Ghost v6.22.0 lokal laufend, Claude Code mit Chrome DevTools MCP verbunden zum Admin-Panel unter localhost:2368/ghost/.

Der erste Prompt war nicht "geh erkunden" (das wäre Vibe-Coding). Er war strukturiert: alle Admin-Panel-Requests abfangen, einzigartige Endpoints nach Pfad und HTTP-Methode katalogisieren, Response-Shapes aufzeichnen, dann systematisch benachbarte URL-Pattern proben. Der Agent nutzte javascript_tool, um fetch()-Calls direkt im Admin-Page-Context zu injizieren, was bedeutete, er erbte die aktiven Session-Cookies und Admin-Level-Permissions. Kein separater Authentifizierungs-Tanz nötig.

Phase 1: passive Abfangung. Während ich durch das Ghost-Admin navigierte (Dashboard, Posts, Members, Settings), zeichnete der Agent jeden API-Call auf, den das Frontend machte. Dreizehn Live-Endpoints tauchten sofort auf. Das sind die, die das Admin-UI tatsächlich nutzt, aber die die offiziellen API-Docs nicht erwähnen.

Phase 2: aktives Probing. Hier wird es interessant. Der Agent nahm die URL-Pattern, die er bereits gesehen hatte (/ghost/api/admin/stats/..., /ghost/api/admin/actions/...) und begann, Variationen zu proben. Er probierte benachbarte Routen, verschiedene Query-Parameter, die Plural- und Singularformen dessen, was er bereits kannte. Er fetchte parallel die offiziellen Ghost Admin API Docs und die Content API Docs, dann berechnete er das Delta zwischen dem, was dokumentiert ist und was tatsächlich mit einer 200 antwortet. Am Ende: 27 Endpoints insgesamt, alle geben gültige Daten zurück.

Phase 3: Wrapper-Konstruktion. Der Agent generierte einen 830-Zeilen TypeScript-Wrapper (ghost-enhanced-api.ts) mit zwei Clients. Ein GhostOfficialClient, der die dokumentierte Admin API wrappt (deine Baseline), und ein GhostEnhancedClient, der jeden undokumentierten gefundenen Endpoint hinzufügt. Strikte TypeScript-Interfaces für jede Response-Shape, denn wenn du mit Endpoints arbeitest, die keine Dokumentation haben, sind Types deine Dokumentation.

Authentifizierung war auch interessant. Ghosts Admin API nutzt JWT signiert mit HMAC-SHA256, abgeleitet von einem hex-kodierten API-Key, geteilt an Position 24 (die erste Hälfte ist die Key-ID, die zweite das Secret). Der Agent fand das heraus, indem er die Auth-Header des Admin-Panels beobachtete und implementierte es mit crypto.subtle im Wrapper. Keine Dokumentation für diesen Teil konsultiert.

Was der Agent fand, in konkreten Begriffen:

Stats-Endpoints (8 insgesamt) — stats/member_count/, stats/mrr/, stats/subscriptions/, stats/referrers/ mit Conversion-Tracking, stats/top-posts-views/. Ghost betreibt ein komplettes Analytics-Backend, das die offiziellen Docs so tun, als existiere es nicht. MRR aufgeschlüsselt nach Währung, Referrer-Attribution mit Conversion-Raten, tägliches Member-Wachstum. Das ist die Art von Daten, für die du normalerweise ein Drittanbieter-Analytics-Tool bräuchtest.

Audit-Log — actions/-Endpoint. Komplettes Journal jeder Admin-Operation: wer welche Einstellung geändert hat, wer welchen Post veröffentlicht hat, wann. Vollständige action_type, resource_type, actor-Felder. Die Art von Feature, die normalerweise "Enterprise-Tier, kontaktiere den Vertrieb" ist.

Email-System — drei separate Endpoint-Gruppen: emails/ (Delivery-Stats pro Email), links/ (Click-Tracking), automated_emails/ (Newsletter-Automation-Metriken). Unabhängig von Post-Endpoints, bedeutet du kannst Email-Performance abfragen, ohne durch die Posts-API zu gehen.

Datenbank-Export — GET /ghost/api/admin/db/ gibt ein vollständiges JSON-Backup zurück. Ein Call. (Und sein Spiegelbild, POST /ghost/api/admin/db/, macht einen destruktiven Import. Der gehört aus offensichtlichen Gründen in die "nicht anfassen"-Kategorie.)

Auch entdeckt: mentions/ (Webmentions/ActivityPub), recommendations/ und incoming_recommendations/ (die Recommendation-Engine), snippets/, labels/, roles/, und vollständige Server-Config.

Die Test-Suite (40 Tests) bestand 39/40 beim ersten Lauf. Der eine Fehler war ein Response-Key-Mismatch: incoming_recommendations/ gibt seine Daten unter einem recommendations-Key zurück, nicht incoming_recommendations. Genau die Art von Inkonsistenz, die nur auftaucht, wenn du tatsächlich den Endpoint triffst und schaust, was zurückkommt. Fix war eine Zeile. 40/40.

Ich habe bereits gesehen, wie Claude Code ein komplettes Open-Source-Tool absorbiert und kompetenter wird als dessen eigene Dokumentation. Gleiche Energie hier, angewandt auf API-Oberflächen, die niemand kartiert hatte.

Klassifizierung: 22 Endpoints sicher (read-only), 9 mit-Vorsicht-verwenden (Write-Operationen), 1 nicht-anfassen (POST /db/, der destruktive Import). Und der nicht-verhandelbare Teil: undokumentierte Endpoints haben null Stabilitätsvertrag. Sie ändern sich zwischen Versionen ohne Changelog-Eintrag. Ein Health-Check auf jedem Endpoint ist das erste, was du baust, vor allem anderen.

Gesamte Agent-Zeit: unter 17 Minuten. Der Rest des Nachmittags war ich beim Lesen des Reports und Entscheiden, was darauf aufzubauen.

27 Endpoints. Null Dokumentation. Ein Nachmittag. Reproduzierbar bei jedem Tool, das du betreibst.

Was das freischaltet (und warum es jetzt wichtig ist)

Custom MCP-Server für jedes Tool. Du entdeckst die Endpoints, verpackst sie in typisierte Clients, exponierst sie an deine Agents via MCP (oder eine CLI, deine Wahl). Dein Agent kann jetzt innerhalb von Apps operieren, die null offizielle Agent-Unterstützung haben. Das MCP-Ökosystem hat bereits tausende Community-Server, aber die meisten bauen nur auf dokumentierten Endpoints auf. Das geht eine Schicht tiefer.

Agent-Pipelines, die nicht auf den Vendor warten. Brauchst du, dass Ghost jeden Morgen Member-Stats in dein Monitoring-Dashboard pushed? Die offizielle API unterstützt das nicht. Die undokumentierten stats/-Endpoints schon. Du schreibst einen Cron-Job, der getStatsReferrers() callt und die Daten dorthin piped, wo du sie willst. Du bist nicht mehr blockiert von dem, was jemand anders dieses Quartal zu priorisieren entschied.

Custom-Extensions, die das UI nie erdacht hat. Kombiniere das Audit-Log mit den Email-Tracking-Endpoints, um ein internes Compliance-Dashboard zu bauen, das Ghost wahrscheinlich nie shippen wird. Brücke zwei Tools über ihre internen Endpoints, um einen Workflow zu automatisieren, der sonst drei Browser-Tabs und manuelles Copy-Paste erfordern würde. Die Art von Sache, die früher "Enterprise-Tier, bitte kontaktiere den Vertrieb" erforderte.

Jetzt ist die Wahl zwischen CLI und MCP für die Verbindung von Agents zu Tools eine aktive Debatte mit echten Performance-Tradeoffs. Beides funktioniert. Der Punkt ist, du brauchst erst etwas zum Exponieren. Discovery kommt vor Packaging.

Die Vendor-Roadmap ist jemand anders' Prioritätenliste. Dein Agent muss nicht darauf stehen.

Die Spielregeln

Open Source zuerst. Immer. Bei Open-Source-Software liest du Code, der öffentlich verfügbar ist, da gibt es keine Grauzone, Punkt. Bei proprietären Tools wird die Situation schnell trüber, und die AGB könnten sehr starke Meinungen über automatisierten Zugang haben. Fang mit Open Source an, gewöhn dich an die Methode, dann triff informierte Entscheidungen darüber, wo du sie sonst hinträgst.

Health-Checks sind nicht optional, und ich meine strukturell nicht optional. Undokumentierte Endpoints haben keine Stabilitätsgarantie. Version 5.92 könnte einen Endpoint exponieren, den 5.93 ohne auch nur einen Changelog-Eintrag entfernt. Dein Wrapper muss Brüche erkennen, bevor er etwas korrumpiert. Jeder Endpoint bekommt einen Health-Check. Jeder Wrapper bekommt eine Test-Suite. Das ist der langweilige Teil, und auch der Teil, ohne den nichts hält.

Und die eine Regel, die ich mir irgendwo sichtbar tätowieren würde: niemals ein SaaS auf internen Endpoints aufbauen. Persönliche Nutzung, interne Tools, Automationen für deinen eigenen Stack, mach wild. Aber in dem Moment, wo du ein Produkt verkaufst, das von einem undokumentierten Endpoint abhängt, baust du auf Sand. Nitter lernte das auf die harte Tour 🫠. Eine Upstream-Policy-Änderung und das Projekt war tot. Behalte die Exploration für dich.

Der Ansatz selbst verlangt auch Struktur. Einen Agent ohne klare Constraints auf einen Network-Tab zu richten funktioniert technisch, produziert aber Müll im großen Maßstab. Das Erkunden interner APIs mit einem Agent verlangt die gleiche Strenge wie jede Produktionsarbeit. Prompt-Contracts, explizite Grenzen, definierte Output-Formate. Kein Vibe-Coding.

Erkunde alles. Baue, was du brauchst. Aber verkaufe niemals ein Produkt auf einem Endpoint ohne Vertrag.

---

Jahrelang nutzten wir unsere Tools wie brave Schüler. Die Docs sagten "du kannst das machen", und wir sagten OK. Punkt.

Diese stille Vereinbarung ist gerade gebrochen. Ein Agent + DevTools erkundet die echten Fähigkeiten jeder Anwendung in 30 Minuten. Das Reverse Engineering, das yt-dlp hunderte Contributors und Jahre der Wartung kostete, wurde zu einem One-Shot für jeden Solo-Dev an einem zufälligen Dienstagnachmittag.

Die offizielle Dokumentation ist die Broschüre. Der Quellcode ist der Vertrag. Und jetzt hast du einen Agent, der beides liest ;-)

---

Quellen & Links:

Google Chrome DevTools MCP — offizieller Release, März 2026

Wenn du ein Dev bist, der echte Sachen mit AI-Agents shipped, darüber schreibe ich. Abonniere und du bekommst die Methoden, bevor sie zu Medium-Trends werden.

(*) Das Cover ist AI-generiert. Die 27 Endpoints sind jedoch sehr real und leicht beleidigt, dass sie nie dokumentiert wurden.