Zwei Protokolle dominieren die KI-Browser-Steuerung: CDP (Chrome DevTools Protocol) und MCP (Model Context Protocol). Sie lösen unterschiedliche Probleme auf unterschiedlichen Ebenen, doch Entwickler, die Browser-Agenten bauen, verwechseln sie häufig oder wählen das falsche für ihren Anwendungsfall. Dieser Leitfaden erklärt, was jedes Protokoll tut, wann welches zum Einsatz kommt und wie beide in einem produktiven Agenten-Stack zusammenarbeiten.
TL;DR: CDP gibt Ihrem Agenten direkte Low-Level-Kontrolle über einen Browser per WebSocket-Verbindung. MCP gibt Ihrem LLM High-Level-Browser-Tools über eine standardisierte Tool-Use-Schnittstelle. CDP ist der Motor; MCP ist das Lenkrad. Die meisten produktiven KI-Agenten brauchen beides: MCP, damit das LLM Aktionen entscheidet, und CDP darunter, damit der Browser tatsächlich funktioniert. Clawbrowser unterstützt beide Protokolle nativ.
Hinweis: „CDP" bezieht sich in diesem Artikel auf Chrome DevTools Protocol, den Standard für Browser-Steuerung.
Was CDP und MCP tatsächlich sind
CDP: Chrome DevTools Protocol
CDP ist ein WebSocket-basiertes Protokoll zur programmatischen Steuerung von Chromium-Browsern. Google hat es für Chrome DevTools gebaut (den Inspektor, den Sie mit F12 öffnen), aber es wurde zum Standard für Browser-Automatisierung. Playwright, Puppeteer und jede größere Automatisierungsbibliothek nutzen intern CDP.
Wenn Sie page.goto() in Playwright aufrufen, sendet es einen CDP-Befehl über einen WebSocket an den Browser. CDP bietet granulare Kontrolle: Seiten navigieren, JavaScript ausführen, Netzwerkanfragen abfangen, Cookies manipulieren und Screenshots aufnehmen.
# CDP: your code controls the browser directly
from playwright.async_api import async_playwright
async with async_playwright() as p:
browser = await p.chromium.connect_over_cdp("http://127.0.0.1:9222")Für den vollständigen CDP-Leitfaden siehe CDP-Browser für KI-Agenten: Entwicklerhandbuch.
MCP: Model Context Protocol
MCP ist ein Protokoll, das standardisiert, wie LLMs sich mit externen Tools verbinden. Statt für jedes Tool eigene Function-Call-Definitionen zu schreiben, entdeckt das LLM verfügbare Tools über einen MCP server und ruft sie über eine Standardschnittstelle auf.
Für die Browser-Steuerung stellt ein MCP server Aktionen wie navigate, click, type, screenshot und extract als Tools bereit, die das LLM aufrufen kann. Das LLM entscheidet anhand der Aufgabe, welches Tool es nutzt. Kein Playwright-Code, keine CSS-Selektoren, keine eigenen Tool-Definitionen in Ihrem Agenten.
{
"mcpServers": {
"clawbrowser": {
"command": "clawctl",
"args": ["mcp", "serve"]Fügen Sie diese Konfiguration in Claude Code, Cursor, Gemini CLI oder einen beliebigen MCP-kompatiblen Agenten ein. Das LLM erhält sofort Browser-Tools.
Warum sie verwechselt werden
Beide Protokolle verbinden einen KI-Agenten mit einem Browser. Beide tragen das Wort „Protokoll" im Namen. Beide tauchen in denselben Gesprächen über KI-Agenten-Infrastruktur auf. Aber sie arbeiten auf unterschiedlichen Ebenen:
- CDP ist ein Protokoll auf Browser-Ebene. Es kommuniziert mit Chromium.
- MCP ist ein Protokoll auf Anwendungsebene. Es kommuniziert mit LLMs.
Ein MCP-Browser-Server nutzt intern CDP, um den Browser zu steuern. Sie sind keine Alternativen. Sie sind Schichten im selben Stack.
Direkter Vergleich
| CDP (Chrome DevTools Protocol) | MCP (Model Context Protocol) | |
|---|---|---|
| Erstellt von | Google (Chrome-Team) | Anthropic |
| Protokolltyp | Browser-Steuerung (WebSocket) | Tool-Nutzung (stdio/SSE) |
| Wer ruft es auf | Ihr Code (Playwright, Puppeteer, roher WebSocket) | Ein LLM (Claude, GPT, Gemini) |
| Kontrollebene | Low-Level: DOM, Netzwerk, JavaScript-Ausführung, Cookies | High-Level: navigate, click, type, screenshot, extract |
| Einrichtung | Verbindung zum Debugging-Port eines Browsers | MCP server im Agenten konfigurieren |
| Flexibilität | Voll: alles, was der Browser kann | Beschränkt auf die vom Server bereitgestellten Tools |
| Geschwindigkeit pro Aktion | Millisekunden (keine Inferenz) | 0,5–3 Sekunden (LLM entscheidet jeden Schritt) |
| Fehlerbehandlung | Ihr Code behandelt Fehler | Das LLM analysiert die Fehler |
| Anti-Detection | Nicht integriert (browserabhängig) | Nicht integriert (browserabhängig) |
| Ideal für | Geskriptete Automatisierung, feinkörnige Kontrolle, Framework-Entwicklung | LLM-gesteuertes Browsen, offene Aufgaben, schnelles Prototyping |
Keines der Protokolle bietet Anti-Detection. Das ist ein Problem auf Browser-Ebene, kein Protokollproblem. Eine Standard-Chrome-Instanz, die über CDP oder einen MCP server verbunden ist, gibt dieselben Automatisierungssignale preis. Anti-Detection erfordert eine Lösung auf Engine-Ebene wie Clawbrowser: verwaltete fingerprints über 20+ Oberflächen, integriertes proxy routing und CDP-Signal-Unterdrückung auf Chromium-Quelltextebene.
Wann CDP verwenden
Verwenden Sie CDP, wenn Sie präzise, programmatische Kontrolle über den Browser brauchen und die genauen Schritte vorab kennen.
Szenarien, in denen CDP gewinnt:
- Strukturiertes Scraping. Sie wissen, welche Selektoren Sie ansprechen, welche Daten Sie extrahieren und wie Sie mit Paginierung umgehen. Ihr Code führt jedes Mal dieselben Schritte aus.
- Netzwerk-Interception. Sie müssen Ressourcen blockieren, Request-Header ändern, API-Antworten erfassen oder JavaScript vor dem Seitenladen injizieren.
- Komplexe Wartebedingungen. Sie müssen auf bestimmte DOM-Elemente, Netzwerk-Idle-Zustände oder Änderungen von JavaScript-Variablen warten, bevor Sie handeln.
- Performancekritische Automatisierung. CDP-Befehle werden in Millisekunden ausgeführt. Kein LLM-Inferenz-Delay pro Aktion. Ein 50-Schritte-Scraping-Job, der über CDP Sekunden dauert, würde mit LLM-Reasoning pro Schritt Minuten brauchen.
- Framework-Entwicklung. Sie bauen ein Agenten-Framework, ein Test-Harness oder eine Automatisierungsbibliothek, die andere nutzen werden.
# CDP: full control, full responsibility
await page.wait_for_selector("#login-form")
await page.fill("#email", "[email protected]")
await page.fill("#password", credentials)
await page.click("#submit")Der Kompromiss: Sie schreiben und pflegen den gesamten Browser-Glue-Code. Jeden Selektor, jede Wartebedingung, jeden Error-Handler. Wenn sich die Seitenstruktur ändert, bricht Ihr Code.
Wann MCP verwenden
Verwenden Sie MCP, wenn das LLM anhand dessen, was es auf der Seite sieht, entscheiden soll, was als Nächstes zu tun ist.
Szenarien, in denen MCP gewinnt:
- Offenes Browsen. „Finde die Preisseite und extrahiere die Plandetails." Der Agent navigiert, liest die Seite und entscheidet ohne hartcodierte Selektoren, worauf er klickt.
- Mehrstufige Workflows mit Urteilsvermögen. „Melde dich an, prüfe ob es eine neue Rechnung gibt, lade sie herunter wenn der Betrag über 500 $ liegt." Das LLM übernimmt die bedingte Logik, indem es bei jedem Schritt den Seiteninhalt liest.
- Schnelles Prototyping. Sie wollen in fünf Minuten einen Browser-Agenten ohne Playwright-Code. MCP-Konfiguration hinzufügen, Aufgabe beschreiben, fertig.
- Nicht-technische Nutzer. Der Agent-Betreiber beschreibt Aufgaben in natürlicher Sprache. Kein Code nötig.
- Agenten-native Umgebungen. Claude Code, Cursor und Gemini CLI sprechen bereits MCP. Einen Browser hinzufügen ist ein einziger Konfigurationsblock.
# MCP: the LLM decides what to do
User prompt: "Go to example.com and tell me the page title"
LLM calls: navigate(url="https://example.com")
LLM calls: screenshot()Der Kompromiss: weniger Präzision. Das LLM könnte auf das falsche Element klicken, zusätzliche Schritte machen oder Seiteninhalt falsch lesen. Jede Aktion bringt LLM-Inferenz-Latenz mit sich. Netzwerkanfragen abfangen oder JavaScript injizieren ist über Standard-MCP-Browser-Tools nicht möglich.
Wann beide zusammen verwenden
Hier landen die meisten produktiven KI-Agenten. MCP übernimmt die LLM-zu-Agent-Schnittstelle. CDP übernimmt die Agent-zu-Browser-Schnittstelle. Der MCP server sitzt dazwischen und übersetzt High-Level-Tool-Aufrufe in Low-Level-Browser-Befehle.
LLM ← MCP → MCP Server ← CDP → Browser
(clawctl) (Clawbrowser)Das LLM sendet MCP-Tool-Aufrufe („navigiere zu dieser URL", „klicke den Login-Button"). Der MCP server übersetzt diese in CDP-Befehle und schickt sie an den Browser. Ergebnisse fließen die Kette zurück.
Warum die Browser-Schicht zählt
Die meisten MCP-Browser-Server verbinden sich über CDP mit einer Standard-Chrome-Instanz. Der Browser hat kein fingerprint management, kein proxy routing, keine Anti-Detection. Ihr Agent funktioniert auf Demo-Seiten, wird aber auf Produktionswebsites hinter Cloudflare, DataDome oder Akamai blockiert.
Der integrierte MCP server von Clawbrowser verbindet sich mit der eigenen Chromium-Engine. Wenn das LLM navigate aufruft, sendet der MCP server einen CDP-Befehl an einen Browser, der bereits verwaltete fingerprints, geo-ausgerichtetes proxy routing und CDP-Signal-Unterdrückung auf Engine-Ebene hat. Keine Stealth-Plugins, keine Proxy-Middleware, kein Code zur Fingerprint-Rotation.
MCP-Pfad (LLM-gesteuert, kein Glue-Code):
{
"mcpServers": {
"clawbrowser": {
"command": "clawctl",
"args": ["mcp", "serve"]CDP-Pfad (geskriptet, volle Kontrolle):
browser = await playwright.chromium.connect_over_cdp(
"http://127.0.0.1:9222"
)Beide Pfade verbinden sich mit derselben Clawbrowser-Instanz mit denselben fingerprints, demselben proxy routing und derselben Anti-Detection. Wählen Sie die Schnittstelle, die zu Ihrem Anwendungsfall passt. Nutzen Sie beide im selben Projekt, wenn verschiedene Teile des Workflows unterschiedliche Kontrollstufen brauchen.
Eine Schritt-für-Schritt-Anleitung zum Bau eines Agenten mit beiden Protokollen finden Sie unter Einen KI-Agenten bauen, der das Web durchsucht.
Entscheidungsframework
| Frage | CDP | MCP |
|---|---|---|
| Kennen Sie die genauen Schritte vorab? | Ja | CDP verwenden |
| Soll das LLM entscheiden, worauf geklickt wird? | MCP verwenden | Ja |
| Brauchen Sie Netzwerk-Interception? | Ja | Nicht verfügbar |
| Brauchen Sie Aktionsgeschwindigkeit unter einer Sekunde? | Ja | Nein (LLM-Latenz) |
| Bauen Sie für Nicht-Entwickler? | Nein | Ja |
| Nutzen Sie Claude Code oder Cursor? | Verfügbar | Native Integration |
| Wollen Sie keinen Browser-Code schreiben? | Nein | Ja |
Wenn Sie auf beiden Seiten „ja" geantwortet haben, nutzen Sie beide: MCP für die LLM-gesteuerten Teile, CDP für die Präzisionsteile. Clawbrowser übernimmt die Browser-Schicht für beide Protokolle.
FAQ
Kann ich zwischen CDP und MCP wechseln, ohne den Browser zu ändern?
Ja, wenn Ihr Browser beide unterstützt. Clawbrowser stellt einen CDP endpoint pro Profil bereit und liefert einen integrierten MCP server. Verbinden Sie Playwright mit dem CDP endpoint für geskriptete Automatisierung und nutzen Sie den MCP server für LLM-gesteuertes Browsen, beides gegen dieselben Browserprofile mit denselben fingerprints und Sessions. Siehe Cursor über CDP mit einem echten Browser verbinden für eine Anleitung beider Verbindungsmethoden.
Welches Protokoll ist schneller?
CDP. Befehle werden in Millisekunden ausgeführt, da keine LLM-Inferenz beteiligt ist. MCP fügt 0,5–3 Sekunden pro Aktion hinzu, weil das LLM entscheiden muss, welches Tool es aufruft, und das Ergebnis interpretieren muss. Bei einem 50-Schritte-Scraping-Job ist CDP in Sekunden fertig. Derselbe Job über MCP braucht Minuten. Nutzen Sie CDP für Massenautomatisierung, bei der Sie die Schritte kennen. Nutzen Sie MCP für Aufgaben, die bei jedem Schritt Urteilsvermögen erfordern.
Was ist mit WebDriver BiDi?
WebDriver BiDi ist ein W3C-Standard, der sowohl WebDriver (verwendet von Selenium) als auch Teile von CDP durch ein browseragnostisches Protokoll ersetzen soll. Er reift noch. Playwright und Puppeteer nutzen intern weiterhin CDP. Wenn WebDriver BiDi volle Verbreitung erreicht, wird es auf der Browser-Steuerungsebene mit CDP konkurrieren, nicht mit MCP auf der Tool-Use-Ebene. Das CDP-vs-MCP-Entscheidungsframework in diesem Artikel gilt unabhängig davon, welches Low-Level-Browser-Protokoll sich durchsetzt.
Brauche ich einen Anti-Detect-Browser für eines der Protokolle?
Ja, wenn Ihr Agent auf Websites mit Anti-Bot-Schutz automatisiert. Weder CDP noch MCP enthält Anti-Detection. Es sind Protokolle zum Senden von Befehlen an einen Browser. Wenn der Browser Automatisierungssignale preisgibt (navigator.webdriver, Headless User-Agent, generischer Canvas-Hash), blockiert die Website ihn unabhängig vom verwendeten Protokoll. Siehe Browser-Automatisierung ohne Blockierung für das vollständige Erkennungsmodell.
Loslegen
Installieren Sie Clawbrowser von clawbrowser.ai, indem Sie den Installationsprompt in Ihren KI-Agenten einfügen.
MCP-Pfad (LLM-gesteuert): Fügen Sie die Clawbrowser MCP server-Konfiguration zu Ihrem Agenten hinzu und beginnen Sie mit dem Browsen in natürlicher Sprache.
CDP-Pfad (geskriptet): Verbinden Sie Playwright oder Puppeteer mit dem CDP endpoint und schreiben Sie Ihren Automatisierungscode.
Beides: Nutzen Sie MCP für die Teile, in denen das LLM über die nächsten Schritte nachdenkt. Nutzen Sie CDP für die Teile, in denen Sie präzise, schnelle, deterministische Kontrolle brauchen. Derselbe Browser, dieselben fingerprints, dieselben Sessions.
Für den CDP-Leitfaden lesen Sie CDP-Browser für KI-Agenten: Entwicklerhandbuch. Für ein vollständiges Build-Tutorial lesen Sie Einen KI-Agenten bauen, der das Web durchsucht.
Continue exploring
Ask AI how Clawbrowser helps
Weiterlesen
Ähnliche Artikel
Cursor über CDP mit einem echten Browser verbinden
Der integrierte Browser von Cursor ist ein isoliertes Webview. Verbinden Sie Cursor per CDP mit Clawbrowser für persistente Profile, verwaltete fingerprints und proxy routing.
Artikel lesen →
CDP-Browser für KI-Agenten: Ein Entwicklerhandbuch
Chrome DevTools Protocol ist die Standardmethode, mit der KI-Agenten Browser steuern. Standard Chrome wird erkannt. So verbinden Sie Ihren Agenten mit einem CDP-Browser, der nicht blockiert wird.
Artikel lesen →