Привет, Хабр! Меня зовут Сергей Клюев, я техлид команды, которая занимается внедрением ИИ на платформе MWS Octapi.
На нашей платформе есть low-code инструменты для создания интеграций без привлечения разработки, но на практике пользователю всё равно требуется изучить документацию и разобраться с нюансами выполнения различных задач. Чтобы упростить этот процесс, мы решили добавить на платформу ИИ-ассистента, который постепенно превратился в полноценного ИИ-агента.
По мере расширения возможностей ИИ-ассистента нам понадобилось множество интеграций. В MWS Octapi уже более 700 интеграций (OpenAPI, SOAP, AsyncAPI, GraphQL и другие). Мы решили переиспользовать их, внедрив на платформу протокол MCP. Добавление поддержки MCP позволило превратить привычные API в «руки» для ИИ и быстро интегрировать ИИ-агентов в ИТ-ландшафт.
Про возможности протокола MCP и особенности его внедрения в Enterprise-среде — далее под катом. Эта статья — текстовая версия вебинара. Видеоверсия доступна по ссылке.
От Function Calling к MCP
ИИ-агент простыми словами — это программа, которая использует большую языковую модель (LLM) для решения поставленной задачи, взаимодействуя с внешними источниками. Для взаимодействия с пользователем у агента есть интерфейс — чаще всего это чат, куда можно отправлять неструктурированную информацию (текстовые запросы).
В обычном приложении вся логика — это алгоритм, прописанный разработчиком. В ИИ-агенте логика делегирована LLM: агент выполняет те действия, которые определит и отправит ему модель в ответ. Однако даже в этом варианте система ещё не является полноценным ИИ-агентом, а представляет собой просто чат: мы отправляем вопросы, они транслируются в LLM, она отвечает, но никаких действий не происходит.
Чтобы агент мог совершать действия, ему нужны функции — например, для работы с базой данных или взаимодействия со сторонними API. Через них агент и работает с внешними источниками данных.
Но как сообщить LLM контекст о доступных функциях, чтобы она знала, какими инструментами может воспользоваться? Ключевой шаг — подготовить для каждой функции структурированное описание. Чаще всего для этого используется JSON: формат определяет структуру входных и выходных параметров, варианты вызова функции. Полный набор описаний для всех доступных функций передаётся в запросе к LLM. Модель, обученная понимать подобный контекст, анализирует на его основе запрос пользователя.
В ответ модель возвращает структурированные данные — тот же JSON, где указано, какую функцию вызвать и с какими параметрами. Таким образом, на вход модели поступает описание доступных функций, а на выходе мы получаем готовую инструкцию к действию, сформированную логикой LLM для решения задачи. Затем агент парсит этот ответ и выполняет указанную функцию.
При первом погружении в тему вызова функций агентами часто возникает ложное впечатление, будто LLM сама как-то магически их вызывает. В действительности всё гораздо прозаичнее. LLM как работала с текстом, так и продолжает работать: на вход получая структурированное описание функций и формируя опять же структурированный ответ, содержащий параметры вызова функций. Именно этот механизм называется Function Calling — он позволяет перейти от простого текстового диалога к выполнению реальных действий.
Такую возможность одной из первых реализовала OpenAI в 2023 году. Компания добавила поддержку передачи описания функций в запросе, а также дообучила модели распознавать этот специальный контекст и генерировать на выходе структурированный ответ с указанием функции для вызова. Вслед за OpenAI аналогичный подход внедрили другие вендоры. У Anthropic этот функционал называется Tool Use.
Однако у такого подхода есть несколько существенных проблем.
1. Зависимость от вендора. Формат передачи параметров и работы с функциями зависит от конкретной модели и её клиента (OpenAI, Anthropic, Mistral и т. д.).
2. Сильная связанность. Чтобы добавить новую функцию или изменить существующую, приходится напрямую модифицировать код агента: писать саму функцию, создавать для неё обёртку, формирующую описание, и обновлять логику клиента. Это лишает систему гибкости, не позволяя оперативно расширять функционал агента.
Для решения этих проблем был создан протокол Model Context Protocol (MCP), призванный стандартизировать взаимодействие между LLM и внешними ресурсами.
Компания Anthropic представила протокол в ноябре 2024 года. Вскоре её поддержали другие крупные вендоры: Microsoft анонсировала поддержку MCP в своих клиентах для OpenAI, а в 2025 году Google добавила его в свои Agent SDK и модели.
Хотя называть MCP повсеместным стандартом пока рано, тренд на его принятие быстро растёт. Всё больше компаний разрабатывают собственные MCP-серверы для своих агентов, фактически признавая его формирующимся отраслевым стандартом де-факто. При этом протокол активно развивается. Текущая версия — 25.11.2025.
Обзор протокола MCP
В исходной архитектуре агент содержит описания функций, их реализацию и формирует JSON-описания для вызова. MCP выносит эту логику вовне — на отдельный MCP-сервер. Расширять функционал агента теперь можно без изменений его внутренней логики, добавляя новые MCP-серверы.
Итак, посмотрим, как трансформируется агент при подключении MCP:
1. Уходит зависимость от различий в структуре данных между вендорами
Логика работы раньше зависела от конкретной модели и её SDK. Теперь, когда вендоры всё чаще поддерживают MCP в своих SDK, можно менять модель или поставщика, не изменяя описание инструментов на стороне агента.
2. Исчезает сильная связанность между агентом и вызываемыми функциями
Поскольку реализация функций вынесена во внешний MCP-сервер, исчезает привязка к агенту. Этот сервер можно свободно модифицировать — например, переписать на другом языке программирования, — не затрагивая основного кода агента.
3. Появляется гибкое расширение
Новые MCP-серверы подключаются по принципу plug-and-play, позволяя практически мгновенно добавлять агенту новый функционал. Именно это я продемонстрирую далее.
Архитектура MCP
Архитектура MCP включает три основных компонента: MCP-хост, MCP-клиент и MCP-сервер.
MCP-хост — это приложение (например, агент или ИИ-приложение), которое координирует работу нескольких MCP-клиентов.
MCP-клиент запрашивает у MCP-сервера информацию о доступных инструментах (tools). MCP-сервер, в свою очередь, отвечает за выполнение функций, вызываемых клиентом, а также за взаимодействие с бэкендом.
В протоколе существует два уровня:
1. Data Layer (уровень данных)
Определяет формат сообщений для обмена между клиентом и сервером. Для семантики сообщений используется JSON-RPC.
2. Transport Level (транспортный уровень)
Определяет способ передачи этих JSON-сообщений. Существует два основных транспорта:
Stdio (стандартный ввод-вывод). Используется, когда MCP-хост, клиент и сервер работают на одной машине.
Streamable HTTP. Позволяет выполнять удалённые вызовы. Клиент отправляет POST-запросы (в соответствии с JSON-RPC) на определённый эндпоинт (например, https://хост/mcp). В зависимости от заголовка Content-Type клиент получает обычный JSON-поток или потоковую передачу данных через Server-Sent Events (SSE).
Рассмотрим основные примитивы, которые предоставляет MCP-сервер.
1. Tools (инструменты)
Это основа функционала — внешние инструменты: вызовы API, исполнение скриптов или любые другие действия, которые может выполнить агент. Для работы с ними в протоколе определены два стандартных метода:
tools/list — клиент получает список доступных инструментов;
tools/call — агент через клиент передаёт информацию о том, какой именно инструмент вызвать и с какими параметрами.
2. Resources (ресурсы)
Это источники данных, доступные агенту только для чтения (файлы, документация, справочники). Для управления ресурсами есть свои методы: list, read и subscribe. Особый интерес представляет subscribe: клиент может подписаться на ресурс и получать от сервера уведомления о его изменениях.
3. Prompts (промты)
Это шаблоны или инструкции, объясняющие агенту, как работать с данным MCP-сервером. Для них предусмотрены методы prompts/list и prompts/get.
На официальном сайте MCP видно, что поддержка Tools отмечена у всех клиентов, в то время как Resources и Prompts поддержаны лишь частично — эти компоненты протокола всё ещё находятся в стадии активной адаптации.
Давайте рассмотрим диаграмму последовательности. Как строятся вызовы и кто является их инициатором?
В упрощённом варианте у нас есть следующие участники (акторы):
Пользователь.
Агент со встроенным MCP-клиентом.
MCP-сервер, выполняющий функции.
LLM, к которой обращается агент.
Бэкенд, выполняющий сами действия.
Рассмотрим, как строится взаимодействие между этими компонентами.
Вначале, при добавлении нового MCP-сервера, между клиентом и сервером должен пройти процесс инициализации. Это стандартная процедура: они обмениваются версиями, проверяют совместимость.
Затем начинается процесс Tools Discovery. Поскольку агенту неизвестны возможности нового сервера, он запрашивает у него список доступных инструментов. Агент отправляет запрос tools/list на MCP-сервер через клиента. В ответ мы получаем список tool-ов, какими обладает MCP-сервер.
Далее пользователь отправляет запрос агенту. В самом простом случае агент перенаправляет запрос в LLM, дополняя его полученным списком доступных tools. То есть он говорит модели: «Вот запрос пользователя, а вот список tools, которые ты можешь использовать для его решения». LLM анализирует это и отвечает в структурированном формате, например: «Для решения этой задачи нужно вызвать Tool 1 с параметрами A, B, C».
После этого агент инициирует вызов инструмента. Через своего MCP-клиента он отправляет на сервер запрос tools/call, указывая, какую именно функцию вызвать и с какими аргументами. MCP-сервер принимает вызов, парсит его и выполняет реальный запрос к целевому бэкенду, для которого и предназначен этот инструмент. Получив ответ от бэкенда, сервер передаёт результат клиенту, и агент, наконец, получает итог выполнения.
Дальнейшие действия зависят от логики агента. В простейшем случае он может передать полученный результат обратно в языковую модель, сообщив: «На вызов инструмента [X] я получил результат [Y]». На основе этого LLM принимает решение о следующих шагах. Чаще всего модель формирует итоговое сообщение для пользователя на основе результата, и агент отправляет его в чат.
Особенности внедрения MCP в Enterprise
Область применения MCP в enterprise определяется масштабом интеграций. Протокол оправдывает внедрение, когда агенту необходимо работать с множеством различных API и требуется гибко добавлять или изменять их, не затрагивая код самого агента.
Однако, если мы делаем Proof of Concept (PoC) агента, который использует всего две статичные интеграции и не предназначен для активного развития в продакшене, вполне достаточно стандартного механизма Function Calling.
Кроме того, согласно исследованию MIT, 95% пилотных проектов с ИИ-агентами не выходят в продакшен. Одной из главных причин называется flawed enterprise integration — сложные, неочевидные и плохо спроектированные интеграции в корпоративной среде.
Тут уместна аналогия с наймом сотрудника: чем отлаженнее процесс онбординга и выдачи доступов, тем быстрее новичок начинает приносить результат. Если же эти процедуры запутанны, адаптация затягивается.
ИИ в этом контексте действует как усилитель существующих процессов. Чёткие инструкции, прозрачные интеграции и отлаженные процедуры позволяют агенту резко повысить эффективность. Но если интеграции непрозрачны, а процессы хаотичны, агент лишь усиливает этот хаос. В такой ситуации внедрение ИИ не только не поможет, но и может усугубить проблемы.
При разработке агентов в enterprise без MCP каждая команда создаёт своего собственного агента. Представьте ситуацию: с одной стороны — 4 агента, с другой — набор внешних систем: базы данных, Jira, почта, поиск. Каждая команда пилит отдельную интеграцию с этими системами, подключает её к своему агенту и пытается его запустить. В результате возникают по сути одинаковые, но не переиспользуемые интеграции, и все команды пытаются решить одну и ту же задачу. Такой подход порождает проблему избыточной сложности M × N, где каждый агент может пытаться интегрироваться с каждой системой.
Протокол MCP решает эту проблему, выступая в роли хаба. Вынеся интеграцию с конкретной системой (например, Jira) в отдельный MCP-сервер, мы позволяем множеству агентов и клиентов переиспользовать её через единую точку доступа. Это снижает сложность до модели M + N.
Однако стоит понимать, что всё хорошо бывает не всегда и не сразу. MCP — это лишь протокол. Он определяет правила взаимодействия (форматы сообщений, методы), но не решает задач безопасности, надёжности и наблюдаемости. Реализация этих аспектов остаётся за продуктом или платформой, которая использует MCP.
Подробнее рассмотрим вопросы Identity and Access Management (IAM) — управления доступом и правами в контексте MCP. Спецификация MCP предполагает, что все API должны быть совместимы со стандартом OAuth 2.1. Однако в реальных корпоративных средах единый стандарт — редкость. Мы столкнулись с этим на практике при подключении интеграций к нашей платформе MWS Octapi. В enterprise часто встречаются legacy-API, авторизация по ключу, Basic Auth и другие устаревшие или нестандартные методы. Сам протокол MCP не регламентирует работу с такими API, поэтому решения приходится придумывать самостоятельно.
Следующий острый момент — разграничение доступа на уровне методов API. Обычно есть некий сервис с API: мы авторизовались и можем вызывать любые методы. Но не все бэкенды реализуют детальное разграничение прав (например, RBAC) в зависимости от конкретного метода.
На уровне агентов проблема усугубляется, потому что не каждому агенту нужно давать права на изменение или удаление данных. Всё-таки мы понимаем, что решение принимает LLM — по сути, «чёрный ящик». Критические функции делегировать ей рискованно. Даже с чтением данных не всё однозначно: доступ к публичному справочнику и доступ, например, к зарплатам всех сотрудников — это принципиально разные уровни ответственности.
При подключении OpenAPI-интеграций мы в MWS Octapi столкнулись с той же проблемой и решили её с помощью дополнительных токенов, которые разграничивают доступ на уровне методов прямо на стороне сервера. Данное решение мы теперь применяем при создании MCP-серверов.
Возможности MWS Octapi — как самостоятельно создать MCP-сервер
На видео показан путь создания MCP-сервера на платформе MWS Octapi. Мы генерируем MCP-сервер автоматически на основе OpenAPI-спецификации.
Заключение: выученные уроки
MCP не решает проблему выбора нужного инструмента
Как объяснить LLM, какой именно инструмент нужно использовать в данный момент? При небольшом количестве инструментов LLM обычно корректно понимает, что нужно сделать вызов. Однако с ростом их числа модель может ошибаться — проблема галлюцинаций остаётся актуальной.
Сам протокол MCP не решает эту задачу. Она должна решаться на уровне логики агента — необходимы механизмы управления контекстом и памятью.
Function Сalling валидная опция для простых агентов
MCP необходим, когда агенту требуется доступ ко множеству API, которые могут изменяться, и есть необходимость избежать привязки интеграций к коду агента. В таких случаях MCP — правильный выбор. Для PoC же достаточно стандартного Function Calling.
Ограничивайте количество инструментов (tools) в MCP
В один MCP-сервер лучше не добавлять более 10 методов. Причина в том, что агент запрашивает и загружает в LLM полный список инструментов. Слишком большой список может превысить возможности модели или привести к ошибкам. Хотя результат зависит от конкретной LLM и логики агента, общее правило таково: чем лаконичнее список методов, тем выше надёжность и точность работы агента. Для решения этой проблемы мы добавили возможность выбора конкретных методов, которые будут доступны агенту, а также механизм разграничения доступа.
Надеюсь, эти наблюдения и советы будут полезны для ваших проектов.