von generativer KI erstellt.
Am 5. August 2026 hat Shopify eine Zeile ins Entwickler-Changelog geschrieben, die für Shopbetreiber mehr bedeutet als die meisten Feature-Ankündigungen des Jahres: Online-Shops stellen ab sofort WebMCP-Werkzeuge bereit, die KI-Agenten aufrufen können. Kein Installationsschritt, keine Einstellung im Admin, keine Ankündigung an Merchants.
Damit verschiebt sich etwas Grundsätzliches. Bisher ging es im Agentic Commerce fast immer um Auffindbarkeit: Wie versteht ein Modell meine Produktdaten, wie taucht mein Shop in ChatGPT oder AI Overviews auf. WebMCP betrifft eine andere Ebene. Hier bedient ein Agent den laufenden Shop im Tab des Kunden.
Was WebMCP überhaupt ist
WebMCP ist ein Standardentwurf, an dem Google, Microsoft und Shopify gemeinsam arbeiten. Die Idee ist schlicht: Eine Webseite meldet dem Browser eigene Werkzeuge an, jedes mit Namen, Beschreibung und einem JSON-Schema für Ein- und Ausgaben. Ein KI-Agent im Browser liest diese Liste und ruft die Werkzeuge direkt auf.
Der Unterschied zum bisherigen Verfahren ist erheblich. Ein Agent ohne WebMCP muss die Seite ansehen, den Quelltext deuten und Klicks nachahmen. Das ist langsam, bricht bei jedem Theme-Update und rät bei Varianten. Ein Agent mit WebMCP schickt strukturierte Eingaben und bekommt strukturierte Daten zurück.
Für den Shop heißt das: Die Storefront beschreibt sich selbst, statt sich anschauen zu lassen. Und Shopify hat diese Beschreibung für alle Shops einmal zentral geschrieben.
Die zehn Werkzeuge im Überblick
Shopify liefert einen festen Satz von zehn Werkzeugen aus, in vier Gruppen. Jeder Shop bekommt denselben Satz, unabhängig von Branche, Theme oder Sortiment.
Katalog: search_catalog durchsucht Produkte, Kollektionen, Artikel und Seiten. browse_store listet Kollektionen oder deren Produkte. get_product liefert vollständige Produktdaten mit Varianten, Preisen und Verfügbarkeit. show_variant öffnet eine Produktseite mit passend vorgewählter Variante, auch bei unvollständiger Angabe.
Warenkorb: get_cart liest den Warenkorb mit Positionen, Mengen und Summen. update_cart legt hinein, ändert Mengen oder entfernt Positionen. cancel_cart leert ihn vollständig.
Checkout: proceed_to_checkout bringt den Kunden nach einer Prüfung des Warenkorbs zum Checkout. manage_orders führt zur Bestellhistorie, falls nötig mit vorherigem Login.
Shop-Informationen: search_shop_policies_and_faqs beantwortet Fragen zu Richtlinien, Versand und Abläufen.
Bemerkenswert ist, was hier fehlt und was drin ist. Es gibt kein Werkzeug für Rabattcodes, keins für Verfügbarkeitsbenachrichtigungen, keins für Beratungsstrecken. Es gibt aber eines, das den Warenkorb komplett leert, und eines, das zum Checkout führt. Der Satz ist auf den Kaufpfad ausgelegt, nicht auf Service.
Was wir in zwei Live-Shops gemessen haben
Ankündigung und Alltag fallen bei neuen Standards regelmäßig auseinander. Also haben wir am 11. August 2026 nachgesehen, statt die Pressemitteilung nachzuerzählen. Getestet auf zwei öffentlichen Shopify-Storefronts, einem deutschen und einem amerikanischen, in einem Chromium-148-basierten Browser, der nicht am Origin Trial teilnimmt.
Das Ergebnis war in beiden Shops identisch. Die Browser-Schnittstelle existiert nicht, weder unter navigator.modelContext noch unter document.modelContext. Damit kann sich auch kein Werkzeug anmelden. Das deckt sich mit den Voraussetzungen: WebMCP läuft laut Chrome-Dokumentation ab Chrome 149 als Origin Trial, für lokale Tests gibt es die Flag chrome://flags/#enable-webmcp-testing. Wo diese Voraussetzungen nicht erfüllt sind, passiert schlicht nichts. Welche davon in unserem Fall zuerst greift, lässt sich mit dieser Messung nicht auseinanderhalten, und für das Ergebnis macht es keinen Unterschied.
Interessanter ist die zweite Hälfte des Befunds. Der Shop selbst ist längst vorbereitet. In beiden Storefronts steht window.Shopify.MCP.enabled auf true, es gibt einen ausgewiesenen Endpunkt unter /api/mcp, und window.Shopify.actions stellt getCart, updateCart und openCart bereit. Genau über diese Aktionen laufen später die Warenkorb-Werkzeuge.
Ein Detail passt dabei nicht ins einfache Bild: In window.Shopify.MCP.tools steckt in beiden Shops genau eine Werkzeugdefinition, search_shop_policies_and_faqs, samt vollständigem Eingabeschema. Zehn Werkzeuge stehen in der Dokumentation, fünf liefert der Endpunkt, eines liegt im Seitenobjekt. Warum ausgerechnet dieses eine dort vorgehalten wird, ist nicht dokumentiert. Wir schreiben es hin, statt es zu deuten, denn wer unser Snippet selbst ausführt, sieht dasselbe.
Der Endpunkt /api/mcp ist bereits heute produktiv. Eine tools/list-Abfrage liefert dort fünf Werkzeuge: search_catalog, get_product_details, get_cart, update_cart und search_shop_policies_and_faqs. Das ist nicht der WebMCP-Satz, sondern das serverseitige Storefront MCP. Vier der fünf Namen sind identisch mit den WebMCP-Werkzeugen, nur get_product_details heißt im Browser get_product. Der Server-Satz ist also eine kleinere Teilmenge: ohne show_variant, ohne cancel_cart, ohne proceed_to_checkout. Genau das ist der Unterschied zwischen Auskunft geben und den Shop bedienen.
WebMCP und Storefront MCP sind nicht dasselbe
Diese Verwechslung wird die nächsten Monate für Missverständnisse sorgen, deshalb hier die saubere Trennung.
Storefront MCP läuft auf dem Server. Ein Agent irgendwo im Netz spricht mit deinem Shop unter /api/mcp, ohne Browser und ohne Sitzung des Kunden. Das ist die Schnittstelle für externe Assistenten und eigene Agenten-Anwendungen.
WebMCP läuft im Tab des Kunden. Der Agent sitzt im Browser, arbeitet in der bestehenden Sitzung, sieht denselben Warenkorb wie der Kunde und löst dieselben Theme-Aktionen aus. Login, Währung, Markt und Rabatte gelten wie beim Menschen.
Die zweite Variante ist die kommerziell relevantere, weil sie den Kunden im Shop hält, statt ihn auf eine fremde Oberfläche zu ziehen. Sie ist auch die riskantere, weil ein fremdes Programm im Kontext einer angemeldeten Sitzung handelt.
Warum dein Theme jetzt zur Schnittstelle gehört
Ein Satz aus der Dokumentation ist wichtiger, als er aussieht: Die Warenkorb-Werkzeuge rufen dieselben Storefront-Aktionen auf, die auch Apps verwenden. Öffnet dein Theme bei jeder Änderung ein Cart-Drawer, dann löst ein Agent dieses Drawer ebenfalls aus.
Daraus folgen sehr konkrete Anforderungen an Dinge, die man sonst als Kosmetik behandelt. Ein Theme, das Warenkorb-Änderungen an eigener Logik vorbeischleust, produziert bei Agenten stille Fehler. Ein Cart-Drawer mit aufwendiger Animation, der Aktionen währenddessen verschluckt, wird zur Fehlerquelle. Varianten mit unklaren Titeln führen dazu, dass show_variant die falsche Option vorwählt.
Dasselbe gilt für Inhalte. search_shop_policies_and_faqs beantwortet Fragen zu Versand, Rückgabe und Erreichbarkeit aus dem, was im Shop hinterlegt ist. Wer dort seit drei Jahren einen Platzhaltertext stehen hat, lässt einen Agenten im Namen seines Shops raten.
Lässt sich das abschalten?
Für Hydrogen ja. Die Werkzeuge werden über ShopifyScripts geladen, und dort gibt es einen Schalter: webMcp={false}. Wer ein eigenes Framework ohne Hydrogen-Bindung nutzt, ruft initializeShopifyScripts() selbst auf und entscheidet dort.
Für Liquid-Storefronts ist in der offiziellen Dokumentation kein Opt-out beschrieben. Das heißt nicht zwingend, dass es keins gibt, aber es heißt: Es ist nicht dokumentiert, nicht im Admin sichtbar und nicht für Merchants vorgesehen. Wer die Werkzeuge aus rechtlichen oder betrieblichen Gründen nicht ausliefern will, sollte das aktiv mit Shopify klären statt auf eine Einstellung zu warten.
Auch die Gegenrichtung fehlt: Eigene Werkzeuge kann ein Merchant derzeit nicht anmelden. WebMCP als Standard erlaubt seitenbezogene Werkzeuge, eine Produktseite könnte also eine Größenberatung anbieten und eine Checkout-Seite etwas anderes. Shopify liefert stattdessen für alle Shops denselben Satz aus. Das ist bei mehreren Millionen Storefronts nachvollziehbar und nimmt dir vorerst jede Möglichkeit zur Differenzierung.
Was das für deine Zahlen bedeutet
Wenn ein Agent den Warenkorb über dieselben Aktionen ändert wie ein Mensch, dann feuern auch dieselben Ereignisse. Ein Add-to-Cart eines Agenten sieht im Theme aus wie ein Add-to-Cart eines Kunden, und alles, was daran hängt, reagiert entsprechend: Cart-Drawer, Tracking-Pixel, Upsell-App, Warenkorb-Abbruch-Strecke.
Ob Shopify solche Aufrufe intern als Agentenaktion kennzeichnet, ist nicht dokumentiert. Für die Auswertung heißt das vorerst: Du kannst nicht sauber trennen, ob ein Warenkorb von einem Menschen oder in seinem Auftrag zusammengestellt wurde. Solange die Zahlen klein sind, ist das egal. Wenn sie es nicht mehr sind, ist es die erste Frage, die im Reporting auftaucht, und die Antwort liegt dann nicht bei dir.
Die Risikoseite, nüchtern betrachtet
Ein Agent, der im Tab des Kunden arbeitet, handelt in dessen angemeldeter Sitzung. Er kann den Warenkorb füllen, ihn leeren und zum Checkout führen. Das ist genau der Funktionsumfang, den man einem hilfreichen Assistenten geben will, und genau der, den man einem manipulierten Assistenten nicht geben will.
Der wunde Punkt ist nicht die Schnittstelle, sondern die Textquelle. Agenten lesen Produktbeschreibungen, Bewertungen und Richtlinien als Kontext. Wo Nutzer Inhalte beisteuern, etwa in Bewertungen oder Fragen zum Produkt, landet fremder Text im Kontext eines Programms mit Warenkorbzugriff. Diese Angriffsklasse ist bekannt, und sie ist unabhängig davon gelöst worden, ob Shopify die Werkzeuge sauber gebaut hat oder nicht.
Praktisch bedeutet das nichts anderes als Sorgfalt an einer Stelle, die man ohnehin pflegen sollte: Moderiere nutzergenerierte Inhalte, und behandle sie als das, was sie sind, nämlich fremden Text auf deiner Domain. Die Kaufentscheidung selbst bleibt in jedem Fall beim Kunden, denn den Checkout schließt kein WebMCP-Werkzeug ab.
Was heute sinnvoll ist
Der Standard ist ein Entwurf, der Browser-Support ist ein Origin Trial, und die Zahl der Kunden, die heute mit einem Agenten in deinem Shop einkaufen, ist überschaubar. Trotzdem lohnt sich Vorbereitung, weil sie fast vollständig aus Arbeit besteht, die sich ohnehin auszahlt.
Warenkorb-Logik prüfen. Läuft jede Änderung über die Standard-Aktionen, oder hat ein Entwickler irgendwann daran vorbeigebaut? Alles, was am Standardweg vorbeigeht, sieht ein Agent nicht.
Variantentitel entrümpeln. Zwei Varianten, die beide "Standard" heißen, sind für Menschen ein Ärgernis und für show_variant ein Ratespiel.
Richtlinien und FAQ aktualisieren. Versand, Rückgabe, Erreichbarkeit, Lieferzeiten. Diese Texte sind ab jetzt Antwortmaterial, nicht Rechtsbeiwerk im Fußbereich.
Produktdaten vervollständigen. get_product gibt weiter, was gepflegt ist. Fehlende Maße, Materialien oder Lieferzeiten fehlen dem Agenten genauso wie dem Kunden.
Selbst nachsehen. window.Shopify.MCP in der Konsole des eigenen Shops zeigt in zehn Sekunden, was ausgeliefert wird. Das ersetzt jede Diskussion darüber, ob das Thema schon relevant ist.
Bei Hydrogen entscheiden. Developer Preview heißt: Es ändert sich noch etwas. Wer dort produktiv ist, sollte bewusst festlegen, ob webMcp aktiv bleibt.
Einordnung
WebMCP ist heute keine Traffic-Quelle und keine Umsatzquelle. Es ist eine Wette, an der drei große Anbieter gleichzeitig arbeiten, und Shopify hat die Kosten dieser Wette für alle Merchants auf null gesetzt, indem es sie ohne Rückfrage ausgeliefert hat. Das ist die eigentliche Nachricht: Die Schnittstelle ist da, unabhängig davon, ob jemand sie bestellt hat.
Was daraus wird, entscheidet der Browser-Markt, nicht der Shop. Bleibt es bei Chromium und einem Origin Trial, passiert wenig. Wird die Schnittstelle regulär ausgeliefert, verschiebt sich ein Teil der Bedienung von der Oberfläche in die Werkzeugliste, und dein Theme wird an einer Stelle bewertet, an der bisher niemand hingesehen hat.
Wir behandeln das Thema deshalb wie den Rest des Agentic Commerce: kein Alarmismus, keine Sonderbudgets, aber die Grundlagen sauber. Wer wissen will, wo sein Shop insgesamt steht, findet den Überblick in unserem Leitfaden zum Agentic Commerce. Und wenn du wissen willst, was deine Storefront konkret ausliefert, sprich uns an. Wir sehen im Shop nach, statt in der Ankündigung.
Tobias Graeger
Inhaber & Shopify-Entwickler
Tobias leitet alle Projekte persönlich. Mit über 50 abgeschlossenen Shopify-Projekten kennt er die Plattform vom Liquid-Template bis zur API-Integration. Sein Fokus: technisch saubere Lösungen, die mit dem Business mitwachsen.
LinkedInHat dir der Beitrag gefallen?
Ein Klick reicht und wir wissen, welche Themen wir weiter vertiefen sollen.
Feedback konnte gerade nicht gespeichert werden.
Das könnte euch auch interessieren
Shopify macht es offiziell: llms.txt, llms-full.txt und agents.md im Theme anpassen
Shopify hat den Changelog veröffentlicht. Nach Wochen voller Routing- und Inhalts-Experimente steht jetzt fest, wie llms.txt, llms-full.txt und agents.md anzupassen sind: drei Liquid-Templates im Theme, mit klarer Fallback-Kaskade. Hier der komplette Fahrplan mit Code und eigenem Live-Test.
Was Shopify im Agentic Commerce ändert: llms.txt leitet auf agents.md um
Shopify-Shops leiten llms.txt und llms-full.txt jetzt per 301 auf agents.md um. Inhalt: kein Sitemap-Doc mehr, sondern ein Runbook, das Agenten in das Universal Commerce Protocol und shop.app zwingt. Und das in genau der Woche, in der Google llms.txt zum Audit-Kriterium erklärt.