Cloudflare WebMCP: Fast 100.000 Shops geben KI-Agenten echte Kaufwerkzeuge
Commerce.com und Cloudflare ergänzen Storefronts um typisierte Funktionen für Produktsuche, Warenkorb und Checkout-Link – ohne Änderungen am Shop-Theme.
Cloudflare und Commerce.com haben am 21. Oktober 2026 WebMCP für fast 100.000 Storefront-Domains ausgerollt. Dadurch können browserbasierte KI-Agenten einen Shop nicht nur wie eine sichtbare Webseite lesen, sondern dessen Einkaufsfunktionen als klar beschriebene Werkzeuge aufrufen: Produkte suchen, Details abrufen, den Warenkorb befüllen und einen Checkout-Link erzeugen.
Das Neue ist weniger ein weiterer Shopping-Chat als eine zusätzliche Bedienebene für bestehende Storefronts. Der Agent arbeitet mit dem tatsächlichen Katalog innerhalb der aktiven Browsersitzung. Der Händler behält Checkout, Marke und Kundenbeziehung; den Kauf schließt weiterhin der Nutzer selbst ab.
Die Storefront wird zur Werkzeugoberfläche
Ein gewöhnlicher Browser-Agent muss eine Seite visuell oder anhand ihrer HTML-Struktur deuten. Er sucht Eingabefelder, liest Produktkarten und versucht, Schaltflächen der richtigen Aktion zuzuordnen. Diese Oberfläche wurde jedoch für Menschen gestaltet. Schon eine andere Beschriftung, ein neues Theme oder ein dynamisch nachgeladenes Element kann die Orientierung erschweren.
WebMCP ergänzt diesen sichtbaren Shop um typisierte Funktionen. Die Website beschreibt gegenüber einem kompatiblen Agenten ausdrücklich, welche Aktion verfügbar ist und welche Eingaben sie erwartet. Statt eine Suchleiste nachzuahmen, kann der Agent das dafür vorgesehene Suchwerkzeug verwenden. Statt einen Preis aus einer Produktkarte herauszulesen, ruft er die Produktdetails aus dem aktuellen Shopkontext ab.
Cloudflare bezeichnet die allgemeine WebMCP-Integration als Developer Preview. Die zugehörige Zoneneinstellung webmcp_enabled befindet sich laut API-Referenz in der Beta; ihre Änderbarkeit kann vom Cloudflare-Tarif abhängen. Der großflächige Commerce.com-Rollout zeigt zugleich, wie sich diese noch junge Schnittstelle über viele bestehende Domains verteilen lässt.
Ein Einkaufsauftrag wird zu vier konkreten Aktionen
Ein praktisches Beispiel ist die Suche nach einem verfügbaren Produkt innerhalb eines vorgegebenen Budgets. Der Agent kann zuerst die Produktsuche mit den gewünschten Merkmalen aufrufen. Anschließend holt er für passende Treffer die Details ab und arbeitet dabei mit den im Store hinterlegten Preisen und Beständen.
Nach der Auswahl legt er den gewünschten Artikel in den Warenkorb. Zum Abschluss erzeugt er einen Checkout-Link und übergibt an den Nutzer. Damit reicht die Unterstützung von einer natürlichen Anfrage bis zu einem vorbereiteten Warenkorb, ohne dass der Agent die eigentliche Zahlung übernimmt.
Diese Grenze ist funktional wichtig: WebMCP automatisiert die Navigation und die vorbereitenden Shopaktionen, verlagert den Abschluss aber nicht aus der Händlerumgebung. Der Nutzer landet beim bestehenden Checkout und bestätigt den Kauf dort selbst. Commerce.com hebt hervor, dass dadurch auch die Kundenbeziehung beim Händler bleibt.
Die Bridge kommt am Cloudflare-Edge hinzu
Für die Commerce.com-Stores muss nicht jede Shopvorlage einzeln angepasst werden. Cloudflare schleust ein Bridge-Skript am Edge in die HTML-Antwort ein, bevor sie den Browser erreicht. Commerce.com beschreibt den Rollout für berechtigte B2C- und B2B-Shops von BigCommerce als standardmäßig aktiviert – ohne notwendige Code- oder Theme-Änderungen.
Im Browser registriert die Bridge die ausgewählten Werkzeugpakete über document.modelContext. Das ist der Kontaktpunkt zwischen Storefront und kompatiblem Agenten: Die Seite veröffentlicht ihre verfügbaren Funktionen innerhalb der laufenden Browsersitzung, der Agent kann sie erkennen und mit strukturierten Eingaben aufrufen.
Das Verhalten bleibt abwärtskompatibel. Erkennt die Bridge, dass ein Browser WebMCP nicht unterstützt, beendet sich das Skript. Der Shop verhält sich dann wie zuvor. Kunden ohne kompatiblen Agenten sehen und bedienen weiterhin die normale Storefront.
Katalog, Sitzung und Checkout bleiben verbunden
Der besondere Nutzen liegt in der Verbindung mit dem bereits geöffneten Shop. Der Agent operiert nicht auf einer losgelösten Produktliste, sondern in der aktiven Sitzung und mit den realen Commerce-Funktionen der Storefront. Dadurch kann eine Suche direkt in Produktdetails, Warenkorb und Checkout-Link übergehen.
Für Händler bedeutet das: Sie müssen keinen getrennten Agenten-Shop mit einem eigenen Katalog pflegen. Preise und Bestände stammen aus dem tatsächlichen Store. Auch der Warenkorb gehört zur laufenden Einkaufssitzung. Die maschinenlesbare Ebene ergänzt damit die vorhandene Verkaufsoberfläche, anstatt sie zu ersetzen.
Ein sinnvoller Einsatz ist eine zielgerichtete Produktauswahl: „Finde eine verfügbare Variante mit diesen Eigenschaften und unter diesem Preis.“ Der Agent kann die Treffer über die Suche eingrenzen, Detaildaten abrufen und die gewünschte Variante in den Warenkorb legen. Ein zweiter Einsatz ist die Rückkehr zu einem bereits konkret benannten Produkt: Details und Bestand lassen sich prüfen, bevor der Agent einen Checkout-Link vorbereitet.
Eigene MCP-Werkzeuge lassen sich anbinden
Cloudflares Integration ist nicht auf das von Commerce.com bereitgestellte Paket beschränkt. Über die Zoneneinstellung webmcp_mcp_url kann ein konfigurierbarer Pfad zu einem vorhandenen MCP-Server hinterlegt werden. Dessen Werkzeuge macht die Bridge anschließend im Browser verfügbar.
Damit können Websites ihre bereits vorhandene MCP-Oberfläche mit der browserseitigen Sitzung verbinden. Die Edge-Bridge übernimmt dabei die Registrierung im Dokument; die eigentlichen Werkzeuge kommen vom angegebenen MCP-Endpunkt. Für Storefronts eröffnet das eine Erweiterung über die vier beschriebenen Einkaufsaktionen hinaus, sofern entsprechende Funktionen im eigenen MCP-Server vorhanden sind.
Die Authentifizierung ergibt sich bei diesem Modell aus dem aktiven Webkontext und der angebundenen Anwendung. Die Quellen beschreiben keinen separaten, allgemein verfügbaren WebMCP-Zugangsschlüssel für den Agenten. Entscheidend ist vielmehr, dass die Werkzeuge von der geladenen Website innerhalb der Browsersitzung angeboten werden.
Händler behalten einen Schalter pro Store
Der Rollout ist breit, aber nicht unumkehrbar. Berechtigte B2C- und B2B-Shops von BigCommerce erhalten WebMCP standardmäßig. Händler können die Funktion in ihren Einstellungen pro Store deaktivieren. Damit lässt sich die agentische Bedienebene abschalten, ohne den normalen Shopbetrieb zu verändern.
Diese Wahlmöglichkeit ergänzt die technische Rückfalllogik im Browser: Auf Händlerseite kann WebMCP bewusst deaktiviert werden; auf Nutzerseite bleibt die Website funktionsfähig, wenn der Browser die Schnittstelle nicht versteht. Beides reduziert die Abhängigkeit des bestehenden Einkaufserlebnisses von der neuen Technik.
Cloudflares allgemeine API-Dokumentation weist außerdem darauf hin, dass die Zoneneinstellung noch Beta-Status hat und je nach Tarif nicht überall veränderbar sein kann. Für den Commerce.com-Rollout gelten die von Commerce.com beschriebenen Berechtigungs- und Store-Einstellungen.
Browser Run macht die Werkzeuge für Agenten zugänglich
Cloudflare dokumentiert WebMCP als Browser-API, über die Websites typisierte Funktionen direkt für KI-Agenten registrieren. Für die agentische Nutzung unterstützt Browser Run die Werkzeuge über experimentelle Chrome-Lab-Sitzungen, Kitesurf und das WebMCP-CDP-Protokoll.
Chrome Lab ist dabei ausdrücklich experimentell und nicht für Produktions-Workloads vorgesehen. Das ändert nichts am Storefront-Rollout, ordnet aber die derzeit verfügbaren Agentenumgebungen ein: Die Website-Seite kann bereits Werkzeuge anbieten, während einzelne Browser- und Automationswege unterschiedliche Reifegrade besitzen.
Das WebMCP-CDP-Protokoll ist besonders für technisch gesteuerte Browsersitzungen relevant. Es macht die registrierten Funktionen über die Browsersteuerung erreichbar. Kitesurf und die Chrome-Lab-Umgebung dienen als weitere Zugänge zu derselben Werkzeugschicht, ohne dass der Agent die sichtbare Oberfläche als alleinige Bedienlogik verwenden muss.
Was sich gegenüber klassischer Browserbedienung ändert
Der Unterschied liegt nicht darin, dass ein Agent plötzlich Webseiten öffnen kann. Neu ist, dass die Storefront ihre vorgesehenen Aktionen selbst benennt. Bei klassischer Browsersteuerung muss der Agent aus Darstellung und Dokumentstruktur ableiten, wie Suche, Produktauswahl und Warenkorb funktionieren. Mit WebMCP erhält er dafür explizite, typisierte Funktionen.
Das verbessert vor allem mehrteilige Aufgaben. Produktsuche, Detailabruf, Warenkorb und Checkout-Link sind keine voneinander getrennten Tricks, sondern aufeinander bezogene Shopaktionen. Der Agent kann die Ausgabe eines Werkzeugs für die nächste Entscheidung verwenden und bleibt dabei im aktuellen Storekontext.
Für den Menschen bleibt die Übergabe klar sichtbar: Der Agent bereitet vor, der Nutzer entscheidet und schließt ab. Für den Händler bleibt die bestehende Commerce-Infrastruktur maßgeblich. WebMCP ist damit keine neue Verkaufsplattform, sondern eine agentenfähige Schnittstelle auf der vorhandenen Storefront.
Das passende Einsatzprofil
WebMCP eignet sich besonders für Aufgaben, bei denen ein Nutzer sein Ziel beschreiben kann, aber nicht jede einzelne Shopinteraktion selbst ausführen möchte. Dazu zählen die Suche nach konkreten Eigenschaften, der Abgleich von Produktdetails sowie das Vorbereiten eines Warenkorbs. Der größte Gewinn entsteht, wenn mehrere dieser Aktionen in einer Sitzung zusammengehören.
Weniger verändert sich beim eigentlichen Vertragsabschluss. Zahlung und endgültige Kaufbestätigung verbleiben im Shop und beim Nutzer. Ebenso bleibt eine Storefront ohne WebMCP-fähigen Browser normal bedienbar. Händler können die zusätzliche Schnittstelle außerdem vollständig deaktivieren.
Der Rollout über fast 100.000 Domains macht aus einem frühen Browserstandard einen greifbaren Commerce-Anwendungsfall: Shops veröffentlichen nicht nur Seiten für Menschen, sondern zugleich klar definierte Werkzeuge für Agenten. Genau diese Kombination aus echtem Katalog, aktiver Sitzung und kontrollierter Übergabe zum Checkout ist der neue Baustein.