Проектирование MCP Gateway: платформа управления MCP от Uber

Введение

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

Однако по мере роста популярности проявились и серьёзные проблемы. Команды разрабатывали интеграции независимо друг от друга, что привело к фрагментации инструментов и дублированию инфраструктуры. Инструменты MCP было сложно находить, трудно поддерживать их стабильную работу, а сами они оказывались жёстко привязаны к конкретным сервисам или реализациям агентов. На малых масштабах такой подход работал, но он совершенно не подходил Uber, когда сотни команд начали экспериментировать с агентными сценариями. Без единой архитектуры масштабирование MCP лишь увеличило бы операционную сложность, риски безопасности и трение для разработчиков, что в итоге ограничило бы эффект от технологии.

Чтобы раскрыть весь потенциал MCP в масштабах Uber, нам понадобилось централизованное и масштабируемое решение. Оно должно было стандартизировать взаимодействие AI-агентов с существующими бэкенд-системами, сохраняя при этом гибкость для команд. Такое решение должно было скрывать различия протоколов (HTTP, gRPC™, TChannel), обеспечивать единые гарантии безопасности и наблюдаемости, а также делать инструменты MCP простыми в создании, поиске и повторном использовании по всей компании.

Так появился MCP Gateway — базовый микросервис, который обеспечивает все взаимодействия по протоколу MCP в Uber. Он работает как слой оркестрации и маршрутизации между AI-агентами, существующими бэкенд-сервисами и нативными серверами MCP. Сосредоточив логику MCP в одном шлюзе, мы получили единую модель выполнения для взаимодействия агентов с сервисами и избавили команды от необходимости изобретать велосипед с базовой инфраструктурой. Существующие API теперь можно без лишних усилий превращать в инструменты MCP, управлять ими в одном месте и использовать сразу несколькими агентами единообразно. MCP Gateway открыл масштабируемый, быстрый и последовательный путь к созданию AI-агентов внутри Uber: сейчас он обслуживает более 800 серверов MCP и свыше 5000 инструментов.

Рисунок 1: MCP Gateway (API как инструменты).

В этой статье мы разберём архитектуру MCP Gateway: прокси-слой (трансляция MCP в существующие протоколы и обратно), слой обнаружения (MCP Registry и обход API) и плоскость управления (создание конфигураций).

Шлюз

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

MCP Registry хранит каталог сотен серверов MCP, работающих поверх внутренних сервисов, и тысяч инструментов MCP. Среди них есть как no-code описания, которые превращают существующие API в инструменты MCP, так и полностью нативные реализации, созданные специально под спецификацию MCP. Реестр служит единым источником истины для поиска, определения владельцев и подключения инструментов во всей экосистеме.

Proxy Gateway отвечает за выполнение запросов MCP в рантайме. Он переводит вызовы протокола MCP в запросы HTTP, gRPC или TChannel, отправляет их нужному бэкенд-сервису и преобразует ответы обратно в формат, совместимый с MCP. Благодаря этому слою трансляции AI-агенты могут взаимодействовать с существующими системами через единый интерфейс MCP, не требуя никаких изменений в самих сервисах.

Плоскость управления

Uber использует микросервисную архитектуру и поддерживает тысячи внутренних сервисов, которые предоставляют API по HTTP, gRPC и TChannel. Эти API дают ИИ-системе ценный контекст, но просить команды вручную создавать серверы MCP было бы долго и мучительно. Чтобы решить эту проблему, мы разработали AutoCrawler — систему, которая непрерывно сканирует реестр IDL Uber в поисках API, транслирует их и обновляет данные в реестре. Она также опрашивает нативные серверы MCP и добавляет их в реестр.

AutoCrawler: движок обнаружения

Autocrawler — это распределённая система рабочих процессов на базе Cadence, подписанная на реестр IDL Uber и сигналы внутренних сервисов. По расписанию cron-задача запускает процесс Cadence, который ищет новые сервисы, API и изменения схем.

Для каждого найденного объекта AutoCrawler выполняет следующие задачи:

• Создание или обновление представлений серверов MCP
• Генерация или получение определений и схем инструментов
• Регистрация инструментов в MCP Registry в состоянии «отключено по умолчанию»

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

Рисунок 2: Auto Crawler.

Обнаружение для сервисов на базе IDL

Для традиционных бэкенд-сервисов, описанных через Protobuf или Thrift IDL, AutoCrawler создаёт серверы и инструменты MCP напрямую из реестра IDL. Для каждой группы API сервиса выполняются следующие шаги:

• Создание или обновление сервера MCP: создаётся или обновляется виртуальный сервер MCP, соответствующий найденному сервису.
• Разбор определений IDL: парсятся связанные файлы protobuf или Thrift для извлечения имён методов, схем запросов и ответов, а также комментариев документации.
• Генерация описаний инструментов: с помощью LLM создаются подробные и удобные для агентов описания инструментов MCP на основе извлечённых схем и комментариев.
• Трансляция схем: схемы protobuf или Thrift преобразуются в совместимые с MCP схемы JSON-RPC 2.0.
• Создание или обновление инструментов MCP: сгенерированные инструменты регистрируются или обновляются в MCP Registry в состоянии «отключено по умолчанию».

Обнаружение для нативных серверов

Помимо сервисов на базе IDL, MCP Gateway поддерживает и нативные серверы MCP — сервисы, которые реализуют протокол MCP напрямую и предоставляют инструменты, оптимизированные для агентов.

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

1. Выполняется вызов listTools к нативному серверу MCP, чтобы получить список явно предоставляемых им инструментов вместе со схемами.
2. В MCP Registry создаётся виртуальный прокси-сервер MCP, содержащий все найденные инструменты и их схемы, в состоянии «отключено по умолчанию».

Сторонние серверы MCP

MCP Gateway работает как централизованный слой оркестрации для всех взаимодействий по протоколу MCP в Uber, обеспечивая бесшовную поддержку сторонних интеграций, таких как Jira и Google.

Подключение сторонних серверов MCP требует совместной работы двух ключевых компонентов:

1. MCP Gateway: передаёт пользовательский токен вызывающей стороны дальше по цепочке, одновременно применяя базовые функции шлюза, включая авторизацию, ограничение частоты запросов и маскирование конфиденциальных данных.
2. Сторонний сервис MCP: обменивает внутренний пользовательский токен на соответствующий токен аутентификации стороннего сервиса перед отправкой запроса на внешний сервер MCP.

Создание и активация

Мы можем создавать серверы MCP без участия команды сервиса, но право собственности и контроль над сервером должны оставаться за ней. Один из ключевых принципов проектирования MCP Gateway: обнаружение не означает автоматическую публикацию. Каждый сервер и инструмент MCP изначально создаётся в отключённом состоянии и должен быть явно проверен и включён командой-владельцем. Владельцы сервисов могут просмотреть и доработать сгенерированные описания инструментов перед их активацией.

Любое изменение описания инструмента формирует diff конфигурации, который должен быть одобрен владельцами сервера. Они могут утвердить и применить изменения, а при необходимости — откатиться к предыдущей рабочей версии.

Рисунок 3: Интерфейс MCP Registry.

Рисунок 4: Интерфейс инструмента MCP.

Плоскость данных

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

На основе этой конфигурации плоскость данных динамически материализует виртуальные серверы MCP. Для каждого виртуального сервера шлюз предоставляет единственный эндпоинт /<service-name>/mcp, который служит точкой входа для выполнения запросов AI-агентом. Входящие запросы направляются к соответствующим обработчикам серверов через встроенный прокси.

Рисунок 5: Плоскость данных MCP Gateway.

Трансляция протоколов и выполнение

За трансляцию протоколов в MCP Gateway отвечают обработчики серверов внутри Proxy Gateway. Каждый обработчик знает и об инструментах, и о нижележащих сервисах, что позволяет ему корректно маршрутизировать и выполнять запросы MCP в рантайме.

Безопасность

MCP Gateway обеспечивает встроенную авторизацию и маскирование данных для всех серверов с детализацией до уровня инструмента. Шлюз использует внутреннюю систему контроля доступа Uber, чтобы применять различные политики charter, настроенные для определённых вызывающих субъектов (людей, сервисов и агентов). Политики charter создаются на уровне сервера с возможностью переопределения на уровне отдельных инструментов, если это необходимо.

Кроме того, MCP Gateway «из коробки» маскирует любые персональные (PII) или конфиденциальные данные в ответах инструментов.

Нижележащие сервисы на базе IDL

Для инструментов, работающих поверх существующих бэкенд-сервисов, обработчик сервера поддерживает маппинг в памяти, описывающий целевой адрес — например, конфигурацию HTTP-эндпоинта или процедуры gRPC/TChannel.

Когда поступает запрос MCP, обработчик:

1. Преобразует входящую JSON-структуру в нужный сетевой формат.
2. Сериализует запрос в байты Protobuf или Thrift.
3. Пересылает запрос в нижележащий сервис.
4. Преобразует ответ в байтах Protobuf или Thrift обратно в совместимый с MCP JSON и возвращает его вызывающему агенту.

Сам запрос к нижележащему сервису выполняется через Muttley — сайдкар сервисной сетки Uber, который работает рядом со всеми бэкенд-сервисами. Делегируя выполнение запросов Muttley, MCP Gateway автоматически получает преимущества существующих механизмов маршрутизации между сервисами.

Нативные серверы MCP

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

Преимущества шлюза

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

• Простой поиск и подключение
• No-code подход к работе с существующими API
• Встроенная наблюдаемость и безопасность
• Централизованное управление правами и политиками

Развитие шлюза

Масштабирование MCP Gateway до сотен серверов и тысяч инструментов выявило проблемы, которых просто не существует на небольших объёмах. Например, раздувание контекста и чрезмерные затраты.

Обнаружение в рантайме

В MCP изначально нет механизма межсерверного поиска. Агент должен заранее знать, к какому серверу обращаться, прежде чем спрашивать о доступных инструментах. Чтобы настроить агента на работу с сервером MCP, нужно явно указать URL сервера, учётные данные и список инструментов. Делать это для сотен серверов невозможно: весь этот контекст быстро исчерпает лимит токенов модели. Мы решили эту проблему следующим образом:

• Omni MCP — единый прокси-сервер, позволяющий клиентам MCP получать доступ к любому серверу MCP Gateway по принципу постепенного обнаружения. Это также открывает путь к оптимизации контекста и токенов за счёт инкрементального поиска. Omni MCP предоставляет такие инструменты:
• discover_server — поиск сервера MCP по смыслу запроса
• discover_tools — поиск инструментов для конкретного сервера
• get_tool_schema — получение JSON-схемы инструмента
• invoke_tool — вызов инструмента

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

• Response Projection (проекция ответа) — MCP Gateway также поддерживает Response Projection, паттерн вызова инструментов MCP в стиле GraphQL. Он работает за счёт добавления нового поля в схему запроса инструмента, которое указывает шлюзу запрашивать только нужные поля, а не все подряд. LLM считывает это поле и передаёт массив вложенных путей только к необходимым данным. Затем шлюз в рантайме обрезает ответ, оставляя только спроецированные поля. Это позволило нам масштабировать совместимость схем API для MCP на корпоративном уровне.
• Code Mode (режим кода) — агенты для написания кода часто работают в shell-средах, где запись результата работы инструмента напрямую в файл эффективнее, чем загрузка полного ответа в контекст модели. Code Mode поддерживает этот паттерн через aifx — CLI-инструмент Uber для агентных операций. Он маршрутизирует вызовы MCP через шлюз, не требуя установки какого-либо сервера MCP. Это помогает агентам находить подходящие инструменты MCP для задачи, даже если определение MCP отсутствует в контексте. aifx предоставляет три команды:
• aifx mcp list — вывести список доступных серверов MCP
• aifx mcp search — искать инструменты по всем серверам MCP
• aifx mcp call — вызвать инструмент MCP через MCP Gateway

Агенты могут объединять эти команды в одну цепочку и записывать результат в файлы, которые файловые агенты затем выборочно читают через grep, загружая в контекст только необходимое. Сегодня Code Mode стал стандартом компании для использования инструментов MCP в агентах для работы с кодом.

Заключение

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

Главная идея, определившая наш дизайн, была предельно простой: существующие API — самый быстрый способ дать агенту нужные инструменты. Вместо того чтобы просить команды переписывать свои сервисы под агентный мир, MCP Gateway подстраивается под текущее положение дел: он прозрачно переводит вызовы HTTP, gRPC и TChannel в совместимые с MCP взаимодействия через Muttley, не требуя никаких изменений в нижележащих сервисах.

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

Благодарности

Источник фото на обложке: сгенерировано в ChatGPT от OpenAI; внешние изображения, логотипы или сторонние ресурсы не использовались.

gRPC является товарным знаком The Linux Foundation.

Следите за свежими материалами от Uber Engineering — подписывайтесь на нас в LinkedIn, чтобы первыми читать новые статьи и инсайты.