MCP (Model Context Protocol) — это соглашение о том, как описать инструмент, чтобы модель могла им пользоваться. Инструмент здесь — любое действие в вашей системе: «получить статус заказа из 1С», «создать сделку в CRM», «посмотреть остаток на складе». Раньше каждое такое подключение писалось отдельно под конкретного агента; со стандартом описание пишется один раз и подходит любой поддерживающей модели.
Владельцу бизнеса из этого важны две вещи, и обе денежные. Первая: второй и третий агент подключаются к тем же системам почти бесплатно — работа не делается заново. Вторая, менее очевидная: описания инструментов становятся активом компании, а не собственностью подрядчика, и смена исполнителя перестаёт означать переписывание всех интеграций.
Дальше — что именно лежит в описании инструмента; как выглядела та же задача до стандарта; смета на трёх агентах и пяти системах; что из этого уже доступно в России на сентябрь 2026, а что придётся писать самому; чего MCP не решает и почему это важнее, чем кажется; и пять вопросов подрядчику, которые стоит задать до подписания договора.
Единый разъём вместо самодельного провода
Открытый протокол описания инструментов и источников данных для языковых моделей. MCP-сервер — небольшая программа-посредник, которая стоит перед вашей системой и публикует список доступных действий в стандартном виде: имя, назначение словами, параметры, формат ответа. Модель читает этот список и решает, какой инструмент вызвать; вызов идёт через сервер, а не напрямую в вашу базу.
Ключевое, что стоит понимать нетехническому читателю: самая важная часть описания — это текст, а не код. Модель выбирает инструмент по формулировке его назначения, поэтому фраза «вернуть текущий статус и плановую дату отгрузки по номеру заказа» работает, а «метод получения данных заказа» — нет. Пишет эту формулировку человек, понимающий процесс; ошибка здесь выглядит не как сбой, а как «агент почему-то не смотрит в 1С».
- 1Имя инструмента — короткое и однозначное: «получить_статус_заказа». Если в списке два похожих имени, модель будет путать их ровно так же, как новый сотрудник.
- 2Назначение словами — когда именно этот инструмент вызывать и когда не вызывать. Это единственное место, где вы объясняете модели границу применения, и на нём экономить нельзя.
- 3Параметры и их типы — номер заказа строкой, обязательный; период датами, необязательный. Здесь же указывается, что делать, если параметра нет: спросить у человека или отказаться.
- 4Что возвращается — перечень полей ответа: статус, плановая дата отгрузки, склад, признак предоплаты. Модель не должна получать всю карточку заказа, если для ответа хватает четырёх полей.
- 5Ограничения — только чтение или чтение и запись, лимит вызовов в минуту, роль, от имени которой идёт обращение. Это уже не про MCP, а про безопасность, но записывается рядом.
Схема из двух частей. Слева карточка «Описание инструмента» с пятью подписанными строками: «Имя: получить_статус_заказа», «Назначение: вернуть текущий статус и плановую дату отгрузки по номеру заказа», «Параметры: номер заказа — строка, обязательный», «Возвращает: статус, дата отгрузки, склад, признак предоплаты», «Ограничения: только чтение, 60 вызовов в минуту». Строка «Назначение» выделена и к ней ведёт выноска «по этому тексту модель решает, вызывать ли инструмент». Справа стрелка к блоку «MCP-сервер», от него стрелка к блоку «1С:УТ». Обратная стрелка подписана «четыре поля, а не вся карточка».
Само подключение одной системы — это не «настроить галочку», а понятный набор работ примерно на неделю. Полезно представлять его состав, чтобы читать смету и понимать, за что стоят строки.
- 1Инвентаризация действий
Выписываются конкретные действия, которые агенту нужны: обычно 5–9 на систему, а не «весь функционал 1С». Каждое лишнее действие — это и лишняя строка в смете, и лишний риск, поэтому список сокращают, а не расширяют.
- 2Выбор способа доступа
Смотрят, что уже есть: веб-сервисы, HTTP-сервисы, промежуточная база, регулярная выгрузка. MCP-сервер встаёт поверх существующего способа и не требует переделывать обмен, если он работает.
- 3Отдельная учётная запись с минимальными правами
В каждой системе заводится своя запись — не администратор и не учётка сотрудника. Права даются ровно под выписанные действия: если агент только смотрит статусы, права на изменение документов у него быть не должно.
- 4Описание инструментов
Формулировки назначения пишутся вместе с предметным специалистом, а не только инженером. Это самая недооценённая работа: от точности одной фразы зависит, будет ли модель вызывать инструмент вовремя.
- 5Тесты на три сценария
Правильный вызов, вызов без обязательного параметра и вызов при недоступной системе. Третий важнее всех: агент должен честно сказать «не смог посмотреть», а не придумать статус заказа.
- 6Журнал и лимит вызовов
Каждый вызов пишется с параметрами и результатом, на число вызовов в минуту ставится потолок. Это не часть стандарта, но без этого сервер нельзя выпускать в работу.
Как та же задача выглядела до стандарта
Возьмём типичную картину в компании на 140 человек: пять систем, к которым агенту нужен доступ, — 1С:УТ, amoCRM, складская система, сайт и телефония. Первый агент делает один подрядчик: он пишет пять коннекторов под свою архитектуру, свои форматы и свою логику ошибок. Через полгода другой отдел заказывает второго агента, возможно у другого исполнителя. Формально те же пять систем — но код первого подрядчика чужой, не документирован и написан под его агента. Пишутся ещё пять коннекторов.
У этой картины есть и обратная сторона, которую замечают уже в эксплуатации. Пять коннекторов первого подрядчика и пять коннекторов второго ходят в одну и ту же 1С, но ведут себя по-разному: у одного лимит вызовов есть, у другого нет; один пишет журнал, другой нет; один при недоступности базы честно отвечает «не смог», другой отдаёт пустой результат, и агент трактует его как «заказов нет». Разбирать такие расхождения приходится по одному, и стоит это дороже, чем разработка: инцидент воспроизводится редко, а виноватого между двумя подрядчиками искать не с кем.
Это не злой умысел и не непрофессионализм: до общего формата описания переиспользовать чужой коннектор действительно было дороже, чем написать свой. Общая механика интеграций и то, из чего складывается их цена, разобраны в материале про API и вебхуки простыми словами — MCP не отменяет ничего из описанного там, он добавляет сверху единый способ рассказать модели, что этот интерфейс умеет.
Две половины на одном листе, разделённые вертикальной чертой. Слева подпись «Самописные коннекторы»: три прямоугольника-агента слева, пять прямоугольников-систем справа (1С:УТ, amoCRM, склад, сайт, телефония), между ними пятнадцать тонких линий «каждый с каждым», клубок подписан «15 коннекторов, 750 000 ₽». Справа подпись «MCP»: три агента, вертикальная полоса из пяти блоков «MCP-серверы», пять систем; от агентов к полосе три линии, от полосы к системам пять линий, подпись «5 описаний плюс подключения, 455 000 ₽». Правая половина выделена тоном.
Что меняется в смете
Считаем на тех же пяти системах. Самописный коннектор к учётной системе с разбором ошибок и тестами стоит по рынку около 60 000 ₽; второй подрядчик делает то же самое чуть дешевле — 45 000 ₽, потому что задача уже понятна, но код всё равно пишется заново. MCP-сервер стоит дороже одиночного коннектора — 75 000 ₽: к той же работе добавляются описания инструментов, схема параметров и тесты на вызовы. Зато подключение следующего агента к готовому серверу — это 8 000 ₽ и несколько часов.
Двухосевой график с нарастающим итогом. Ось X — три отметки: «Агент 1», «Агент 2», «Агент 3». Ось Y — рубли от 0 до 800 000. Сплошная линия «Самописные коннекторы» проходит через точки 300 000, 525 000, 750 000. Штриховая линия «MCP-серверы» — через 375 000, 415 000, 455 000. Точка пересечения между первым и вторым агентом выделена и подписана «здесь стандарт окупается». Вертикальная скобка справа между линиями подписана «разница 295 000 ₽». Внизу сноска «пять систем: 1С:УТ, amoCRM, склад, сайт, телефония».
Из графика видно главное: на одном-единственном агенте стандарт не окупается. Если у вас один сценарий и другого не планируется, честный ответ — обычный коннектор дешевле на 75 000 ₽. Стандарт покупают под второй и третий сценарий, и вопрос «есть ли они на горизонте года» надо задать себе до, а не после.
Есть и вторая, не считаемая в рублях выгода — та, ради которой это стоит делать даже на одном агенте. Описание инструмента лежит в вашем репозитории и написано в открытом формате, поэтому при смене подрядчика переписывается агент, а не интеграции. В обычной схеме при расставании переписывается всё, и это 60–80 % бюджета проекта заново. Что ещё стоит зафиксировать по доступам и исходникам, разобрано в материале про доступы подрядчику при внедрении.
Что из этого доступно в России на сентябрь 2026
Экосистема вокруг стандарта в России складывается, но говорить о готовом каталоге подключений пока рано. Что есть по состоянию на сентябрь 2026 и чего нет — по порядку.
| Что | Состояние | Что это значит для проекта |
|---|---|---|
| MCP Hub в составе Yandex AI Studio | Работает, рядом с конструктором агентов Agent Atelier, Vector Store и AI Search | Подключения собираются в интерфейсе платформы; удобно, если агент строится там же |
| Корпоративные платформы агентов | GigaChat Enterprise развивается в вариантах on-premise, облако и гибрид | Стандарт поддерживается платформой, но набор готовых серверов пока небольшой |
| Готовые серверы под конфигурации 1С | В каталогах практически отсутствуют | Коннектор к 1С:УТ или 1С:ERP пишется под ваш обмен; стандарт окупается на переиспользовании |
| Российские CRM и отраслевые системы | Точечно, чаще силами интегратора | То же: описание пишется один раз и дальше живёт как ваш актив |
| Самописные и старые системы | Только своими руками | MCP-сервер здесь удобен тем, что прячет за собой любой способ обмена — хоть файловый |
Отдельно про 1С, потому что это самый частый вопрос. Стандарт не отменяет необходимости разобраться, каким способом ваша конфигурация отдаёт данные наружу — веб-сервисы, HTTP-сервисы, обмен через файлы или промежуточную базу. MCP-сервер встаёт над этим и превращает выбранный способ в описанный инструмент. Сравнение самих способов обмена с 1С мы разбирали отдельно; выбор между ними от появления стандарта не изменился.
Из этого следует развилка, которую стоит пройти осознанно. Первый путь — собирать агента внутри платформы: подключения настраиваются в её интерфейсе, запуск занимает недели вместо месяцев, но и агент, и описания живут внутри одного поставщика. Второй — держать MCP-серверы в своём контуре и обращаться к модели как к внешнему сервису: дороже на старте примерно на 15–20 %, зато смена модели или платформы не задевает подключения. Первый путь разумен для пилота, второй — когда сценариев больше одного и они надолго.
Чего MCP не решает
Здесь проходит граница, которую в коммерческих предложениях обычно не проводят. MCP отвечает на вопрос «как модель зовёт инструмент». Он ничего не говорит о том, кому этот инструмент можно звать, сколько раз и что останется в журнале. Три этих вопроса решаются отдельно и стоят отдельных денег.
| Слой | Решает ли MCP | Что нужно сверх стандарта |
|---|---|---|
| Вызов инструмента: имя, параметры, ответ | Да, это его предмет | — |
| Права доступа к данным | Нет | Отдельная учётная запись в каждой системе с правами уже, чем у рядового оператора |
| Необратимые действия: списание, отмена, отправка клиенту | Нет | Явный список запрещённых операций и подтверждение человеком перед выполнением |
| Лимиты и защита от шторма вызовов | Нет | Квота вызовов в минуту и стоп-кран, останавливающий агента при аномалии |
| Журналирование | Нет | Запись: кто, когда, какой инструмент, с какими параметрами, что вернулось и что изменилось |
Схема из четырёх горизонтальных полос, уложенных стопкой между блоком «Модель» сверху и блоком «Учётная система» снизу. Полосы сверху вниз: «Журнал вызовов», «Лимиты и стоп-кран», «Права доступа и подтверждение необратимых действий», «Описание и вызов инструмента (MCP)». Нижняя полоса выделена сплошной заливкой и подписана «покрывает стандарт», три верхние — штриховкой и общей выноской справа «отдельные требования и отдельные деньги в смете». Слева вертикальная стрелка сверху вниз с подписью «запрос модели».
Эти три слоя в честной смете идут отдельными строками, и по порядку величины они выглядят так: разграничение прав и ролей — 40 000–90 000 ₽, подтверждение необратимых действий человеком — 30 000–60 000 ₽, журнал вызовов с хранением и поиском — 25 000–50 000 ₽. Если в предложении их нет вовсе, это не значит, что подрядчик их сделает бесплатно, — это значит, что он их не планировал. Как эти уровни защиты устроены и в каком порядке их выстраивают, разобрано в материале про три контура защиты ИИ-агента.
Когда агент получает возможность не только читать, но и создавать документы, менять статусы и отправлять сообщения, в компании появляется ещё один субъект, изменяющий учётные данные, — и работает он быстрее любого сотрудника. Права такой учётной записи должны быть уже, чем у рядового оператора, а список необратимых действий согласован письменно до запуска. Подробнее — в материалах про принцип минимальных прав доступа и необратимые действия ИИ-агента.
Пять вопросов подрядчику
Все пять задаются на первой встрече и занимают десять минут. Ответы на них определяют, останется ли у вас что-то ценное после проекта.
- 1Отдаются ли описания инструментов заказчику в исходном виде и в каком репозитории они лежат? Правильный ответ — «в вашем, доступ у нас как у подрядчика». Ответ «они у нас на платформе» означает, что при расставании вы уходите с пустыми руками.
- 2Где развёрнуты MCP-серверы — в вашем контуре или у подрядчика? Это влияет и на цену переезда, и на то, через чью инфраструктуру ходят данные вашей учётной системы.
- 3Под какой учётной записью сервер обращается в 1С и в CRM и какие у неё права? Ответ «под администратором, чтобы точно работало» — повод остановиться и переделать до запуска, а не после первого инцидента.
- 4Что пишется в журнал на каждый вызов инструмента и сколько журнал хранится? Без этих записей ни один разбор «почему агент изменил документ» не проводится, а спор с подрядчиком превращается в обмен мнениями.
- 5Что произойдёт с описаниями при расторжении договора? Ответ должен быть пунктом договора, а не устным обещанием. Как это формулируется в остальных частях, разобрано в материале про существенные условия договора на внедрение.
Когда про MCP можно не думать
Стандарт полезен, но это инженерное решение, а не обязательное требование. Есть четыре ситуации, где разговор о нём — лишний пункт в переговорах.
- Один агент и одна система. Пять систем окупают стандарт на втором сценарии, одна не окупит никогда: обычный коннектор дешевле и проще.
- Коробочный продукт со встроенным ИИ. Если помощник живёт внутри вашей CRM и никуда за её пределы не ходит, подключать нечего — вы покупаете готовую функцию. Что при этом теряется по сравнению с заказным агентом, разобрано в статье про встроенный ИИ в CRM против заказного агента.
- Пилот на 6–8 недель, задача которого — понять, работает ли идея вообще. На этом этапе правильная цель — быстрый ответ на вопрос «полезно или нет», а не архитектура на три года вперёд.
- Агент, который ничего не делает в системах, а только отвечает по документам. Ему нужны база знаний и поиск, а не инструменты; из чего он собирается, разобрано в материале про состав ИИ-агента.
Зеркальный признак — когда о стандарте стоит говорить с самого начала: у вас больше трёх систем, в планах на год больше одного сценария с ИИ и вы уже один раз меняли подрядчика. При таком наборе 75 000 ₽ переплаты на первом агенте — самая дешёвая страховка из доступных.
