WebMCP mit Kitesurf: Browser-Aktionen sicher ausführen

WebMCP mit Kitesurf: die Kurzantwort

Für Kitesurf WebMCP wird ein MCP-kompatibler Agent über Chrome DevTools MCP mit Cloudflare Browser Run verbunden. Der WebSocket-Endpunkt erhält browser=kitesurf, außerdem muss die experimentelle WebMCP-Tool-Kategorie aktiviert werden. Dadurch stehen dem Agenten zwei zentrale Befehle zur Verfügung: list_webmcp_tools ermittelt die Aktionen einer Seite, execute_webmcp_tool führt eine davon aus.

Der Einstieg sollte mit einer rein lesenden oder reversiblen Aktion erfolgen. Cloudflare Radar eignet sich als dokumentiertes Ziel, weil die Seite Aktionen wie navigate-to und set-location bereitstellt. Zuerst das von Kitesurf gelieferte Schema prüfen, dann ausschließlich die dort erlaubten Argumente übergeben und anschließend das strukturierte Ergebnis mit dem sichtbaren Seitenzustand vergleichen. Erst wenn beides übereinstimmt, gilt der Tool-Aufruf als erfolgreich.

Diese Anleitung beschreibt einen dokumentierten Testplan; sie gibt nicht vor, einen Live-Test abzubilden. Für diesen Durchlauf standen weder ein Cloudflare-Testkonto noch ein Browser-Run-Token zur Verfügung. Deshalb werden im Folgenden auch keine erfundenen Erfolgsresultate präsentiert.

Was WebMCP in Kitesurf wirklich verändert

MCP und WebMCP erfüllen unterschiedliche Aufgaben. MCP verbindet den Agenten mit dem entfernten Browser. WebMCP erlaubt es der Website, in diesem Browser eigene, benannte Aktionen bereitzustellen. Bildlich gesprochen ist MCP die Telefonleitung und WebMCP das Menü am anderen Ende: Die Leitung stellt die Verbindung her, das Menü zeigt, was bestellt werden kann und welche Angaben dafür erforderlich sind.

Ohne dieses Menü muss ein Agent die Seite meist auslesen, ein Bedienelement finden, darauf klicken, warten und erneut auslesen. Mit WebMCP kann eine Seite stattdessen eine Funktion wie set-location samt typisierten Eingaben anbieten. Der Agent muss weiterhin die passende Aktion auswählen und das Ergebnis kontrollieren, aber nicht mehr jede Interaktion aus Pixeln oder der Seitenstruktur ableiten.

Laut Cloudflares WebMCP-Dokumentation besitzt Kitesurf eine eigene Implementierung und benötigt daher keine Chrome-Lab-Sitzung. Seiten können programmatische Tools über document.modelContext registrieren. Darüber hinaus erkennt Kitesurf deklarative Formular-Tools, die mit den Attributen toolname und tooldescription gekennzeichnet sind.

Einen MCP-Client mit Kitesurf verbinden

Benötigt werden Node.js 20.19 oder neuer, ein MCP-kompatibler Client, eine Cloudflare-Konto-ID sowie ein API-Token mit der Berechtigung Browser Rendering - Edit. Cloudflares Anleitung zur MCP-Client-Einrichtung deckt Claude Desktop, Claude Code, Cursor und OpenCode ab. Wer erstmals eine MCP-Verbindung einrichtet, findet in der Übersicht der besten MCP-Server zusätzlichen Kontext zur Aufgabe des lokalen Servers.

Cloudflares Kitesurf-Ankündigung nennt für den lokalen Client folgende Konfiguration:

{
  "mcp": {
    "kitesurf": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "chrome-devtools-mcp@latest",
        "--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/devtools/browser?browser=kitesurf",
        "--wsHeaders={\"Authorization\":\"Bearer <CLOUDFLARE_API_TOKEN>\"}",
        "--category-experimental-webmcp"
      ],
      "enabled": true
    }
  }
}

Die genaue Konfigurationsstruktur richtet sich nach dem jeweiligen Client; die Befehlsargumente müssen jedoch unverändert bleiben. Die echte Konto-ID und das Token gehören in umgebungsbasierte Secrets und nicht in eine versionierte Einstellungsdatei. Die Chrome-Lab-Parameter dürfen nicht in diese URL übernommen werden. Kitesurf verwendet browser=kitesurf, benötigt kein lab=true und akzeptiert kein keep_alive.

Besonders wichtig ist das letzte Flag. Erst --category-experimental-webmcp ergänzt Chrome DevTools MCP um list_webmcp_tools und execute_webmcp_tool. Die Verbindung selbst kann also einwandfrei funktionieren, obwohl beide WebMCP-Befehle fehlen.

Eine geprüfte Aufgabe auf Cloudflare Radar ausführen

Der kleinste aussagekräftige Test weist vier Dinge nach: Die Erkennung funktioniert, das Schema ist lesbar, die Ausführung liefert Daten und der sichtbare Seitenzustand stimmt mit dem Ergebnis überein.

1. Den verbundenen Agenten https://radar.cloudflare.com/ öffnen lassen. Die Aufgabe nur in einem Testkonto ausführen; Aktionen mit finanziellen, destruktiven oder kontoweiten Folgen sind auszuschließen.
2. list_webmcp_tools aufrufen und alle zurückgegebenen Toolnamen, Beschreibungen und Eingabeschemata speichern. Da sich das Angebot nach einer Navigation oder einer anderen Aktion ändern kann, gilt dieses Inventar nur für den aktuellen Seitenzustand.
3. Ist eine unkritische Aktion wie set-location vorhanden, wird sie ausgewählt und ihr zurückgegebenes Schema gelesen. Die Argumentnamen nicht aus diesem Artikel ableiten, sondern das Live-Schema als verbindlichen Vertrag behandeln.
4. execute_webmcp_tool mit einem schemakonformen Ortswert aufrufen. Zu protokollieren sind der exakte Toolname, die Argumente, das strukturierte Ergebnis, die verstrichene Zeit und der sichtbare Seitenzustand.
5. Die Antwort mit der Anzeige in Radar vergleichen. Nach der Zustandsänderung list_webmcp_tools erneut ausführen und hinzugekommene oder entfernte Aktionen festhalten.

Ein sinnvoller Agenten-Prompt ist bewusst direkt formuliert:

Die Nachweise sollten als kompakter Testdatensatz behandelt werden, nicht als Chatprotokoll. Mindestens folgende Felder sind erforderlich:

So wird aus einer Demo ein Test, den ein Engineering-Team wiederholen kann. Gleichzeitig lassen sich WebMCP-Fehler von Fehlern im Schlussfolgern des Agenten trennen: Fehlt das benannte Tool, scheitert die Schnittstelle bereits vor der Ausführung. Ist der Aufruf erfolgreich, aber die Seite zeigt etwas anderes, liegt der Fehler danach – in der Implementierung oder der Verifikation.

Wo Kitesurf einen Fallback braucht

Kitesurf WebMCP ist keine universelle Browser-Steuerung. Seine aktuellen Grenzen bestimmen, welche Produktionsaufgaben sich sicher darüber abwickeln lassen.

• Tools, die in einem iframe oder Popup registriert sind, werden nicht über CDP bereitgestellt. Für den Agenten gelten sie als nicht verfügbar. Stattdessen ist ein herkömmlicher Browserpfad, ein manueller Ablauf oder – bei einer eigenen Website – ein Tool auf oberster Ebene erforderlich.
• Kitesurf-Sitzungen erscheinen nicht in wrangler browser list und besitzen keine Live-Ansicht. Ein Agent kann daher kein Tool abschließen, das auf die Bestätigung einer Person wartet.
• Bei einer bestätigungspflichtigen Aktion führt Cloudflares dokumentierter manueller Weg über das WebMCP-Panel unter Application im Kitesurf-Playground. Das ist eine Übergabe, keine unbeaufsichtigte Automatisierung.
• Kitesurf implementiert weder die WebMCP-Berechtigungsrichtlinie tools noch eine herkunftsbasierte Toolfilterung. Tool-Erkennung ist keine Autorisierung. Deshalb ist eine separate Positivliste für Domains, Aktionen und Testidentitäten notwendig.
• Die Toolliste ist zustandsabhängig. Nach einer Navigation oder jeder Aktion, die die Seite verändert, muss sie erneut abgefragt werden, bevor das nächste Tool als weiterhin verfügbar gilt.

Das belastbare Produktionsmuster ist ein Router: zuerst WebMCP, wenn eine passende benannte Aktion verfügbar ist; andernfalls normale Browser Automation; bei zustimmungspflichtigen Aktionen eine Übergabe an einen Menschen. Diese Verzweigungen sollten nicht hinter einem einzigen optimistischen Prompt verschwinden.

Wirtschaftlich zählt die Wartung, nicht nur der Browserpreis

Kitesurf ist während der Beta innerhalb der Kontolimits kostenlos. Cloudflare hat jedoch nicht festgelegt, dass die allgemeinen kostenpflichtigen Browser-Run-Tarife für Mehrverbrauch auch für die kostenlose Beta gelten. Die aktuelle Preis- und Kontingentsituation von Kitesurf wird separat erläutert – einschließlich der Gründe, aus einem Beta-Angebot kein dauerhaftes Kostenmodell abzuleiten.

Für Browser-Infrastruktur existiert bereits ein reales Marktbudget. Browserbase listet kostenpflichtige Tarife für $20 und $99 pro Monat. Browserless nennt bei jährlicher Abrechnung Tarife von $25 und $140 pro Monat. Beide Produkte decken breitere Infrastrukturaufgaben ab; daraus folgt kein direkter Ersatzvergleich. Die Preise zeigen vielmehr, dass Teams schon heute für den Betrieb von Browser-Agenten bezahlen.

WebMCP verändert eine andere Kostenposition: die Wartung von Selektoren, Wiederholungsversuche und die Prüfung durch Bedienpersonal. Browser, Modell, Sicherheitskontrollen, Ergebnisvalidierung und Fallback-Pfad bleiben weiterhin notwendig. Deshalb sollte dieselbe Aufgabe auf beiden Wegen gemessen werden – mit verstrichener Zeit, Fehlversuchen, menschlichen Eingriffen und nötigen Engineering-Korrekturen. Kitesurf lohnt sich nur dort, wo die messbare Wartungsersparnis größer ist als der Integrationsaufwand.

Sieben Anwendungsfälle – wer am meisten profitiert

Alle folgenden Anwendungsfälle setzen voraus, dass die Zielseite tatsächlich ein passendes WebMCP-Tool bereitstellt. Kitesurf kann keine Website-Aktion erzeugen, die es dort nicht gibt.

Der erste Anwendungsfall bietet den breitesten Nutzen, weil die meisten Teams noch über Jahre mit einem gemischten Web arbeiten werden. Ein Router, der erkennt, wann WebMCP nicht geeignet ist, bringt mehr als eine Demo, die auf einer einzigen vorbereiteten Seite funktioniert.

Drei Produkte mit realistischem Potenzial

1. Ein WebMCP-first-Fallback-Router

Für Agententeams lässt sich eine Richtlinienschicht entwickeln, die die Tools einer Seite auflistet, die angeforderte Aktion einem erlaubten Schema zuordnet und die Aufgabe entweder an execute_webmcp_tool, eine herkömmliche Browser-Automatisierung oder eine Warteschlange für Menschen weiterleitet. Das ist die stärkste Chance, weil ein solches Produkt die Einführungslücke schließt, statt darauf zu warten, dass jede Website WebMCP implementiert.

Die Nachfrage rund um diese Aufgabe ist bereits sichtbar: browser automation erreicht etwa 720 monatliche Suchanfragen, die kommerzielle Suchphrase browser automation tools etwa 260 bei einem CPC von $34.28. Die kleinste verkäufliche Version benötigt einen MCP-Client-Connector, eine Positivliste für Domains und Aktionen, einen Schema-Matcher, ein Ausführungsprotokoll und einen Fallback-Adapter.

Die Schwachstelle ist die Reichweite. WebMCP ist noch wenig verbreitet, Toolsets können sich mit dem Seitenzustand ändern und Kitesurf kann iframe- oder Popup-Tools nicht über CDP bereitstellen. Die Fallback-Engine ist deshalb Teil des Produkts und kein optionales späteres Feature.

2. Ein WebMCP-Regressionsmonitor

Websitebetreibern lässt sich eine regelmäßig ausgeführte Prüfung anbieten, die bereitgestellte Toolnamen und Schemata erfasst, eine reversible Fixture-Aktion ausführt, das Ergebnis mit der sichtbaren Seite abgleicht und bei Abweichungen alarmiert. Auf website automation entfallen etwa 590 monatliche Suchanfragen bei einem CPC von $33.88. Die verwandte Suchphrase im Singular, browser automation tool, ist laut Vorschlagsdaten im Jahresvergleich um 24% gestiegen.

Ein MVP kann eine kurze Liste eigener Routen mit Testzugängen überwachen, Tool-Inventare vor und nach der Aktion speichern und einen kompakten Fehlerdatensatz mit Argumenten, Ergebnis, Dauer und Seitenzustand erzeugen. Die Herausforderung ist der Zustand: Ein fehlendes Tool kann auf eine falsche Route oder Sitzungssituation hindeuten statt auf einen fehlerhaften Release. Deshalb braucht das Produkt reproduzierbare Navigation und sorgfältig definierte Fixtures.

3. Ein WebMCP-Readiness-Audit

Ein Preflight-Dienst für Webteams kann erfassen, welche Customer Journeys Tools auf oberster Ebene anbieten, welche Aktionen in iframes oder Popups liegen und welche die Zustimmung einer Person erfordern. Der Nachfrageindikator ist konkret: playwright browser automation erzielt etwa 320 monatliche Suchanfragen und ist im Jahresvergleich um 129% gestiegen; website automation kommt auf etwa 590.

Die kleinste Version nimmt die Routen einer eigenen Website und eine Testidentität entgegen, listet und klassifiziert die verfügbaren Tools und erstellt einen priorisierten Umsetzungsbericht. Die ehrliche Einschränkung betrifft die Beobachtbarkeit: Da Kitesurf verschachtelte iframe- oder Popup-Tools nicht über CDP bereitstellen kann, kann ein Auditor deren beabsichtigte Verträge nicht allein mit Kitesurf erschließen. Um verborgene von fehlenden Tools zu unterscheiden, sind Angaben des Websitebetreibers oder eine zweite Prüfmethode erforderlich.

Grenzen und eine ehrliche Einordnung

Kitesurf WebMCP eignet sich heute für begrenzte, reversible Aufgaben, bei denen eine strukturierte Aktion klar besser ist als eine Klickfolge. Als einziger Pfad für einen kritischen Workflow, einen verschachtelten Bezahlvorgang oder eine Aufgabe mit notwendiger Live-Freigabe durch einen Menschen ist es dagegen nicht geeignet.

Das Feature ist wertvoll, doch seine Einführung ist dem Ökosystem voraus. Benannte Aktionen können Mehrdeutigkeit verringern und Fehler leichter diagnostizierbar machen. Sie machen aber weder jede Website agentenfähig, noch beweist ein zurückgegebenes Payload, dass die Seite die richtige Aktion ausgeführt hat. Die entscheidende Produktgrenze ist die Verifikation.

Wenn dieses Verbindungs- und Verifikationssystem samt Fallback-Richtlinie für einen produktiven Agenten umgesetzt werden soll, unterstütze ich gern beim Produktionssystem.