MCP простыми словами: как подключить AI к API, таблицам и маркетплейсам

Коротко

MCP (Model Context Protocol) — открытый стандарт, по которому AI-модель подключается к внешним инструментам: API, базам данных, таблицам, CRM, кабинетам маркетплейсов. Модель через MCP не просто получает текст, а может *вызывать функции* — прочитать заявку, найти строку в таблице, создать задачу, узнать остаток товара.

Раньше под каждую связку «модель ↔ сервис» писали свой костыль. MCP превращает это в набор одинаково устроенных «розеток»: один раз описали инструмент — и его может использовать любой совместимый агент.

Для бизнеса это значит одно: AI перестаёт быть болталкой в отдельном окне и начинает работать внутри ваших процессов — с логами, правами доступа и человеком, который подтверждает важные действия.

Проблема: модель умная, но слепая и безрукая

Представьте типичный запрос менеджера маркетплейса: «Проверь, по каким SKU остаток меньше 10 штук, и предложи, что пополнить».

Обычная модель ответит красиво и бесполезно — она не видит ваш склад. Дальше два сценария.

Сценарий 1: копипаст. Человек выгружает отчёт из кабинета, вставляет в чат, получает ответ, переносит его обратно. На один вопрос — пять ручных действий. Это не экономит время, а перекладывает его.

Сценарий 2: интеграция «в лоб». Разработчик пишет отдельный код: сходить в API Ozon, распарсить ответ, отдать модели, забрать результат, положить в таблицу. Работает — ровно до момента, когда вы захотите подключить второй сервис. Тогда всё пишется заново. Через полгода у вас десяток несовместимых скриптов, каждый ломается по-своему, и никто не помнит, где что лежит.

MCP решает вторую проблему. Он задаёт единый формат: как инструмент себя описывает, как модель его вызывает, как возвращается результат. Подключение нового сервиса перестаёт быть отдельным проектом.

Как это устроено: три роли

Чтобы не тонуть в терминах, держите в голове три части.

Хост — приложение, где живёт модель. Это может быть Claude Desktop, ваш AI-агент, бот в Telegram, внутренняя панель.

MCP-сервер — прослойка перед конкретным инструментом. Один сервер для Google Sheets, другой для CRM, третий для API Wildberries. Сервер объявляет: «я умею вот эти действия — читать строки, добавлять запись, искать по фильтру».

Модель — через хост видит список доступных инструментов и сама решает, какой вызвать под задачу.

Диалог получается такой. Пользователь: «Сколько заявок пришло за сегодня?» Модель понимает, что ответа в её памяти нет, но есть инструмент crm.get_leads. Она вызывает его с параметром «дата = сегодня», сервер идёт в CRM, возвращает 14 строк. Модель формулирует человеческий ответ: «14 заявок, из них 9 с сайта, 5 из Telegram».

Ключевое отличие от «просто API»: модель не запрограммирована жёстко под один сценарий. Ей дали набор инструментов и она комбинирует их под конкретный вопрос. Один и тот же MCP-сервер CRM обслуживает и «сколько заявок», и «найди клиента по телефону», и «переведи сделку на этап оплаты» — без нового кода под каждый вопрос.

Workflow: как это выглядит на реальных задачах

Абстракции — потом. Вот три связки, которые мы собирали для клиентов.

Заявки и таблицы

У небольшого сервиса заявки падают в Telegram, в почту и через форму на сайте. Раньше администратор вручную сводил их в Google-таблицу.

Собрали агента с двумя MCP-серверами: один читает входящие сообщения, второй пишет в таблицу. Агент разбирает заявку («хочу записаться, вторник, стрижка»), нормализует в поля (услуга, дата, контакт) и добавляет строку. Спорные случаи — где не хватает данных или дата неоднозначна — он не додумывает, а помечает флагом «нужна проверка» и отдаёт человеку.

Это важный момент: MCP даёт доступ, но не отменяет здравый смысл. Записать чистую заявку агент может сам. Отменить чужую бронь — только с подтверждением.

CRM и квалификация лидов

Лид пишет в Telegram. Агент через MCP-сервер CRM находит, есть ли уже такой контакт, поднимает историю, задаёт два-три уточняющих вопроса и ставит предварительный статус: «горячий / тёплый / не наш профиль». Менеджеру утром приходит не 40 сырых диалогов, а список с пометками и черновиками ответов.

Продавать и закрывать сделку по-прежнему человек. Агент снимает рутину первого касания — ту самую, на которую уходит половина дня и вся энергия.

Подробнее логику агентов мы разбирали в статье AI-агент для бизнеса — MCP здесь ровно тот механизм, которым агент дотягивается до систем.

Маркетплейсы: WB и Ozon

Самая частая просьба от селлеров — «сделайте, чтобы отвечало на отзывы и следило за остатками».

MCP-сервер над API кабинета даёт агенту доступ к отзывам, вопросам, остаткам, ценам. Дальше всё зависит от того, что вы разрешаете.

Читать и анализировать — безопасно: агент раз в час проверяет остатки, находит SKU на нуле, готовит сводку. Отвечать на отзывы — уже требует рамок: благодарность за «5 звёзд, всё супер» агент отправит сам, а на жалобу «пришёл брак» — подготовит черновик и позовёт человека. Менять цену или запускать рекламный бюджет без подтверждения не должен вообще никто, кроме вас.

MCP тут — не про то, чтобы отдать кабинет роботу. Он про то, чтобы аккуратно разложить действия на «можно автоматом», «можно с подтверждением» и «только руками».

ROI: где реально экономит время

Считать надо не в «вау-эффекте», а в часах.

Сведение данных. Заявки, отзывы, статусы, которые кто-то переносил руками между системами. Тут экономия прямая: 1–2 часа в день администратора превращаются в фоновую задачу агента. Окупается быстрее всего, потому что процесс повторяется каждый день.

Первичная обработка. Квалификация лидов, разбор входящих, черновики ответов. Экономия не в том, что человек исчезает, а в том, что он начинает с готового черновика, а не с чистого листа. По нашим замерам это 30–50% времени на типовых ответах.

Мониторинг. Остатки, цены конкурентов, новые отзывы. Человек физически не может проверять кабинет каждый час — агент может. Экономия здесь не в часах, а в упущенной выгоде: товар не завис в «нет в наличии» три дня.

Где ROI сомнительный — там, где процесс редкий, нестандартный или цена ошибки высокая. Автоматизировать раз в месяц отчёт, который делается за 20 минут, дороже, чем оставить как есть. Как отличить одно от другого, мы разбирали в тексте как понять, что процесс пора автоматизировать.

Риски: где MCP кусается

Дать модели руки — значит дать ей возможность что-то испортить. Честный разговор про риски.

Слишком широкие права. Если MCP-сервер CRM умеет всё — читать, менять, удалять — то и модель умеет всё. Первое правило: сервер отдаёт ровно те действия, что нужны задаче. Агенту для сводки по заявкам не нужен доступ на удаление сделок. Урезайте права на уровне сервера, а не надеждой на то, что модель «не додумается».

Действия без подтверждения. Всё, что необратимо или стоит денег — отправка клиенту, смена цены, возврат, рассылка — должно проходить через human-in-the-loop. Агент готовит, человек нажимает. Это не признак незрелости системы, это её правильная архитектура.

Отсутствие логов. Если вы не видите, какой инструмент агент вызвал и с какими параметрами, вы не управляете системой, а верите ей. Каждое действие через MCP должно логироваться: что вызвано, когда, с какими данными, что вернулось. При разборе «почему клиенту ушло не то» логи — единственный способ понять причину.

Данные и доступы. MCP-сервер держит ключи к вашей CRM и кабинету маркетплейса. Это чувствительный узел. Токены — в защищённом хранилище, а не в коде; доступ — по принципу минимальных прав; отдельный контур для того, что касается денег и персональных данных.

Галлюцинации в вызовах. Модель может вызвать инструмент с кривыми параметрами — например, придумать несуществующий SKU. Поэтому сервер валидирует вход: если товара нет, он возвращает честную ошибку, а не делает вид. Проверка на стороне инструмента, а не на доверии к модели.

Внедрение: с чего начать

Не начинайте с «подключим AI ко всему». Так вы получите хрупкую систему, в которой страшно что-то трогать.

Шаг 1. Выберите один процесс. Частый, повторяемый, с понятным результатом и низкой ценой ошибки. Сведение заявок в таблицу — хороший первый кандидат. Автоматическая смена цен на WB — плохой.

Шаг 2. Опишите инструменты, а не мечты. Что конкретно агент должен уметь: «прочитать входящие», «добавить строку», «найти контакт». Каждый пункт — это будущее действие MCP-сервера. Если пункт нельзя описать одним глаголом и понятными параметрами — он ещё сырой.

Шаг 3. Разделите действия по уровню риска. Три корзины: «автоматом», «с подтверждением», «только человек». Это разделение важнее выбора модели.

Шаг 4. Подключите один сервер, проверьте на реальных данных. Не на идеальных примерах, а на настоящем потоке заявок с опечатками и странными формулировками. Именно там всплывает всё интересное.

Шаг 5. Включите логи и подтверждения с первого дня. Не «потом добавим». Наблюдаемость системы закладывается сразу, иначе её не докрутишь.

Шаг 6. Расширяйтесь по одному инструменту. Работает связка «заявки → таблица» — добавляйте CRM. Работает CRM — добавляйте Telegram-уведомления. Каждый новый MCP-сервер подключается к тому же агенту, и в этом весь смысл стандарта: рост без переписывания.

По технике MCP-серверы бывают готовые (для популярных сервисов вроде Google Sheets, Slack, GitHub уже есть открытые реализации) и кастомные — под ваш API, самописную CRM, специфику кабинета WB/Ozon. Для стандартных инструментов берите готовое, для вашей уникальной логики нужен свой сервер. Второе — как раз то, что мы в Paramiko делаем чаще всего: у большинства бизнесов процессы не укладываются в коробочные коннекторы.

FAQ

Чем MCP отличается от обычного API-подключения? API вы вызываете жёстко запрограммированным кодом под конкретный сценарий. MCP описывает инструмент так, что модель сама решает, когда и с какими параметрами его вызвать. Один MCP-сервер обслуживает много разных запросов без нового кода под каждый.

MCP — это отдельная нейросеть? Нет. Это протокол, стандарт связи. Модель остаётся любой (Claude, другая LLM), а MCP — «розетка», через которую она дотягивается до ваших инструментов. Саму модель он не заменяет и не улучшает — он даёт ей доступ к данным и действиям.

Можно ли подключить AI к Wildberries и Ozon через MCP? Да, через MCP-сервер над API кабинета. Читать остатки, отзывы, вопросы — безопасно автоматизировать. Отвечать на отзывы — с подтверждением на спорных. Менять цены и рекламу — только с явным контролем человека. MCP тут помогает аккуратно разделить, что можно автоматом, а что нет.

Это безопасно? AI получит доступ к моей CRM. Безопасность зависит от настройки, а не от протокола. Правильно — урезать права сервера до необходимого минимума, держать необратимые действия за подтверждением человека, логировать каждый вызов, хранить токены в защищённом контуре. Если это сделано, доступ контролируем и прозрачен.

Нужен ли программист, чтобы всё это подключить? Для готовых коннекторов (таблицы, мессенджеры, популярные сервисы) — минимально. Для вашего собственного API, самописной CRM или нестандартной логики маркетплейса нужен кастомный MCP-сервер, а значит — разработка. Обычно с этого и начинается реальный проект.

С чего начать, если процессов много? С одного — частого, повторяемого, с низкой ценой ошибки. Автоматизируйте его целиком, с логами и подтверждениями, доведите до стабильности, и только потом подключайте следующий инструмент к тому же агенту.

Что дальше

MCP — не волшебная кнопка, а способ навести порядок: дать модели доступ к вашим системам через понятные, ограниченные и наблюдаемые «розетки». Ценность не в том, что AI начнёт всё делать сам, а в том, что рутина уходит агенту, а решения и контроль остаются у вас.

Если хотите понять, что стоит автоматизировать именно у вас и где MCP реально даст экономию, а где будет лишним — напишите Дмитрию в Telegram @dmkosik или опишите свой процесс для короткой диагностики Paramiko. Без обязательств: сначала разберём, есть ли там что автоматизировать, а потом — как.