Agent-Commerce (MCP)

STOAR bringt eine eingebaute Model-Context-Protocol-Oberfläche mit, damit KI-Einkaufsagenten — ChatGPT, Claude und jeder andere MCP-Client — deinen Shop entdecken, seinen Katalog durchsuchen, Fragen aus deinen veröffentlichten Richtlinien beantworten, einen Warenkorb bauen, einen echten Lieferpreis berechnen und der Kundschaft einen sicheren Link geben können, um den Checkout im Browser abzuschließen. Mit ausdrücklicher Zustimmung der Kundin oder des Kunden kann ein Agent anschließend auch deren Bestellungen abfragen.

Es ist derselbe Kern, auf dem Storefront und REST-APIs laufen, nur als weiterer Protokoll-Adapter bereitgestellt. Hinter den Kulissen wird nichts Neues erfunden: ein von einem Agenten gebauter Warenkorb ist ein normaler Gast-Warenkorb, und ein Preis stammt aus demselben Rechner, der beim Checkout läuft — die Zahl, die ein Agent nennt, ist also auch die, die berechnet wird.

Zwei Server #

Das ist die vollständige käuferseitige Ebene. Händler- und Admin-Operationen — Produkte bearbeiten, Bestellungen erstatten, Bestände ändern — werden Agenten bewusst nicht zugänglich gemacht.

Opt-in, und standardmäßig aus #

Agent-Commerce ist Opt-in. Beide Server bleiben aus, bis du sie aktivierst, und ein Shop, der sich nicht dafür entschieden hat, antwortet mit 404 — er ist nicht einmal als MCP-Host auffindbar. Aktiviere sie unter Manager → Agent Access (MCP), wo du außerdem steuerst:

• welche der beiden Server an sind;
• ob Agenten sich identifizieren müssen, bevor sie handeln dürfen;
• Warenkorb-Obergrenzen (max. Menge pro Position, max. Positionen, max. Warenkorbwert);
• wie lange ein Übergabe-Checkout-Link gültig bleibt;
• die Anfrage-Rate und die Ergebnisgröße.

Änderungen greifen bei der nächsten Anfrage — ohne Deploy. Nichts auf einem der beiden Server kann eine Bestellung aufgeben, eine Zahlung entgegennehmen oder eine bestehende Bestellung ändern. Geld bewegt sich erst, nachdem ein Mensch den Checkout im eigenen Browser abgeschlossen hat.

Schnellstart #

Der Server wird pro Shop auf der angefragten Domain bereitgestellt, genau wie die REST-API:

https://{deine-shop-domain}/mcp

Richte einen beliebigen MCP-Client darauf aus, oder liste die Tools direkt auf:

curl -s https://app.stoar.ai/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Ein minimaler Einkaufsablauf sind fünf Aufrufe: einmal die Shop-Bedingungen lernen, ein Produkt finden, seine Varianten lesen, einen Warenkorb bauen, dann einen Lieferpreis berechnen und der Kundschaft cart.continue_url übergeben.

Tools #

Katalog

Richtlinien

Warenkorb

Alle Warenkorb-Tools werden über den cart_id-Token angesprochen, den create_cart zurückgibt.

Die Warenkorb-Tools sind gezielt, keine Komplettersetzungen: jeder Aufruf nennt nur, was er anfasst, sodass ein verwirrter Agent zwar scheitern, aber keine Position stillschweigend verlieren kann, die er zu wiederholen vergaß. Jede Mutation gibt den vollständigen Warenkorb zurück. Jede Mutation ist idempotent — dieselbe Anfrage erneut zu senden liefert das ursprüngliche Ergebnis, statt es doppelt anzuwenden.

Bestellungen

Die Übergabe #

Ein Agent baut einen Warenkorb, den er nie bezahlen kann. cart.continue_url ist der Weg, wie dieser Korb zu einem echten Kauf wird: die Kundschaft öffnet ihn im Browser, der Warenkorb lädt in ihre Sitzung, und sie landet im normalen Checkout. Der Link ist signiert, zeitlich begrenzt, auf einen Shop beschränkt und trägt immer nur einen Gast-Warenkorb — nie den Korb einer angemeldeten Kundin oder deren gespeicherte Adressen.

Sicherheitsmodell #

• /mcp ist bewusst unauthentifiziert. Alles, was es offenlegt, ist entweder ohnehin öffentlich (Katalog, Richtlinien) oder über einen nicht erratbaren Token adressiert (ein Warenkorb, oder eine Bestellung mit ihrem per E-Mail versandten Lookup-Token). Kein Kundendatensatz, keine Bestellhistorie, keine Zahlungs- oder Adressdaten sind ohne die eigene Berechtigung der Kundschaft erreichbar.
• /mcp/account erfordert einen Kunden-Token, den die Kundschaft selbst erzeugt, beschränkt auf eine einzige, nur lesende Berechtigung. Es ist keine Admin-Berechtigung und kann keine andere API steuern.
• Die Gast-Bestellabfrage ist token-geschützt, nicht per E-Mail + Bestellnummer. Bestellnummern sind fortlaufend, daher ließe eine maschinell erreichbare E-Mail-Prüfung das Durchzählen fremder Kaufhistorien zu. Der je-Bestellung-Token liegt bereits in der Bestätigungs-E-Mail, es wird also nichts Neues ausgegeben und nichts Neues preisgegeben.
• Vor Gästen verborgene Preise bleiben verborgen. In einem B2B-Shop, der Preise vor nicht angemeldeten Besuchern verbirgt, sehen Agenten dieselbe Schwärzung, und der Warenkorbbau ist deaktiviert, statt einen Korb mit unbekanntem Wert zu erzeugen.
• Die Mandanten werden aus der angefragten Domain aufgelöst und können durch kein Argument überschrieben werden, sodass der Agent einer Storefront nie den Katalog oder Warenkorb einer anderen erreicht.

Messen #

Wenn Agent-Zugriff aktiv ist, zeigt das Dashboard Agent-Warenkörbe, Agent- Bestellungen, Agent-Umsatz (abzüglich Erstattungen) der letzten 30 Tage sowie den Top-Agenten nach Bestellanzahl — damit du die erste Frage beantworten kannst, die jede und jeder zu Agent-Commerce stellt: Verkauft es etwas?

Vergleich mit Shopify #

Shopify hat sein Storefront-MCP zugunsten des Universal Commerce Protocol eingestellt, dessen Agent-Checkout eine partner-exklusive Vorschau ist. STOAR liefert die vollständige käuferseitige Oberfläche heute und ergänzt mehrere Dinge, für die UCP keine Entsprechung hat:

• get_store_info — sonst raten Agenten Lieferziele, Zahlarten und die Rückgabefrist.
• estimate_shipping — ein Lieferpreis aus dem echten Checkout-Rechner, kein bloßer Zwischenbetrag.
• Gast-Bestellabfrage — Shopifys ist nur für Angemeldete, Gastbestellungen (ein großer Teil des realen Verkehrs) gehen leer aus.
• Gezielte Warenkorb-Änderungen statt eines vollersetzenden update_cart, das jede Position stillschweigend löscht, die der Agent zu wiederholen vergisst.
• Idempotenz bei jeder Mutation, nicht nur beim Abbrechen.
• Lieferbare Alternativen, wenn ein Artikel vergriffen ist.

Aktuelle Grenzen #

• Keine Rückgaben, Stornierungen oder Adressänderungen über MCP. Diese sind unumkehrbar und gehören hinter eine ausdrückliche menschliche Bestätigung, die der Transport noch nicht garantieren kann; Agenten verweisen die Kundschaft auf die Kontoseite.
• Bundles und Abos sind lesbar, aber nicht über einen Agenten kaufbar — beide sind gekennzeichnet, sodass der Agent die Kundschaft auf die Produktseite leitet, statt das Falsche zum falschen Preis hinzuzufügen.
• Der Bestellstatus wird vom Händler gepflegt — eine Sendungsnummer pro Bestellung, ohne Live-Carrier-Anbindung, und der Statushinweis ist als möglicherweise veraltet gekennzeichnet.
• Richtlinieninhalte folgen den übersetzten Storefront-Seiten, eine Änderung erfordert also einen Deploy statt einer Bearbeitung im Manager.

Siehe auch #

• REST-API-Adapter — die Magento-, Shopify-, WooCommerce- und BigCommerce-Fassaden über demselben Kern
• Warenkorb & Checkout — der Storefront-Warenkorb, in den ein Agent übergibt
• KI-Einkaufsassistent — der In-Store-Chat, der Kundschaft direkt antwortet, das Gegenstück zu dieser agentenseitigen Oberfläche