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

Модель Контекст Протокол дає сумісному клієнту стандартний спосіб знаходити іменовані інструменти, читати обмежені ресурси і викликати сервер зі структурованими аргументами. Сам по собі він не робить Store безпечним, не авторизує платіж і не замінює оформлення замовлення протокол. MCP-сервер усе одно ідентифікує виконавця, перевіряє кожне поле, застосовує правила продукту та Store і повертає типізований результат. Модель — клієнт, який просить можливість, а не власник комерція-стану.

Публікуйте вузькі бізнес-дії: search_catalog, get_product, create_cart_draft, request_checkout, get_order_status або draft_catalog_update. Не відкривайте сирі база даних запити, довільний HTTP, постачальник секрети чи універсальний виконати. Кожен інструмент потребує вхідні дані/результат схема, Store обсяг, ризик клас, ідемпотентність правило, тайм-аут і чіткого збій результат. Ресурси можуть пояснювати політика й каталог контекст, але недовірений текст не може видати інструмент або послабити перевірки.

Buyer інструменти та автор-керування інструменти належать різним контурам повноважень. Покупець може шукати, порівнювати, підготувати кошик одного Store, почати дозволений оформлення замовлення або прочитати статус власного замовлення. Власник працює з каталог чернетки, запаси сповіщення, знижки, замовлення і звірка лише з точною керування-надання доступу. Прикріплений Agent отримує тільки явно вибрані Store можливості і ніколи не успадковує відповідальність, платіж-постачальник доступ чи інструменти іншого Store.

Продукти, ціни, готовий до продажу запаси, замовлення, платежі, повернення коштів, виконання замовлення, клієнти і згода залишаються в авторитетних комерція сервіси. MCP-шар перекладає типізований запит у ці сервіси й повідомляє зафіксований результат; він не створює другу правду з розмови. Для змінний чернетки потрібні версія перевірки, для повторюваних наслідки — ідемпотентність ключі. Якщо постачальник відповів тайм-аут, повертайте невідомий або очікує і запускайте звірка, а не вигадуйте успіх.

Використовуйте OAuth або іншу перевірену обмежений обсягом ідентифікація, мінімальні дозволи, короткі сесії, явне підтвердження для наслідкових записи та незмінний аудит з виконавець авторство. Під час виконання перевіряйте Store id, ідентифікація покупця чи власника, сума, валюта, ціна версія, поточний стан і можливість. Дозволи мають відкликатися; читання і запис — бути розділеними; застарілий, відсутній, міжконтекстний-Store чи неоднозначний інструмент ідентифікація — відмовити закритий. Підтвердження не замінює серверну валідацію.

Codex, ChatGPT, GitHub Copilot та інші клієнти відрізняються транспорт, автентифікація, виявлення, затвердження і адміністрування засоби контролю, тому перевіряйте конкретний клієнт і план. Почніть із лише для читання каталогу або замовлення статус, потім додайте одну зворотний чернетка дія і протестуйте недійсний, дублікат, застарілий, між обліковими записами, тайм-аут та відкликаний доступ. Prostir Store має статус Попередній перегляд і проєктується навколо одного комерція основа, авторизованого наявного Agent та Store MCP кінцева точка https://{slug}.store.prostir.build/mcp; перевірте відповідність до заміни робочого платформа шлях.