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

Das Model Context Protocol gibt einem kompatiblen Client einen Standard, benannte Werkzeuge 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 Kaufabschluss. 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, Anbieter-Secrets oder generisches execute. Jedes Werkzeug braucht Input- und Output-Datenschema, Store-Umfang, Risikoklasse, Idempotenz, Zeitüberschreitung und klares Fehlerresultat. Ressourcen erklären Policy und Katalog, doch unvertrauenswürdiger Text darf weder Werkzeuge gewähren noch Kontrollen schwächen.

Käufer-Werkzeuge und Creator-Management-Werkzeuge gehören zu getrennten Berechtigungsflächen. Käufer dürfen suchen, vergleichen, einen Warenkorb für einen Store vorbereiten, erlaubten Kaufabschluss starten oder den eigenen Bestellstatus lesen. Verantwortlicher bearbeiten Entwürfe, 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, Anbieter-Zugriff noch Werkzeuge 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 Prüfungen für Entwürfe und Idempotency Keys bei Wiederholungen. Nach Anbieter-Zeitüberschreitung 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 Prüfung mit Akteur. Prüfen Sie bei Ausführung Store, Identität, Betrag, Währung, Preisrevision, Zustand und Fähigkeit. Grants müssen widerrufbar sein; trennen Sie Lesen und write und scheitern Sie geschlossen bei veraltet, fehlenden, cross-Store oder mehrdeutigen Werkzeuge. 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 Lesen-only Katalog oder Bestellstatus, danach einer reversiblen Entwurf-Aktion, und testen Sie invalid, duplicate, veraltet, kontoübergreifend, Zeitüberschreitung und revoked Zugriff. Prostir Store ist Vorschau 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.