MCP без ручной сборки: как Энтакси ускоряет создание интеграционных сервисов - Entaxy

MCP — один из заметных новых способов связать ИИ-системы с корпоративными данными и бизнес-функциями. Но за простым для пользователя принципом «агент вызывает инструмент» скрывается довольно много инженерной работы: HTTP-транспорт, обработка ошибок, маршрутизация, безопасность, SSE, JSON-RPC, проверка соответствия протоколу и еще целый набор технических деталей.

Для интеграционной платформы возникает закономерный вопрос: стоит ли каждый раз собирать эту инфраструктуру вручную?

В Энтакси этот процесс можно автоматизировать. Платформа генерирует необходимую MCP-обвязку, а аналитику остается сосредоточиться на бизнес-логике инструментов и их связи с корпоративными системами.

MCP: много протокола, мало бизнес-ценности

Когда компания создает MCP-сервис с нуля, значительная часть работы не связана непосредственно с задачей бизнеса.

Нужно реализовать HTTP-эндпоинт и фильтры, поддержать SSE, организовать диспетчеризацию методов протокола, сформировать JSON-RPC-ответы и ошибки, настроить безопасность, обработать runtime-ошибки, собрать сервисные конфигурации и написать conformance-тесты.

По оценкам ЕМДЕВ только техническая «обвязка» MCP может занимать порядка 132 человеко-часов при ручной реализации. При этом сама бизнес-логика инструментов оценивается еще в 10 часов. Именно здесь и появляется пространство для автоматизации.

Что генерирует Энтакси

Функция генерации MCP в Энтакси берет на себя повторяющуюся техническую работу вокруг протокола.

В проекте автоматически инкапсулируются несколько уровней инфраструктуры:

Транспорт MCP. Реализуются необходимые проверки и обработка HTTP-запросов, включая Origin, Accept, GET/405, notifications/202 и MCP-Protocol-Version, а также обработка ошибок парсинга и некорректных запросов.

SSE. Генерация избавляет от необходимости вручную решать технические проблемы взаимодействия SSE с асинхронным выполнением в CXF и самостоятельно формировать SSE-кадры.

JSON-RPC и ошибки. Формируется типовая обработка MCP-ответов и ошибок, включая CallToolResult, GetPromptResult, передачу envelope и возврат исходного id.

Маршрутизация инструментов и ресурсов. Для каждого элемента tools, resources и prompts генерируется соответствующая ветка маршрутизации. Аналитику не приходится вручную создавать десятки строк XML на каждый новый инструмент.

Security. Используются готовые механизмы платформенной безопасности, включая схемы JAAS и OAuth и привязку профиля через роли.

Обработка runtime-ошибок. Для коннектора автоматически создается callable-route errorHandler, который позволяет встроить обработку ошибок в MCP-сценарий.

В результате техническая часть MCP становится не отдельным проектом, а повторяемым шаблоном внутри интеграционной платформы.

Аналитик описывает инструменты, а Энтакси — все остальное

Важный принцип автоматизации заключается в разделении ответственности.

Энтакси не пытается «сгенерировать бизнес». Логика конкретного инструмента (запросить данные, изменить запись, запустить процесс, обратиться к внешней системе) по-прежнему остается задачей аналитика.

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

В расчете для сервиса с десятью инструментами бизнес-логика составляет 10 человеко-часов и не автоматизируется. Остальная инфраструктура MCP при использовании Энтакси сокращается до нескольких часов.

Это принципиально важно: автоматизация не заменяет аналитика, а убирает из его работы рутинную инфраструктуру.

142 часа против 16

При использовании генерации MCP экономический эффект становится заметен уже на первом сервисе.

Для MCP-сервиса с десятью инструментами оценка выглядит так:

Таким образом, первый сервис дает экономию около 126 часов, или 89%. На каждом последующем сервисе экономия оценивается еще примерно в 28 часов, или 64%, поскольку часть базовой работы уже повторно используется.

Еще один эффект появляется при увеличении количества инструментов внутри одного MCP-сервиса.

В ручном варианте для каждого инструмента приходится добавлять маршрутизацию и тесты. В Энтакси список инструментов используется как основа для генерации соответствующих веток маршрута.

Для сервиса на 50 инструментов только задача маршрутизации оценивается примерно в 28–33 часа вручную против 4 часов c Энтакси MCP. Дополнительная экономия составляет около 25–30 часов только на одном крупном сервисе.

Генерация MCP как вопрос управляемости

Ускорение разработки — только одна сторона задачи. Для корпоративной среды не менее важно, чтобы MCP-сервисы создавались по единым правилам.

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

Централизованный подход Энтакси позволяет вынести эту повторяющуюся логику в платформу и использовать единый механизм генерации. За счет этого MCP становится частью общей интеграционной среды, а не отдельным набором самописных сервисов.

Получается простая модель: аналитик определяет, что умеет инструмент, а платформа помогает стандартизировать, как этот инструмент становится MCP-инструментом.

Что автоматизация не отменяет

Важно не переоценивать эффект.

Генерация MCP не заменяет проектирование интеграции и написание бизнес-логики. Маршрутизация на конкретную корпоративную систему по-прежнему требует разработки. Кроме того, в текущем проекте сохраняются некоторые ручные операции: например, тонкая настройка обработки ошибок.

Есть и еще одна важная оговорка — приведенные трудозатраты это экспертная оценка для аналитика, знакомого с Энтакси, Camel и CXF, но впервые реализующего MCP. При этом вариант с «копипастом» предполагает, что уже существует ранее созданный MCP-сервис.

То есть корректнее говорить не о магической кнопке «сделать MCP за пять минут», а об автоматизации большой повторяющейся части работы.

MCP как стандартный строительный блок интеграционной платформы

Главной идеей функции генерации и управления MCP в Энтакси является не сокращение количества строк кода. Речь о другом подходе к интеграциям — MCP становится стандартным строительным блоком платформы. Его транспорт, маршрутизация, ошибки, безопасность и проверки соответствия протоколу не нужно заново проектировать для каждого нового сервиса.

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

А когда MCP-сервисов становится десятки, разница превращается уже в конкретный бизнес-эффект: меньше повторяющейся разработки, быстрее запуск новых сценариев и больше времени команды на действительно полезную работу, т.е. ту самую бизнес-логику, ради которой интеграция вообще создается.