MCP как стандарт: что меняется для корпоративных интеграций

Что произошло

Ещё год-два назад подключение языковой модели к корпоративной системе выглядело одинаково в любой компании: команда писала адаптер к API, описывала в промпте функции, которые модель может вызвать, добавляла слой разбора ответов и обработку ошибок. Для следующей системы всё повторялось заново. Для следующей модели — тоже, потому что формат вызова функций у каждого поставщика свой. Интеграционный код оказывался одноразовым: он знал о конкретной модели, конкретной системе и конкретном сценарии.

MCP (Model Context Protocol) — открытая спецификация, которая разделяет эти три вещи. Протокол описывает, как приложение с моделью обнаруживает доступные инструменты, вызывает их и получает результат, не зная заранее, что это за инструменты и как они устроены внутри. Спецификацию поддержали основные поставщики моделей и инструментов разработки, а число готовых серверов для распространённых систем растёт.

Для корпоративного заказчика это сдвиг не технологический, а организационный. Пока каждая интеграция — отдельный проект, агентные сценарии масштабируются линейно затратам: пять систем и три агента означают пятнадцать связок. Когда появляется общий контракт, связка «система — протокол» пишется один раз, а связка «агент — протокол» уже есть в любом современном фреймворке. Сервер для 1С или СЭД по-прежнему нужно спроектировать, написать и сопровождать — но один раз для всех агентов, а не для каждого сценария отдельно. Вопрос переходит из плоскости «сколько стоит разработка» в плоскость «кто владеет коннектором и как он контролируется».

Как устроен MCP

Три роли: хост, клиент, сервер

В протоколе три участника. Хост — приложение, в котором работает модель: чат-интерфейс, агентная платформа, среда разработки. Клиент — компонент внутри хоста, который держит соединение с одним сервером и транслирует запросы. Сервер — отдельный процесс, который предоставляет инструменты и данные конкретной системы.

Обмен идёт сообщениями JSON-RPC либо через стандартные потоки ввода-вывода, когда сервер запущен локально рядом с хостом, либо по HTTP, когда сервер работает как сетевая служба. Второй вариант — основной для корпоративного контура: сервер разворачивается как обычный сервис в сегменте целевой системы, а хосты подключаются к нему по адресу.

Ключевое свойство: сервер ничего не знает о модели. Он получает вызов инструмента с параметрами и возвращает результат — какая модель и по какому промпту приняла решение, для сервера не существует. Это и делает его переиспользуемым.

Инструменты и их обнаружение

Сервер предоставляет три типа сущностей. Инструменты — действия с параметрами: «найти контрагента по ИНН», «получить остаток по счёту», «создать проект приказа». У каждого инструмента есть имя, текстовое описание и схема входных параметров в формате JSON Schema. Ресурсы — данные, доступные для чтения по адресу: документ, запись справочника, содержимое таблицы. Промпты — заготовки инструкций, которые сервер может предложить хосту для типовых задач.

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

При подключении клиент запрашивает у сервера список инструментов и получает актуальный перечень; при изменениях сервер уведомляет клиента. Ни промпт, ни код хоста не содержат жёстко прописанного перечня функций. Расширение возможностей агента становится задачей владельца сервера: добавили в сервер 1С инструмент «получить график платежей» — все подключённые агенты получили его без изменения своего кода. При кастомной интеграции пришлось бы менять каждого агента.

Отличие от интеграции «под проект»

Разница не в том, что MCP «умнее», а в том, где проходит граница ответственности. При интеграции под проект она проходит внутри кода одной команды, и никто снаружи не может проверить, что там происходит. При MCP граница — это протокол, и по обе стороны от неё можно ставить контроль.

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

Контроль на уровне протокола

Поскольку каждый вызов инструмента проходит через клиент и сервер как структурированное сообщение, контроль встраивается в это место, а не размазывается по промптам. Три механизма, которые мы считаем обязательными:

• Права. Сервер получает не абстрактный запрос от «модели», а запрос в контексте конкретного пользователя или сервисной учётной записи. Какие инструменты доступны, какие данные возвращаются — определяет ролевая модель целевой системы, а не промпт.
• Журнал. Каждый вызов записывается: кто, когда, какой инструмент, с какими параметрами, что вернулось. Это готовый аудиторский след, который невозможно получить из логов чата.
• Ограничения. Инструменты, изменяющие данные, помечаются отдельно и требуют подтверждения человеком или дополнительной проверки. Лимиты на частоту вызовов и объём возвращаемых данных задаются на сервере, а не в промпте.

Все три реализуются на шлюзе между хостами и серверами и работают одинаково для любого агента и любой модели.

Где ломается

Слабые места протокола проявляются там же, где ломаются любые интеграции, но со своими особенностями:

• Слишком много инструментов. Список попадает в контекст модели; сервер с сотней инструментов расходует контекст и ухудшает выбор. Лечится группировкой серверов по задачам и фильтрацией на шлюзе.
• Внедрение инструкций через данные. Результат инструмента — текст, который модель читает. Если в поле «комментарий» документа кто-то написал инструкцию для модели, она может её выполнить. Данные из систем нужно считать недоверенными, а действия с изменениями — подтверждать.
• Версионирование схем. Изменение параметров инструмента ломает агентов так же, как изменение API. Нужны правила совместимости: новые параметры — необязательные, удаление — через период устаревания.
• Качество сервера. Протокол не гарантирует, что сервер написан хорошо. Сервер, который при ошибке возвращает пустую строку вместо понятного сообщения, делает агента слепым.

Как это выглядит на практике

Производственная компания, 1С и три агента. Три пилота — помощник закупщика, ассистент по кадровым вопросам, помощник при закрытии месяца — делали три команды, и каждая написала свою интеграцию с 1С: через HTTP-сервисы, с собственной авторизацией и кэшем. При выходе из пилота выяснилось, что сопровождать три способа доступа к одной системе никто не готов. Их заменили одним сервером MCP с инструментами, разбитыми по областям, и единым журналом. Агенты подключились к нему за недели, а не за месяцы, а ИТ-служба получила одну точку контроля вместо трёх.

Сеть клиник, СЭД и подтверждения. Задача — ускорить подготовку проектов приказов, ответов на запросы, служебных записок. Сервер к СЭД предоставляет инструменты поиска, чтения карточек и создания проектов документов. Инструменты создания помечены как изменяющие данные: агент готовит проект, но отправка по маршруту согласования возможна только после подтверждения сотрудника.

Банк из первой сотни, смена модели. Поддержка внутренних пользователей строилась на агенте, который читает базу знаний и CRM. Через несколько месяцев изменились требования к размещению модели: внешний API стал недопустим, потребовалась модель в контуре. Поскольку доступ к базе знаний и CRM шёл через серверы MCP, замена модели свелась к настройке хоста и прогону набора проверочных сценариев. Интеграционный код не менялся.

Что это значит для российской компании

Первое и главное: MCP не требует внешних сервисов. Сервер — обычный процесс на Python, Go или Java в изолированном сегменте сети. Хост с моделью на vLLM, векторное хранилище на Qdrant, серверы к 1С и СЭД — всё это работает без выхода за периметр. Для компаний с требованиями 152-ФЗ и для субъектов КИИ это условие входа, а не опция.

Второе: готовых серверов для отечественных систем немного, и писать их для 1С, СЭД, корпоративных порталов и обменов с государственными системами будут внутренние команды или интеграторы. Компетенция нужна знакомая: проектирование API, описание схем, работа с правами. Специалисты по интеграции, которые есть в любой крупной ИТ-службе, справятся с этим быстрее, чем с «промпт-инжинирингом».

Третье: требования к объяснимости и аудиту решений проще выполнять, когда каждый вызов инструмента журналируется в структурированном виде. Для банков и медицины это прямой аргумент в пользу протокольного слоя.

Четвёртое: срок перехода значимых объектов КИИ на отечественные решения — 1 января 2028 года. Компании, которые строят агентные сценарии поверх систем, подлежащих замене, должны закладывать это в архитектуру: при замене системы переписывается сервер, а агенты продолжают работать с теми же инструментами, если их семантика сохранена.

Интеграционный слой стоит проектировать так, чтобы и модель, и целевую систему можно было заменить, не трогая друг друга.

Что делать: пошагово

1. Проведите инвентаризацию действий, а не систем. Соберите, какие операции агентам нужны в каждой системе: чтение справочников, поиск документов, создание черновиков, изменение статусов. Разделите на «только чтение» и «изменение данных». Второй список будет короче и потребует отдельных правил.
2. Выберите одну систему для первого сервера. Обычно это система с наибольшим числом обращений от разных сценариев — 1С или база знаний.
3. Спроектируйте инструменты под задачи, а не под API. Один инструмент — одна понятная операция с понятным результатом. Описание пишется для модели: что делает, что возвращает, когда применять. Схема параметров — с ограничениями и примерами значений. Ошибки возвращаются текстом, который модель может использовать для повторной попытки.
4. Поставьте шлюз. Единая точка, через которую хосты обращаются к серверам: аутентификация пользователя, проверка прав, журналирование, лимиты. Без шлюза каждый сервер решает эти вопросы по-своему.
5. Разверните в контуре. Сервер — в сегменте целевой системы, шлюз — между хостами и серверами, секреты — в хранилище секретов, а не в конфигурационных файлах.
6. Проверьте на двух уровнях. Контрактные тесты сервера: каждый инструмент возвращает ожидаемое при заданных параметрах. Проверка выбора инструментов моделью: набор из десятков типовых запросов, для которых известно, какие инструменты должны быть вызваны. Второй тест прогоняется при каждой смене модели или описаний.
7. Заведите реестр серверов. Кто владеет, какая версия, какие инструменты, какие изменяют данные, кто подключён. Без реестра через полгода никто не сможет сказать, какие агенты сломаются при изменении сервера.
8. Измеряйте время подключения нового агента. Это главная метрика интеграционного слоя. Если она не сокращается от агента к агенту, слой не работает как слой.

Типичные ошибки

• Обёртка API один к одному. Сервер повторяет все методы API системы, и модель получает десятки похожих инструментов. Почему плохо: модель выбирает инструмент по описанию, и при похожих описаниях выбор случаен. Что вместо: инструменты под задачи пользователя, с укрупнением и понятными именами.
• Изменяющие инструменты без подтверждения. Агент может создать, отправить, удалить — и делает это по своему усмотрению. Почему плохо: одна ошибка выбора инструмента становится инцидентом. Что вместо: пометка изменяющих инструментов, подтверждение человеком, отдельный журнал.
• Доверие к результатам инструментов. Текст из системы передаётся модели как инструкция. Почему плохо: данные могут содержать внедрённые команды, случайно или намеренно. Что вместо: результаты помечаются как данные, изменяющие действия требуют подтверждения, чувствительные поля фильтруются на сервере.
• Авторизация через модель. Токены и учётные данные попадают в промпт, чтобы модель «сама» их передала. Почему плохо: они утекают в журналы, в контекст, в ответы. Что вместо: пользователь аутентифицируется в хосте, шлюз передаёт его идентичность серверу, сервер применяет права целевой системы.
• MCP для одного агента. Сервер спроектирован под единственный сценарий и содержит его логику. Почему плохо: это та же кастомная интеграция, только с другим транспортом. Что вместо: сервер содержит только операции системы, логика сценария остаётся в агенте.

Как понять, что вы на верном пути

• Новый агент подключается к существующему серверу настройкой, без изменений кода сервера.
• Смена модели проводится как настройка хоста и прогон проверочного набора, а не как проект.
• Для каждого сервера есть владелец, версия и перечень инструментов с пометкой изменяющих данные.
• Журнал вызовов инструментов даёт ответ на вопрос «кто, когда, что и с каким результатом» без обращения к разработчикам.
• Права доступа агента совпадают с правами пользователя, от имени которого он работает, и это проверено.
• Время подключения агента к системе измеряется и сокращается.
• Ни один сервер не отправляет данные за периметр без явного решения службы безопасности.

Вопросы, которые нам задают

Чем MCP отличается от вызова функций, который и так есть в моделях? Вызов функций — способность модели сформировать структурированный запрос к функции. MCP — договорённость о том, как приложение узнаёт о функциях, вызывает их и получает ответ, независимо от модели. Первое — свойство модели, второе — контракт между приложениями; протокол делает функции переносимыми.

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

Нужна ли ещё интеграционная шина, если есть MCP? Да. Шина связывает системы между собой в фоновых процессах. MCP связывает модель с системами в интерактивных сценариях. Сервер MCP может обращаться к шине, а не к системам напрямую, если так устроен ландшафт. Один слой не заменяет другой.

Начните с реестра действий, которые нужны агентам, и с одного сервера для самой востребованной системы. Через квартал у вас будет ответ, сокращается ли время подключения следующего агента, — и это единственный честный критерий того, что интеграционный слой состоялся.