Покупатель спрашивает «есть ли этот размер на складе и когда приедет мой заказ» — и ждёт ответа, пока менеджер открывает выгрузку остатков, сделанную утром. Данные уже устарели. Подключение AI-агента к PIM, складу и системе заказов через MCP-серверы убирает этот разрыв: агент отвечает по наличию, ценам и статусам на живых данных, без ручных выгрузок.
Это открытый разбор практики на базе публичных материалов вендоров, а не кейс KT.Team. Ниже — что именно стало возможным на инструменте MCP в e-commerce и ритейле, со ссылками на источники.
Что такое MCP и зачем он рознице
Model Context Protocol — открытый стандарт (изначально его выпустила Anthropic в ноябре 2024), который описывает, как AI-агент обнаруживает и вызывает «инструменты» — функции с предсказуемой схемой — у внешних систем. Для агента это единый адаптер: вместо десятка самописных интеграций он работает с одним контрактом.
Для ритейла ключевой результат — ответ на живых данных. MCP-сервер выставляет конкретные инструменты («проверить наличие», «получить цену», «узнать статус заказа»), а агент по запросу читает реальное состояние систем, а не статичный текст с сайта или вчерашний CSV.
Каталог, цена, остатки и заказы через один слой
commercetools представила Commerce MCP, который выставляет ключевые API платформы в формате, потребляемом агентами: корзины, каталоги, цены, промо, инвентарь и заказы (commercetools). В прототипах вендора показаны три сценария: shopping-агент, использующий наличие и цены в реальном времени для подбора; developer-copilot; и агент клиентской поддержки, который читает живые данные заказа, чтобы оформить возврат или решить проблему.
Shopify в своём MCP-сервере выставляет каталог, остатки и заказы с инструментами вроде `check_stock` (проверка наличия), `search catalog`, `create_cart`, `apply_discount`. Метаданные отдаются как «inference-ready» — подготовленными под обработку моделью; покупатель в чате может проверить реальные остатки и узнать статус заказа без участия человека (PrestaScan).
Logicbroker применяет MCP к дроп-шип и фулфилменту: сервер даёт инструменты проверки наличия, размещения заказа, обновления цен и «интеллектуальной маршрутизации» — связки каталога, заказов и партнёрского фулфилмента. Данные превращаются в «машиночитаемые схемы», которые агент запрашивает в реальном времени, а не парсит со страниц (Logicbroker).
Почему PIM первичен, а не MCP
Важный и недооценённый вывод — от inriver. MCP стандартизирует доступ агента к системам и действиям, но «ни один протокол не определяет product information, от которой эти действия зависят» (inriver). То есть MCP даёт механизм, а полезность ответа определяет качество и структура данных в PIM.
inriver перечисляет, что должно быть в PIM, чтобы агент отвечал точно: структурированные модели товара (агент понимает, какой именно товар и как варианты связаны с наличием), нормализованные данные (меньше неоднозначности), API-first доступ. Практический смысл для бизнеса: фрагментированные данные о товаре в разных системах подрывают работу агента. Консолидация в PIM с governance должна предшествать запуску агентских сценариев по каталогу и остаткам — иначе агент будет уверенно отвечать неверно, и потребуется ручная правка.
Это совпадает с инженерным принципом «минимальная модификация ядра инструмента»: MCP-сервер ставится рядом с PIM/WMS/OMS как тонкий слой контрактов, не переписывая и не форкая сами системы. Бизнес-логика живёт в отдельных сервисах-инструментах, источники остаются отчуждаемыми и заменяемыми.
Governance: без него агенту нельзя давать заказы
Все источники сходятся: доступ к чувствительным операциям должен быть за строгим governance. Logicbroker описывает role-based access control, аудит-лог всех транзакций и whitelisting инструментов, чтобы исключить неавторизованные операции. commercetools называет это «governed execution»: администратор управляет тем, какие инструменты выставлены и в каком объёме. Shopify разделяет Storefront MCP (для покупателя — поиск, оформление) и Dev MCP (внутренняя конфигурация), давая внешним недоверенным агентам ограниченные права.
Практический водораздел: чтение (наличие, цена, статус заказа) можно открывать широко — это и есть главный быстрый выигрыш; запись (оформление, возврат, изменение корзины) — только за авторизацией и аудитом. Это применение зрелого международного стандарта вместо самописной «интеграции с правами на всё».
Какой бизнес-результат
- Ответы клиенту и менеджеру на актуальных данных вместо суточных выгрузок — снимается риск продать то, чего нет, и обещаний по несуществующим срокам.
- Поддержка читает живой статус заказа и инициирует возврат прямо в диалоге, а не «по скрипту».
- Один контракт MCP вместо набора точечных интеграций под каждый канал и каждого внешнего агента.
Что менять в бизнес-процессе
Раньше: менеджер выгружает остатки и статусы в Excel раз в сутки, отвечает с задержкой и риском устаревших данных. Становится: агент по запросу читает наличие, цену и статус напрямую из PIM, WMS и OMS через MCP-инструменты и отвечает на живых данных, а запись-операции проходят через RBAC и аудит. Узкое место смещается с интеграций на две вещи — качество и структуру данных в PIM и governance доступа к инструментам. Сначала наводится порядок в PIM, затем выставляются read-инструменты, и только потом — строго ограниченная запись.
