MCP dla e-commerce: jak AI bezpiecznie używa narzędzi Store

Model Context Protocol daje zgodnemu klientowi standard odkrywania nazwanych tools, czytania ograniczonych resources i wywołania serwera ze strukturalnymi argumentami. Sam nie zabezpiecza Store, nie autoryzuje płatności i nie zastępuje checkout. Serwer MCP identyfikuje aktora, waliduje input, stosuje policy produktu i Store oraz zwraca typowany wynik. Model jest klientem proszącym o capability, nie właścicielem stanu commerce.

Publikuj wąskie akcje: search_catalog, get_product, create_cart_draft, request_checkout, get_order_status albo draft_catalog_update. Nie wystawiaj surowych queries, dowolnego HTTP, provider secrets ani ogólnego execute. Każdy tool wymaga schemas, Store scope, risk class, idempotency rule, timeout i jasnego failure. Resources mogą wyjaśniać policy i katalog, lecz niezaufany tekst nie daje tool ani nie osłabia kontroli.

Buyer tools i creator-management tools należą do odrębnych powierzchni władzy. Kupujący może szukać, porównywać, przygotować cart jednego Store, rozpocząć dozwolony checkout lub sprawdzić własne zamówienie. Owner przegląda drafts, inventory alerts, discounts, orders i reconciliation tylko z dokładnym grantem. Podłączony Agent dostaje wybrane capabilities i nigdy nie dziedziczy ownership, provider access ani tools innego Store.

Products, prices, sellable inventory, orders, payments, refunds, fulfillment, customers i consent pozostają w autorytatywnych services commerce. MCP tłumaczy typowane żądanie i raportuje zatwierdzony wynik; nie tworzy drugiej prawdy z rozmowy. Stosuj revision checks dla drafts i idempotency keys dla ponowień. Przy timeout provider zwróć unknown lub pending i wykonaj reconciliation zamiast zakładać sukces.

Użyj OAuth albo zweryfikowanej scoped identity, minimalnych praw, krótkich sessions, jawnego confirmation dla ważnych writes i niezmiennego auditu z aktorem. W wykonaniu sprawdź Store, identity, amount, currency, price revision, state i capability. Grants mają być odwoływalne; rozdziel read i write oraz fail closed dla stale, missing, cross-Store lub ambiguous tools. Confirmation nie zastępuje walidacji serwera.

Codex, ChatGPT, GitHub Copilot i inni klienci różnią się transportem, authentication, discovery, approvals i kontrolami admin, więc sprawdź dokładny client i plan. Zacznij od read-only katalogu lub order status, potem odwracalnej draft action, i testuj invalid, duplicate, stale, cross-account, timeout oraz revoked access. Prostir Store jest Preview z jednym commerce root, autoryzowanym istniejącym Agentem i https://{slug}.store.prostir.build/mcp; sprawdź fit przed zastąpieniem stabilnego procesu.