Под MCP Ozon здесь понимаем проект внутреннего MCP-сервера поверх Seller API: агент может получать разрешённые данные кабинета, а запись цены или остатков предлагаем проводить только после отдельного подтверждения человеком. Здесь разбираем внутренний инструмент для команды продавца — чат-боты покупателям и общая автоматизация кабинета живут в соседних материалах. Контур работает, когда список операций и границы подтверждений описаны заранее.
Чем отличается от бота
Проверка инструмента строится на коротком сценарии продавца: сводка по продажам, ответ на вопрос из данных кабинета, изменение цены. По итогам смотрим четыре признака: точность чтения, честность при нехватке данных, соблюдение границ записи и корректное подтверждение опасных действий.
Чат-бот покупателям разговаривает с внешней аудиторией и отвечает на вопросы по базе знаний. Инструмент MCP для Ozon — внутренняя штука: он работает с данными кабинета продавца и живёт в контуре вашего агента, и остаётся вне клиентского канала. Агент через него смотрит остатки, собирает сводки, готовит изменения — а команда продавца подтверждает запись.
Общая автоматизация работы с кабинетом разобрана в статье про работу с Ozon через нейросеть, а процесс управления ценами — в материале про ИИ для цен на Ozon. Здесь фокус узкий: один MCP-инструмент с жёстким разделением чтения и записи, допусками и подтверждениями.
- Чтение: остатки, заказы, аналитика — без подтверждения.
- Запись: цены, остатки — только через подтверждение.
- Журнал: каждый вызов с параметрами и результатом.
- Границы: список операций, разрешённых агенту.
Сценарий продавца выбран неслучайно: он короткий, предметный и бьёт по слабым местам инструмента. Сводка по продажам проверяет точность чтения аналитики, ответ из данных кабинета — честность при нехватке информации, изменение цены — соблюдение границ записи. Эти прогоны позволяют проверить границы инструмента на конкретных данных.
Перед стартом фиксируем дату сборки инструмента: описания операций, границы и подтверждения обновляются, и пилот привязывается к конкретному снимку конфигурации. Описания, сценарии и журналы прогонов складываются в одну папку — архив помогает объяснить расхождения между версиями без поиска в переписке.
Состав инструмента
Инструмент собирается как MCP-сервер с обёрткой над API кабинета продавца. Агент видит описание операций — название, назначение, параметры — и вызывает ровно разрешённое. Ключи доступа к кабинету хранятся на сервере инструмента; до агента доходит лишь описание операций, а возможность записи ограничивает сервер и процедура подтверждения.
Описание операций держат в формате, понятном агенту: что делает операция, какие параметры принимает, какие границы действия. Общие правила таких описаний разобраны в материале про описание инструментов MCP — здесь требование одной фразой: чем точнее границы, тем реже агент ошибается с выбором.
- Название и назначение: что операция делает в терминах кабинета.
- Параметры: допустимые значения и форматы.
- Границы: диапазоны, внутри которых операция разрешена.
- Подтверждение: нужно оно или операция чтения.
Ключ доступа к кабинету живёт по правилу минимума: отдельный ключ инструмента, права ровно под список операций, хранение в защищённом хранилище сервера. При подозрении на компрометацию инженер отзывает один ключ, а доступ команды к кабинету остаётся нетронутым. При ротации обновляют секрет в хранилище и проверяют, что соединение и права по-прежнему работают.
Порядок сборки
- Создайте ключ доступа. Отдельный ключ кабинета с минимальными правами — ровно под список операций инструмента.
- Опишите операции чтения. Остатки, заказы, аналитика — каждая с параметрами и границами.
- Опишите операции записи. Цены и остатки — с жёсткими диапазонами и обязательным подтверждением.
- Подключите подтверждения. Изменения уходят ответственному в чат и ждут кнопку.
- Заведите журнал. Каждый вызов: операция, параметры, результат, кто подтвердил.
- Прогоните сценарии. Сводка, вопрос из данных, изменение цены — на ограниченном списке товаров.
Пилот подаём как предложение: один кабинет, три сценария и чек-лист. Если сценарии проходят — расширяем список операций по одной за прогон; если агент путается — смотрим, где правится описание операции, а где меняются границы. Такой порядок держит изменения маленькими и обратимыми: каждый шаг легко откатить, пока журнал короткий и картина свежая.
Короткий список операций проще проверить и поддерживать при изменениях Seller API.
Три сценария прогона покрывают главные риски инструмента. Сводка проверяет чтение: цифры в ответе совпадают с кабинетом, источник назван. Вопрос из данных проверяет честность: на отсутствующий показатель агент обязан ответить о нехватке данных, а выдуманная цифра здесь — брак. Изменение цены проверяет допуски: агент предлагает новую цену внутри лимита и останавливается, дожидаясь кнопки ответственного.
Какие операции кабинета ваш агент запросит первыми?
Дорожки доступа
| Операция | Допуск | Подтверждение |
|---|---|---|
| Сводка по продажам | Чтение аналитики | Без подтверждения |
| Остатки по складу | Чтение остатков | Без подтверждения |
| Изменение цены | Запись в диапазоне лимита | Кнопка у ответственного |
| Массовое изменение | Запись по списку товаров | Двойное подтверждение |
Чтение и запись идут разными дорожками: чтение включают после проверки прав доступа и состава данных, а запись всегда проходит подтверждение. Допуски к операциям проверяет сервер инструмента — агент видит описание, а границы диапазонов и лимиты держит конфигурация сервера, поэтому ограничения должны действовать независимо от промпта.
Агент предлагает цену — человек ставит её. Инструмент, который пишет в кабинет без подписи владельца, остаётся за порогом. правило предлагаемого пилота
В предлагаемом регламенте изменение границ согласует владелец кабинета: отдельно проверяют новую операцию чтения и особенно тщательно — расширение диапазона записи. Каждое изменение уходит в журнал с датой и инициатором — по журналу видно, кто и когда расширил полномочия агента, это помогает восстановить историю разрешений.
Для массового изменения цен или остатков предлагаем двойное подтверждение. Второй ответственный проверяет список товаров, пределы изменения и комментарий первого; сам порядок согласования нужно закрепить в регламенте компании.
Тест и приёмка
Начните с операций чтения на одном кабинете: сводка продаж и остатки. Метрика первого этапа — доля ответов, принятых без правок. Типичная ошибка — разрешить запись сразу: цена, уехавшая мимо лимита, стоит дороже любой сводки.
Тест прогоняем на ограниченном списке товаров: сценарии чтения — сводка и ответ из данных, сценарий записи — изменение цены внутри лимита с подтверждением. Журнал показывает цепочку: запрос агента, параметры, подтверждение, результат в кабинете. Каждый сценарий закрывается отметкой в чек-листе до боевого доступа.
Границы проверяют на фиктивных запросах до боевого запуска: агент просит цену ниже лимита, выше лимита и ровно на границе. Запросы вне разрешённого диапазона сервер отклоняет; значение ровно на границе принимают, если оно включено в правило. Ожидаемый результат для каждого случая заранее фиксируют в чек-листе.
Экономика контура складывается из времени инженера на обвязку и расхода токенов модели. Условия оплаты модели сверяйте на странице вендора; расход зависит от объёма данных, частоты запросов и длины ответов. Регулярный контур «агент → инструмент → подтверждение → журнал» под ваш кабинет можно отдать на поддержку: логику цены и состав работ описываем на странице про ИИ-агентов для бизнеса.
Раз в месяц журнал разбирают с владельцем кабинета: какие операции просили чаще, где агент ошибался, какие границы уточнить. Такой разбор держит инструмент живым: список чтения растёт по факту потребности, а подтверждения ужесточаются там, где агент ошибался.
Метрики пилота смотрим парой: доля ответов, принятых без правок, и доля подтверждений, после которых изменение отменили. Первая показывает точность агента, вторая — качество его предложений на границе. Рост первой при росте второй — сигнал сузить диапазоны записи и вернуть спорные операции на двойное подтверждение.