MCP für E-Commerce: So nutzt KI Store-Tools sicher

Das Model Context Protocol gibt einem kompatiblen Client einen Standard, benannte Tools zu entdecken, begrenzte Ressourcen zu lesen und einen Server mit strukturierten Argumenten aufzurufen. Es macht einen Store nicht automatisch sicher, autorisiert keine Zahlung und ersetzt keinen Checkout. Der MCP-Server identifiziert den Akteur, validiert jede Eingabe, wendet Produkt- und Store-Regeln an und liefert ein typisiertes Ergebnis. Das Modell ist Client einer Fähigkeit, nicht Besitzer des Commerce-Zustands.

Veröffentlichen Sie enge Aktionen wie search_catalog, get_product, create_cart_draft, request_checkout, get_order_status oder draft_catalog_update. Keine rohen Datenbankabfragen, beliebiges HTTP, Provider-Secrets oder generisches execute. Jedes Tool braucht Input- und Output-Schema, Store-Scope, Risikoklasse, Idempotenz, Timeout und klares Fehlerresultat. Ressourcen erklären Policy und Katalog, doch unvertrauenswürdiger Text darf weder Tools gewähren noch Kontrollen schwächen.

Käufer-Tools und Creator-Management-Tools gehören zu getrennten Berechtigungsflächen. Käufer dürfen suchen, vergleichen, einen Warenkorb für einen Store vorbereiten, erlaubten Checkout starten oder den eigenen Bestellstatus lesen. Owner bearbeiten Drafts, Bestandsalarme, Rabatte, Bestellungen und Reconciliation nur mit dem exakten Grant. Ein verbundener Agent erhält nur ausgewählte Store-Fähigkeiten und erbt weder Ownership, Provider-Zugriff noch Tools eines anderen Store.

Produkte, Preise, verkaufbarer Bestand, Bestellungen, Zahlungen, Erstattungen, Fulfillment, Kunden und Consent bleiben in autoritativen Commerce-Services. MCP übersetzt eine typisierte Anfrage und meldet das gespeicherte Ergebnis; es erzeugt keine zweite Wahrheit aus dem Gespräch. Nutzen Sie Revision Checks für Drafts und Idempotency Keys bei Wiederholungen. Nach Provider-Timeout gilt unknown oder pending mit Reconciliation, nicht angenommener Erfolg.

Nutzen Sie OAuth oder verifizierte scoped Identity, geringste Rechte, kurze Sessions, explizite Bestätigung wichtiger Writes und unveränderliches Audit mit Akteur. Prüfen Sie bei Ausführung Store, Identität, Betrag, Währung, Preisrevision, Zustand und Capability. Grants müssen widerrufbar sein; trennen Sie read und write und scheitern Sie geschlossen bei stale, fehlenden, cross-Store oder mehrdeutigen Tools. Bestätigung ersetzt keine Servervalidierung.

Codex, ChatGPT, GitHub Copilot und andere Clients unterscheiden sich bei Transport, Authentifizierung, Discovery, Approvals und Admin-Kontrollen. Prüfen Sie konkreten Client und Plan. Starten Sie mit read-only Katalog oder Bestellstatus, danach einer reversiblen Draft-Aktion, und testen Sie invalid, duplicate, stale, cross-account, timeout und revoked access. Prostir Store ist Preview mit einem Commerce-Root, autorisiertem bestehendem Agent und https://{slug}.store.prostir.build/mcp; prüfen Sie den Fit vor dem Austausch stabiler Abläufe.