Под названием «MCP Bridge» встречаются несколько проектов, которые превращают описание REST API в MCP-инструменты для агента; здесь разобран продукт mcp-bridge.ai: он импортирует схему вашего API, собирает из её операций инструменты и выполняет запросы с настроенной авторизацией. Разработчику остаётся отобрать нужные операции, описать их словами для модели и решить, какие из них разрешено вызывать. Подходит, когда у внутреннего сервиса есть актуальная схема OpenAPI и агенту достаточно небольшого набора действий.
Что делает мост
MCP Bridge читает схему (по сайту продукта, поддерживаются OpenAPI, GraphQL, WSDL и gRPC), генерирует определения MCP-инструментов и выполняет запросы к вашему API с заданной авторизацией.
Условный пример: у компании есть внутренний сервис заявок на ремонт оборудования с REST API и готовой схемой OpenAPI. Руководитель цеха хочет спрашивать агента о статусе заявок и получать сводку по участку. Для этого агенту нужны две операции чтения, а создание и закрытие заявок нужны намного реже и требуют контроля. Схема уже описывает все пять операций сервиса, и вопрос сводится к тому, какие из них превратить в инструменты.
Имя носят многие проекты: на GitHub есть и другие мосты, которые строят MCP-сервер из описания OpenAPI, а мостами называют ещё и переходники между stdio и HTTP. Принцип отбора операций ниже общий, а детали настройки относятся к продукту, описанному на сайте MCP Bridge. Он разворачивается как контейнер Docker (на сайте названы AWS ECS, Azure Container Apps и совместимые оркестраторы), поэтому запросы к внутреннему API могут идти из вашей сети. Это отличается от варианта, где разработчик пишет сервер вручную: в статье про собственный MCP-сервер каждый инструмент описывается кодом, а здесь основа берётся из схемы и затем правится. Практический критерий выбора такой: если схема актуальна и операций немного, начинайте с моста; если схема устарела, сперва приведите её в порядок, потому что мост унаследует каждую неточность. Для малого числа операций с хорошей схемой мост экономит ручную работу по описанию параметров и валидации, а для нестандартной логики вроде склейки нескольких вызовов в один шаг привычнее собственный код. Выбор между путями зависит от качества схемы и от того, сколько операций нужно агенту.
Отбор операций
| Операция сервиса заявок | Решение | Причина |
|---|---|---|
| Список заявок участка | Включить | Чтение, результат легко проверить |
| Карточка заявки | Включить | Чтение, нужна для ответа на вопрос о статусе |
| Создание заявки | Отложить | Запись, включается после тестового этапа |
| Смена статуса заявки | Отложить | Запись с последствиями для плана работ |
| Удаление заявки | Исключить | Необратимое действие без пользы для сценария |
По описанию продукта, управление набором строится вокруг «кураторства инструментов»: каждую операцию можно включить или отключить, переименовать, поправить описание и настроить сопоставление параметров. Это главный шаг всей работы, и на него закладывают больше всего внимания: именно здесь схема, написанная для разработчиков, становится набором понятных модели действий. Схема, сгенерированная для людей-разработчиков, содержит технические подписи, а модели нужны понятные формулировки. Описание «Возвращает заявки участка за выбранный период» работает лучше, чем копия служебного комментария из схемы.
Модель ошибается там, где подписи неоднозначны. Если в схеме два поля называются почти одинаково, агент перепутает их, и ответ окажется формально верным, но по другому участку. Сократите и сами параметры: агенту достаточно участка и периода, а служебные поля пагинации и внутренние идентификаторы стоит скрыть от модели через сопоставление параметров. Чем меньше полей решает модель, тем реже запрос оказывается ошибочным. Принципы описания инструментов подробнее разобраны в статье про инструменты MCP-сервера.
Авторизация
Секретам нужна разумная политика: срок жизни, замена по расписанию, отзыв при подозрении. Среди способов авторизации продукт называет Bearer-токен, Basic, ключ API и OAuth2. Секрет обязан оставаться вне описания инструмента и вне диалога с моделью: проверьте это на тестовом запросе. Для пилота выберите тот, который уже принят в вашем сервисе, и заведите отдельную служебную учётную запись для агента. Права этой записи на стороне сервиса должны совпадать с набором включённых инструментов: даже при ошибке в настройке моста сервис откажет в любом действии сверх выданных прав.
- Служебная учётная запись агента отделена от личных записей сотрудников.
- Права записи в сервисе выключены, пока в мосте отключены операции записи.
- Секрет хранится в менеджере секретов вашей инфраструктуры и недоступен модели.
- В журнале сервиса запросы агента отличимы по имени учётной записи.
Журнал сервиса отличит запросы агента от запросов людей только при отдельной учётной записи, поэтому разделяйте их даже на тестовом стенде. Если агент должен действовать от имени конкретного сотрудника, схема усложняется: нужен вход через OAuth и отзыв токена при уходе человека. Эту часть удобно сверять со статьёй про OAuth-доступ и отзыв прав. Для первого запуска служебная запись с правами чтения проще и безопаснее.
Тест на чтении
Прежде чем проверять ответы, убедитесь, что мост видит сервис из своей сети: запросы идут из контейнера, поэтому доступ к адресу API и правила межсетевого экрана проверяются первыми. Тест строится на операции без побочных эффектов. Если запрос чтения завершается верным ответом, значит схема импортирована, авторизация работает и параметры сопоставлены. Если ответ неверен, причину ищут в описании параметров или в сопоставлении, а запись остаётся закрытой. Каждый прогон фиксируют: вопрос, вызванный инструмент, переданные параметры, ответ API и вердикт проверяющего.
- Импортируйте схему сервиса заявок и оставьте включёнными только список заявок и карточку заявки.
- Задайте служебную учётную запись с правами чтения и проверьте вход.
- Попросите агента назвать заявки участка за вымышленный период и сверьте ответ со списком в самом сервисе.
- Спросите о заявке, которой нет в системе, и убедитесь, что агент сообщает об отсутствии вместо подстановки похожей.
Аннотации инструментов — «только чтение», «разрушающая», «идемпотентная» — продукт выводит автоматически, и они доступны для правки. Проверьте их сами: метод поиска, оформленный как POST, продукт может принять за запись, а метод GET с побочным эффектом, наоборот, считать безобидным. Автоматическая разметка служит первым приближением, а итоговое решение принимает человек, который знает, что делает каждый метод на самом деле.
Какие операции вашего API вы бы открыли агенту первыми?
Контроль записи
Перед включением записи опишите последствия каждого вызова: что изменится в плане работ, можно ли отменить действие и кто увидит результат. Запись включайте по одной операции и только после подтверждения чтения. Для создания заявки в мосте открывается один инструмент, а решение о вызове принимает сотрудник: агент готовит параметры, человек читает их и подтверждает. Хорошее подтверждение показывает человеку имя инструмента и все параметры вызова целиком, без сокращений. Подтверждение настраивают в клиенте агента, а проверку права и формата дублирует сам сервис, поскольку мост служит лишь одним из слоёв.
Журнал просмотрите в первую неделю глазами владельца сервиса: какие инструменты вызываются чаще, какие запросы завершаются ошибкой, где агент повторяет вызов. Журнал строится на двух сторонах: мост показывает задержки, пропускную способность и расход токенов по инструментам, а сервис хранит кто, когда и что создал. Сверяйте оба журнала на тестовых заявках. Полный ответ API в журнал моста часто попадает вместе с данными сотрудников, поэтому определите, что именно сохраняется, и закройте лишнее до рабочего запуска. Подробнее о контрактах инструментов — в статье про инструменты компании для агентов.
Возьмите одну схему и отметьте в ней две операции чтения. Импортируйте только их, подключите служебную запись без права изменений и прогоните тест на вымышленных данных. Когда нужен контур с подтверждениями, журналом и приёмкой, обсудите с нами автоматизацию вашего процесса.