MCP для e-commerce: як AI безпечно використовує інструменти Store

Model Context Protocol дає сумісному клієнту стандартний спосіб знаходити іменовані tools, читати обмежені resources і викликати сервер зі структурованими аргументами. Сам по собі він не робить Store безпечним, не авторизує платіж і не замінює checkout protocol. MCP-сервер усе одно ідентифікує виконавця, перевіряє кожне поле, застосовує правила продукту та Store і повертає типізований результат. Модель — клієнт, який просить можливість, а не власник commerce-стану.

Публікуйте вузькі бізнес-дії: search_catalog, get_product, create_cart_draft, request_checkout, get_order_status або draft_catalog_update. Не відкривайте сирі database queries, довільний HTTP, provider secrets чи універсальний execute. Кожен tool потребує input/output schema, Store scope, risk class, idempotency rule, timeout і чіткого failure result. Resources можуть пояснювати policy й catalog context, але недовірений текст не може видати tool або послабити перевірки.

Buyer tools та creator-management tools належать різним контурам повноважень. Покупець може шукати, порівнювати, підготувати cart одного Store, почати дозволений checkout або прочитати статус власного замовлення. Власник працює з catalog drafts, inventory alerts, discounts, orders і reconciliation лише з точною management-grant. Прикріплений Agent отримує тільки явно вибрані Store capabilities і ніколи не успадковує ownership, payment-provider access чи tools іншого Store.

Products, prices, sellable inventory, orders, payments, refunds, fulfillment, customers і consent залишаються в авторитетних commerce services. MCP-шар перекладає типізований запит у ці сервіси й повідомляє зафіксований результат; він не створює другу правду з розмови. Для mutable drafts потрібні revision checks, для повторюваних effects — idempotency keys. Якщо provider відповів timeout, повертайте unknown або pending і запускайте reconciliation, а не вигадуйте успіх.

Використовуйте OAuth або іншу перевірену scoped identity, мінімальні grants, короткі sessions, явне confirmation для наслідкових writes та незмінний audit з actor attribution. Під час виконання перевіряйте Store id, identity покупця чи власника, amount, currency, price revision, current state і capability. Grants мають відкликатися; read і write — бути розділеними; stale, missing, cross-Store чи ambiguous tool identity — fail closed. Confirmation не замінює серверну валідацію.

Codex, ChatGPT, GitHub Copilot та інші клієнти відрізняються transport, authentication, discovery, approval і admin controls, тому перевіряйте конкретний client і plan. Почніть із read-only каталогу або order status, потім додайте одну reversible draft action і протестуйте invalid, duplicate, stale, cross-account, timeout та revoked access. Prostir Store має статус Preview і проєктується навколо одного commerce root, авторизованого наявного Agent та Store MCP endpoint https://{slug}.store.prostir.build/mcp; перевірте fit до заміни робочого platform path.