chrome-debug-mcp

chrome-debug-mcp ist ein asynchroner, auf Rust basierender Model Context Protocol (MCP)-Server, der es KI-Agenten und Large Language Models ermöglicht, Chromium-basierte Browser nativ über das Chrome DevTools Protocol (CDP) zu steuern, zu automatisieren und zu debuggen.

Unter der Haube verwendet dieser MCP-Server cdp-browser-lite (das selbst den cdp-lite-Client re-exportiert) und integriert sich direkt in den Browser, wodurch schwere Abstraktionen vermieden werden und Live-Debugging-Sitzungen direkt aus Ihrem Editor oder Ihrer Chat-Oberfläche ermöglicht werden. Ab v0.2.0 kann er auch den Lebenszyklus des Chrome-Prozesses automatisch verwalten.

✨ Funktionen

Dieser Server implementiert nativ eine Reihe von Tools, die nach CDP-Domänen und nativer Prozessverwaltung kategorisiert sind:

🛡️ Datenschutz & Sicherheit

• Isolierte Profile (Standard): Jedes Mal, wenn der MCP-Server Chrome startet, erstellt er ein frisches, temporäres Benutzerprofil im temporären Verzeichnis Ihres Systems. Dieses Profil ist vollständig unabhängig von Ihrem Hauptbrowserprofil und wird entfernt, wenn der Browser gestoppt wird — Cookies, Verlauf, gespeicherte Passwörter oder Sitzungsdaten aus einer Sitzung gehen niemals in die nächste über.

• Inkognito-ähnliche Erfahrung: Standardmäßig werden keine Cookies, kein Verlauf, keine gespeicherten Passwörter oder Sitzungsdaten von Ihren persönlichen Konten mit der verwalteten Instanz geteilt.

• Identitätsschutz: Selbst wenn ein LLM die volle Kontrolle über den Browser hat, kann es nicht auf Ihre angemeldeten Sitzungen (z. B. Google, GitHub, Banking) zugreifen oder sich als Sie ausgeben, sofern dies nicht ausdrücklich autorisiert wurde.

• Benutzerprofil-Modus: Verwenden Sie das Flag --user-profile, um Chrome mit Ihrem bestehenden Systemprofil zu starten. Dies ist nützlich, wenn Sie möchten, dass das LLM innerhalb Ihrer aktiven Sitzungen (Cookies, gespeicherte Anmeldungen usw.) arbeitet, ohne sich auf jeder Website erneut authentifizieren zu müssen. Mit Vorsicht verwenden, da dies dem LLM Zugriff auf Ihre persönlichen Browserdaten gewährt.

  • ⚠️ Hinweis zu --user-profile: Aufgrund der Singleton-Architektur von Chrome wird die Anfrage delegiert und der Debug-Port kann nicht geöffnet werden, wenn Ihr Browser bereits geöffnet ist. Sie müssen entweder alle vorhandenen Chrome-Instanzen schließen, bevor Sie den MCP starten, oder Ihren Browser manuell mit dem Flag --remote-debugging-port=9222 starten.

🚀 Chrome-Instanz- und Tab-Verwaltung

• Multi-Instanz-Unterstützung: Startet und steuert mehrere gleichzeitige, unabhängige Chrome-Prozesse auf dynamischen Ports, jeweils mit eigenem isolierten Profilverzeichnis. Begrenzen Sie die Anzahl der Instanzen mit dem Flag --max-instances.

• Instanz-Registry-Tools: Verwenden Sie open_instance, list_instances und close_instance, um zusätzliche Instanzen zu erstellen, zu überprüfen und zu bereinigen. Alle vorhandenen Tools akzeptieren eine optionale instance_id, um Befehle an den Zielbrowser zu leiten.

• Multi-Tab-Unterstützung (Neu): Steuert mehrere gleichzeitige Tabs innerhalb einer einzelnen Chrome-Instanz und multiplexiert die Ereignisströme und Befehle über eine einzige WebSocket-Verbindung.

  • Automatische Erkennung: Von Zielseiten geöffnete Popups (z. B. window.open()) werden automatisch erkannt, angehängt und in der Tab-Registrierung der Sitzung registriert.

  • Cache-Isolation: Zustandscaches (Konsolenmeldungen, Netzwerkverkehr, vom Debugger geparste Skripte, WebMCP-Tools) sind strikt pro Tab isoliert, sodass Ereignisse nicht zwischen Zielen übergreifen.

• Tab-Registry-Tools (Neu):

  • open_tab — Öffnet einen neuen Tab, optional mit einem benutzerdefinierten Label und einer Ziel-URL. Gibt JSON mit der tab_id zurück, um sie in anderen Tools wiederzuverwenden.

  • list_tabs — Listet alle offenen und registrierten Tabs der Instanz als JSON auf (tab_id, label, target_id, url) sowie den aktuell aktiven Tab. Wenn keine Tabs registriert sind, greifen die Tools auf die standardmäßige Einzel-Tab-Verbindung der Instanz zurück.

  • close_tab — Schließt einen bestimmten Tab anhand der ID und bereinigt seinen Cache-Zustand. Gibt den neuen aktiven Tab zurück.

  • switch_tab — Ändert den standardmäßig aktiven Tab, der verwendet wird, wenn tab_id in Tool-Aufrufen weggelassen wird, und bringt ihn optional in den Vordergrund.

• LLM-freundliche Oberfläche: Die Lebenszyklus-Tools (open_instance, close_instance, open_tab, list_tabs, switch_tab, close_tab) geben strukturiertes JSON zurück, sodass Agenten Aufrufe ohne Regex-Parsing von Prosa verketten können, und ihre Beschreibungen folgen der standardmäßigen MCP-Vorlage (Nebenwirkungen, Voraussetzungen, Rückgabewerte, Alternativen), damit Modelle sie korrekt einordnen.

• Ziel-Routing (Neu): Alle Tab-bezogenen Tools akzeptieren einen optionalen tab_id-Parameter, um Befehle zu adressieren und Cache-Zustände von einem bestimmten Tab abzurufen. Wenn er weggelassen wird, wird der standardmäßig aktive Tab adressiert.

• Isolierte Profile: Startet Chrome standardmäßig mit einem frischen, temporären Profil und stellt sicher, dass es keine Cookies, Passwörter oder Sitzungsdaten mit Ihrem Hauptbrowser teilt.

• Benutzerprofil-Unterstützung: Verwenden Sie optional --user-profile, um Ihre vorhandenen Browser-Sitzungen und Cookies zu nutzen.

• Dynamische Portverwaltung: Erkennt automatisch, ob der Standardport (9222) belegt ist.

  • Wenn der Port von einer Chrome-Instanz belegt ist, die CDP bereitstellt (vom Benutzer gestartet oder eine andere verwaltete chrome-debug-mcp-Instanz), verbindet er sich automatisch mit ihr, anstatt eine neue zu starten.

  • Verwaltete Profile sind ephemer, daher gibt es keinen persistenten Zustand pro Port; ein zweiter Server, der sich einen Port teilt, teilt einfach denselben Browser (und beendet niemals eine verbundene Instanz).

• Docker- & Headless-Unterstützung: Volle Kompatibilität mit Docker-Umgebungen. Verwenden Sie das Flag --headless, um Chrome ohne GUI in Containern auszuführen.

• Remote-/Host-Verbindung: Verwenden Sie das Argument --host, um eine Verbindung zu einer Chrome-Instanz herzustellen, die auf einem anderen Rechner oder dem Host-Rechner läuft (z. B. --host host.docker.internal aus einem Container heraus).

• Optionale Automatisierungs-Infoleiste: Fügen Sie das Flag --enable-automation hinzu, um die native Meldung „Chrome wird von automatisierter Testsoftware gesteuert“ explizit anzuzeigen. Standardmäßig ist dies für eine dezentere Interaktion deaktiviert.

• Proxy-Unterstützung: restart_chrome akzeptiert jetzt ein optionales proxy_server-Argument, um Chrome so zu starten, dass der Datenverkehr über einen Proxy geleitet wird.

• Autostart: Erkennt automatisch, ob Chrome auf dem angegebenen Port läuft. Wenn nicht, startet es eine neue Instanz mit den erforderlichen Flags.

• restart_chrome: Startet die verwaltete Chrome-Instanz neu.

• Fähigkeitsvoreinstellungen: restart_chrome akzeptiert ein optionales features-Array, damit ein Client pro Neustart zusätzliche Browserfunktionen aktivieren kann. Es handelt sich um eine geschlossene Menge — beliebige Chrome-Flags werden bewusst nicht akzeptiert, um zu verhindern, dass das Tool zu einem Befehlszeilen-Injektionspunkt wird:

  • WEB_MCP — aktiviert die experimentelle WebMCP-Oberfläche (--enable-features=WebMCPTesting, --categoryExperimentalWebmcp=true), für Websites, die dem Browser Tools bereitstellen.

  • WEBGL_SOFTWARE — erzwingt SwiftShader-Software-WebGL (--use-gl=angle, --use-angle=swiftshader, --enable-unsafe-swiftshader), für Umgebungen ohne GPU wie Container.

  Voreinstellungen gelten für die Instanz, die durch diesen Aufruf gestartet wurde; ein späterer restart_chrome-Aufruf, der features weglässt, setzt sie zurück, analog zum Verhalten von proxy_server.

• stop_chrome: Fährt die verwaltete Chrome-Instanz ordnungsgemäß herunter (SIGTERM/SIGINT mit Fallback auf SIGKILL).

• Robuster Lebenszyklus: Behobene Probleme mit verwaisten Chrome-Prozessen. Ephemere Profile werden beim Stoppen gelöscht, und cdp-browser-lite räumt verwaiste Profilverzeichnisse auf, die durch abrupte Beendigungen zurückbleiben; die Wiederherstellungsblase „Chrome wurde nicht ordnungsgemäß beendet“ wird über Startflags und Profil-Patching unterdrückt.

• ⚠️ Verhaltensänderung: Verwaltete Chrome-Instanzen werden jetzt beendet, wenn der MCP-Serverprozess endet (einschließlich Abstürzen). Zuvor überlebte ein verwaltetes Chrome einen Serverabsturz und wurde beim Neustart wieder verbunden; von nun an wird es beendet. Verbundene (vom Benutzer gestartete) Chrome-Instanzen werden niemals beendet.

🔐 Proxy-Authentifizierung

• enable_proxy_auth: Behandelt automatisch Proxy-Authentifizierungsaufforderungen, indem es in die Fetch-CDP-Domäne eingreift und benutzerbereitgestellte Anmeldedaten (Benutzername & Passwort) bereitstellt.

• Robustheitsverbesserungen: Verfügt jetzt über ein 30-Sekunden-Timeout für langsamere Residential-Proxys und fängt standardmäßig nur Document-Anfragen ab, um Hintergrundanfragen nicht zu beeinträchtigen.

• Vorwärmen: Navigiert automatisch zu einer prewarm_url (Standard: http://api.ipify.org?format=json), um den Proxy-Tunnel zuverlässig aufzubauen, bevor Ihre Hauptnavigation beginnt. Sie können die Abfangung optional auf einen bestimmten resource_type beschränken.

🖱️ Benutzereingabe

• click_element: Simuliert einen nativen Mausklick auf ein bestimmtes Element mithilfe eines CSS-Selektors. Es berechnet die Mittelpunktskoordinaten des Elements und sendet CDP-Mausereignisse direkt.

• fill_input: Füllt ein Eingabefeld im DOM mit dem angegebenen Text. Es fokussiert das Element über einen CSS-Selektor und verwendet dann natives CDP Input.insertText.

• scroll: Scrollt die Seite um Pixel, Viewport-Höhen (Seiten) oder zu einem bestimmten Element. Unverzichtbar für die Interaktion mit lazy-geladenen Inhalten oder unendlichem Scrollen.

📡 Netzwerkinspektion

• get_network_logs: Ruft abgefangene Netzwerkanfragen (REST/HTTP) und WebSocket-Frames ab.

• Erweiterte Filterung: Filtern Sie Protokolle nach URL, Ressourcentyp, WebSocket-Richtung oder Payload-Inhalt.

• Payload-Inspektion: Zugriff auf vollständige Anfrage-/Antwort-Header, REST-Antwortkörper und WebSocket-Frames.

• Kontextoptimiert: Optionaler „Zusammenfassungsmodus“, um das Überfluten des LLM-Kontextfensters zu vermeiden.

🪵 Konsole & Fehler

• get_console_logs: Ruft Konsolenprotokolle aus dem Browser ab. Dies umfasst console.log/warn/error-Aufrufe, Ausnahmen und Netzwerkfehler. Entscheidend für die Fehlersuche bei Seiten-Skripten und Fehlern. Enthält optionale Filterung nach Protokollebene und ein clear-Flag zur effizienten Zustandsverwaltung.

⚡ Leistung & Profiling

• get_performance_metrics: Ruft Laufzeit-Leistungsmetriken aus dem Browser ab (z. B. JS-Heap-Größe, DOM-Knoten, Layout-Dauer). Nützlich für eine schnelle Momentaufnahme des Speicher- und Rechenaufwands der Seite.

• profile_page_performance: Zeichnet eine Leistungsablaufverfolgung der Seite auf und analysiert sie. Es berechnet automatisch die Core Web Vitals (FCP, LCP, DCL, Load) und identifiziert die wichtigsten Long Tasks (Hauptthread-blockierende Vorgänge). Sie können die Seite optional mit deaktiviertem Cache neu laden, um einen Kaltstart zu simulieren.

🌐 Seiten- & Laufzeitsteuerung

• capture_screenshot: Macht einen Screenshot der aktuellen Seite (oder des vollständigen Seitenlayouts) und gibt ihn als base64-codierten Bildblock an den LLM-Client zurück.

• navigate: Navigiert den aktiven Tab zu einer bestimmten URL.

• reload: Lädt die aktuelle Seite neu.

• inspect_dom: Ruft das gesamte HTML oder einen intelligenten Ausschnitt um eine Suchanfrage ab.

  • Kontextsuche: Suchen Sie nach bestimmtem Text und erhalten Sie eine konfigurierbare Anzahl von Zeichen darum herum.

  • Token-Effizienz: Reduzieren Sie die Nutzung des Kontextfensters bei großen Seiten drastisch.

• evaluate_js: Führt einen beliebigen JavaScript-Ausdruck global im Seitenkontext aus.

🐞 Live-Debugging & Ausführungssteuerung

• pause_on_load: Aktiviert den Debugger und löst ein Neuladen der Seite aus, wobei die Ausführung bei der allerersten geparsten Skriptanweisung angehalten wird.

• search_scripts: Durchsucht alle geparsten Skriptkontexte nach einer Abfrage, um Zeilen und Spalten für Haltepunkte genau zu finden.

• set_breakpoint: Setzt einen präzisen JS-Haltepunkt mithilfe von script_id, url oder exaktem script_hash.

• evaluate_on_call_frame: Wertet einen JavaScript-Ausdruck direkt im lokalen Gültigkeitsbereich des aktuell angehaltenen Debugger-Call-Frames aus.

• step_over: Führt die nächste Ausdruckszeile aus, ohne in Funktionsaufrufe zu springen.

• resume: Hebt die Pause auf und setzt die Ausführung fort.

• remove_breakpoint: Entfernt einen zuvor gesetzten Haltepunkt.

🧩 WebMCP (von der Seite bereitgestellte Tools) Erfordert einen Neustart von Chrome mit dem WEB_MCP-Capability-Preset (siehe restart_chrome).

• webmcp_list_tools: Listet die Tools auf, die die aktuelle Seite dem Browser bereitstellt (Name, Beschreibung, inputSchema, frameId).

• webmcp_invoke_tool: Ruft ein Seiten-Tool anhand des Namens auf. input ist ein JSON-Objekt-String (z. B. "{}" oder "{\"product\":\"knot\"}"), der dem inputSchema des Tools entspricht. Blockiert bis zu 30 Sekunden, während auf das Ergebnis gewartet wird.

• webmcp_get_invocation: Gibt den Status (Pending/Completed/Error/Canceled) und das Ergebnis eines Aufrufs anhand der invocationId zurück – nicht blockierend.

• webmcp_list_invocations: Listet alle Aufrufe in der Sitzung mit ihrem Status auf, mit optionalem status-Filter.

  ⚠️ Zustimmungsdialoge: Seiten-Tools mit Nebenwirkungen (Zwischenablage-Schreibvorgänge, Formularübermittlungen …) können einen Bestätigungsdialog auf der Seite anzeigen, den ein Mensch anklicken muss. In diesem Fall gibt webmcp_invoke_tool einen Timeout-Fehler zurück, der die invocationId enthält – der Aufruf bleibt Pending (er wird NICHT abgebrochen), sodass Sie ihn nach der Genehmigung oder Ablehnung durch den Benutzer mit webmcp_get_invocation abfragen können.

🧪 Stabilität & Zuverlässigkeit

• Umfangreiche Unit-Tests: Umfassende Testsuite, die die Zuverlässigkeit der Ereignisverarbeitung und der Tool-Deserialisierung gewährleistet, insbesondere im debugger-Bereich.

• Nebenwirkungsfreie Tests: Alle Unit-Tests sind so konzipiert, dass sie isoliert ausgeführt werden, ohne echte Chrome-Instanzen zu starten oder das Dateisystem zu verändern.

• Internes Refactoring: Entkoppelte Kernlogik durch Traits und Dependency Injection, um die langfristige Wartbarkeit zu gewährleisten.

Related MCP server: chrome-devtools-mcp

⚙️ Konfiguration

Standardmäßig ermittelt der MCP-Server die Chrome-Ausführungsdatei über die plattformübergreifende Suche von cdp-browser-lite: zuerst CHROME_PATH (absolute Priorität), dann gängige Binärdateien in Ihrem PATH (google-chrome, google-chrome-stable, chromium, chromium-browser), dann betriebssystemspezifische Speicherorte (/Applications/Google Chrome.app/... unter macOS, das Installationsverzeichnis von chrome.exe unter Windows, /usr/bin/google-chrome, /opt/google/chrome/chrome und /snap/bin/chromium unter Linux). Dies ist eine echte Obermenge der Pfade, die der Server zuvor fest codiert hatte.

Argumente:

• --local: Beschränkt die Navigation ausschließlich auf lokale Adressen (localhost, 127.0.0.1, 192.168.x.x oder *.local). Aus Sicherheitsgründen dringend empfohlen.

• --headless: Führt Chrome im Headless-Modus aus (ohne GUI). Unverzichtbar für Docker- oder Serverumgebungen.

• --user-profile: Verwendet das Standard-Systembenutzerprofil (Sitzungen, Cookies usw.) anstelle eines neuen. Dies ist nützlich, um wiederholte Anmeldungen während Recherchesitzungen zu vermeiden.

• --host: Gibt den Zielhost für die Chrome-Instanz an (Standard: 127.0.0.1). Verwenden Sie host.docker.internal, um von einem Container aus eine Verbindung zu einem Host-Rechner herzustellen.

• --port: Gibt den Remote-Debugging-Port an (Standard: 9222).

• --enable-automation: Aktiviert die Infoleiste „Wird von automatisierter Software gesteuert“.

• --max-instances: Begrenzt die maximale Anzahl gleichzeitiger Chrome-Instanzen (Standard: 8). Wird ignoriert, wenn --user-profile gesetzt ist.

Umgebungsvariablen:

• CHROME_PATH: Definiert den Pfad zur Chrome-Ausführungsdatei explizit.

🐳 Docker- & Headless-Nutzung (v1.0.0)

chrome-debug-mcp ist vollständig containerbereit. Dies ermöglicht mehrere leistungsstarke Anwendungsfälle für LLMs:

1. Cloud-Bereitstellung (über Glama)

Der einfachste Weg, diesen Server zu nutzen. Glama erzeugt einen Docker-Container mit vorinstalliertem Chrome. Das LLM erhält sofortigen Zugriff auf einen Browser in der Cloud, ohne jegliche lokale Einrichtung.

2. Isolierte lokale Nutzung

Führen Sie alles in Docker aus, um die Installation von Chrome oder Rust auf Ihrem Host-Rechner zu vermeiden:

docker build -t chrome-mcp .
docker run -i --rm chrome-mcp --headless

3. Hybridmodus (Container steuert Host)

Der MCP-Server läuft in einem sicheren Docker-Container, steuert jedoch die Chrome-Instanz auf Ihrem tatsächlichen Desktop. Dadurch kann das LLM Sie in Ihrer echten Browsersitzung unterstützen:

1. Starten Sie Ihr lokales Chrome mit: --remote-debugging-port=9222

   • Hinweis: Wenn Sie in diesem Modus Proxy-Unterstützung benötigen, müssen Sie Chrome auch mit dem Flag --proxy-server="http://your-proxy:port" starten.

2. Führen Sie den Container aus:

# On macOS/Windows
docker run -i --rm chrome-mcp --host host.docker.internal

🚀 Schnellstart

Der einfachste Weg, den MCP-Server nativ zu installieren und auszuführen, ist über Rusts Cargo oder durch Herunterladen der vorkompilierten Binärdateien. Sie müssen Chrome nicht mehr manuell starten – der MCP-Server startet automatisch eine sichtbare Instanz von Chrome mit den korrekten Debugging-Flags.

1. Installation

Option A: Vorkompilierte Binärdateien (empfohlen) Gehen Sie zur Releases-Seite und laden Sie die native ausführbare Datei für Ihre Plattform herunter (macOS, Windows, Linux). Wir bieten .msi-Installationsprogramme für Windows und Shell-Skripte für UNIX-Systeme.

Option B: Installation über Cargo

cargo install --git https://github.com/raultov/chrome-debug-mcp

Option C: Installation über Shell-Skript (Unix)

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/raultov/chrome-debug-mcp/releases/latest/download/chrome-debug-mcp-installer.sh | sh

2. Konfigurieren Sie Ihren MCP-Client

Dieser Server ist vollständig getestet und nachweislich mit Claude Code, agy und codex kompatibel. Konfigurieren Sie Ihren KI-Client so, dass er den Server in einem der folgenden Modi ausführt.

Universelle Konfiguration (JSON)

Die meisten MCP-Clients (wie Claude Code oder jede JSON-basierte Konfiguration) verwenden diese Struktur. Hier sind die drei Hauptnutzungsmodi:

{
  "mcpServers": {
    "chrome-debug-mcp": {
      "command": "chrome-debug-mcp",
      "args": [],
      "env": {}
    },
    "chrome-docker": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "chrome-debug-mcp:v1.0.9", "--headless"]
    },
    "chrome-docker-hybrid": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "--net=host",
        "chrome-debug-mcp:v1.0.9",
        "--host",
        "127.0.0.1"
      ]
    }
  }
}

Hinweis: Der chrome-docker-hybrid-Modus mit --net=host ist unter Linux der empfohlene Weg, damit der Container auf Ihre lokale Chrome-Instanz unter 127.0.0.1 zugreifen kann.

Claude Code

Um den Server in Claude Code hinzuzufügen und zu aktivieren:

claude mcp add chrome-debug-mcp chrome-debug-mcp

3. Verwendung

Sobald die Verbindung hergestellt ist, übernimmt der KI-Agent automatisch das Starten von Chrome, wenn der erste Befehl ausgeführt wird. Der Browser bleibt sichtbar, sodass Sie den Debugging-Prozess visuell verfolgen können.

4. Agent-Workflows & Multi-Instanz-Anleitung

LLMs können diesen Server mit einigen optimierten Mustern bedienen:

A. Isolierte Multi-Instanz-Szenarien

Wenn Sie automatisierte Browsersitzungen ausführen, können Sie separate Chrome-Prozesse starten, um Cookie-Verschmutzung oder Tab-Kollisionen zu vermeiden:

1. Rufen Sie open_instance mit label: "user-session-1" oder optionalen Proxy-Server-Konfigurationen auf. Dies gibt eine eindeutige instance_id zurück (z. B. chrome-2).

2. Übergeben Sie die instance_id explizit an nachgelagerte Tools wie navigate, evaluate_js oder webmcp_list_tools.

3. Geben Sie Ressourcen nach Abschluss mit close_instance frei.

B. Arbeiten mit WebMCP

Wenn Sie zu einer Seite navigieren, die WebMCP unterstützt (z. B. https://www.knot.kz/#/agent-tools):

1. Tools, die von der Webseite registriert wurden, können mit webmcp_list_tools abgerufen werden.

2. Standardmäßig ist WEB_MCP aus Sicherheitsgründen deaktiviert. Wenn die Tool-Liste leer ist, rufen Sie restart_chrome mit features: ["WEB_MCP"] auf und führen Sie dann reload aus.

3. Rufen Sie Seiten-Tools mit webmcp_invoke_tool auf und übergeben Sie JSON-Argumente als Eingabe. Wenn ein Zustimmungsdialog die Ausführung auf der Webseite anhält, endet das Tool nach 30 Sekunden mit einem Timeout, der Aufruf bleibt jedoch anhängig. Sie können das Ergebnis mit webmcp_get_invocation abfragen.

🛠 Kompilierung (aus dem Quellcode)

Wenn Sie aus dem Quellcode kompilieren möchten:

git clone https://github.com/raultov/chrome-debug-mcp
cd chrome-debug-mcp
cargo build --release

Die resultierende Binärdatei befindet sich in target/release/chrome-debug-mcp. Dieses Projekt verwendet cargo-dist, um die native plattformübergreifende Verteilung nahtlos über GitHub Actions zu übernehmen.

📖 Warum dieser MCP-Server?

Andere Integrationsserver wie Puppeteer/Playwright-Wrapper sind hochabstrakt, schwergewichtig und scheitern typischerweise daran, echte, interaktive Schritt-für-Schritt-Debugger bereitzustellen. Dieser MCP-Server verwendet rohe CDP-Nachrichten und bildet sie 1:1 auf LLM-Tools ab, sodass intelligente Agenten buchstäblich über JS hinwegschreiten, lokale Bereichsvariablen nativ lesen, in V8-Compilerkontexten suchen und genau verstehen können, warum ein Skript abstürzt.

📜 Lizenz

Dieses Projekt ist unter der MIT-Lizenz lizenziert. Weitere Einzelheiten finden Sie in der LICENSE-Datei.