Uber: как MCP Gateway объединяет инструменты для ИИ-агентов

Почему отдельные подключения перестали работать

В Uber ИИ-агентам понадобился доступ к актуальным данным и действиям во внутренних системах: инструментам разработки, служебным API и операционным сведениям. Для такого взаимодействия используют MCP (Model Context Protocol) — протокол, с помощью которого агент узнаёт, какие инструменты доступны, передаёт им структурированные аргументы и получает результат. Первые интеграции быстро показали пользу: модель переставала быть ограничена только текстом диалога.

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

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

Две части платформы: каталог и выполнение

В архитектуре разделены два контура. MCP Registry — реестр и управляющий контур (control plane): в нём хранятся определения инструментов, сведения об их владельцах и состоянии доступности. Proxy Gateway — рабочий контур (data plane), который принимает запрос агента и организует вызов нужного сервиса. Слово «виртуальный сервер» здесь означает представление сервиса через Gateway; для каждого существующего API не требуется запускать отдельный новый MCP-процесс.

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

Первая оригинальная схема показывает границу системы: слева разные клиенты, включая Cursor, Claude Code, внутренних агентов Uber и обычный MCP-клиент; по центру шлюз, принимающий MCP/JSON-RPC 2.0; справа сервисы TChannel/Thrift, HTTP/JSON, gRPC/Protobuf и нативный MCP-сервер. Вывод схемы — единый формат обращения для агентов при сохранении разных существующих API на стороне сервисов. Детальное управление каталогом происходит отдельно от этих рабочих запросов.

Как реестр пополняется без ручной переписи сервисов

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

AutoCrawler использует Cadence, систему распределённых рабочих процессов. Он связан с реестром описаний интерфейсов (IDL Registry) и внутренними сигналами сервисов. По расписанию cron запускает процесс Cadence, который проверяет новые сервисы, новые методы и изменения схем. Для обнаруженных сущностей он создаёт либо обновляет виртуальные MCP-серверы, готовит описания инструментов и регистрирует их. При регистрации они по умолчанию выключены.

На второй схеме показан весь путь подготовки: слева источники сведений об API и нативных серверах, затем AutoCrawler, проверка владельцем и MCP Registry. В блоке хранилищ на самой схеме указаны Cassandra для метаданных и Terrablob для схем; после реестра показаны автоматическая синхронизация и обновление маршрутов и инструментов Gateway. Это фоновые процессы изменения каталога: они не должны смешиваться с обработкой каждого вызова агента. Рисунок дополняет текст статьи названиями хранилищ, но не содержит их нагрузочных характеристик.

Как методы Protobuf и Thrift становятся MCP-инструментами

Описание интерфейса (IDL, interface definition language) фиксирует, какие методы есть у сервиса, какие данные принимает каждый метод и какой ответ возвращает. Uber использует такие определения в Protobuf и Thrift. AutoCrawler может получить из них основу нового инструмента, не меняя код самого API.

Для каждой группы «сервис — API» сначала создаётся или обновляется запись виртуального MCP-сервера. Затем AutoCrawler разбирает файлы Protobuf или Thrift: извлекает имена методов, структуры запросов и ответов, а также комментарии разработчиков. На их основе языковая модель создаёт более понятные агенту описания возможностей инструмента. Это разовая подготовка либо обновление его определения при изменении API, а не генерация описания при каждом рабочем вызове.

Далее схемы преобразуются в представление, совместимое с MCP и JSON-RPC 2.0, после чего определения инструментов добавляются в Registry или обновляются. Новый инструмент остаётся выключенным до решения владельца. Здесь важно разделять описание инструмента, которое агент использует для выбора и заполнения аргументов, и реальное выполнение метода внутренним сервисом: за выполнение отвечает другой контур.

Как подключаются уже существующие MCP-серверы

Некоторые команды пишут сервисы специально для агентов. Такие нативные MCP-серверы уже реализуют протокол и сами объявляют инструменты, оптимизированные для работы модели. Для них нет необходимости восстанавливать методы из Protobuf или Thrift.

В Uber для нативных серверов используется фреймворк MCPFx. Сервер отправляет heartbeat — сигнал своего присутствия и готовности. AutoCrawler отслеживает эти сигналы, находит новый сервер и вызывает его метод listTools, чтобы получить опубликованный список инструментов вместе со схемами. Затем Registry получает виртуальный сервер-прокси с найденными определениями, также выключенный по умолчанию.

Таким образом, у AutoCrawler два разных способа обнаружения. Для обычного API исходником служит IDL, а для нативного MCP-сервера — его собственный список инструментов. Дальнейшие требования к владению и разрешению вызовов общие.

Внешние MCP-интеграции и пользовательские токены

Платформа также позволяет подключать внешние MCP-сервисы, в статье названы Jira и Google. В отличие от внутренних API, здесь недостаточно знать адрес метода: нужно связать права пользователя внутри Uber с его правами во внешней системе.

Контракт разделён между двумя компонентами. MCP Gateway принимает вызов и передаёт пользовательский токен следующему интеграционному сервису, одновременно применяя общие механизмы авторизации, ограничения частоты запросов и скрытия чувствительных сведений. Отдельный Third-Party MCP Service обменивает внутренний пользовательский токен на соответствующий токен внешней системы и только после этого направляет запрос внешнему MCP-серверу.

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

Кто разрешает агенту пользоваться найденным инструментом

Автоматическое появление метода в каталоге ещё не означает, что агент вправе его вызвать. В Uber каждый новый сервер и каждый инструмент изначально выключены. За их использование отвечает команда, которой принадлежит исходный сервис: она проверяет описание, уточняет формулировки и явно включает нужные возможности. Так автоматизация снимает работу по обнаружению API, но не отбирает у владельца решение о доступе.

Изменение описания инструмента образует разницу между версиями конфигурации — diff. Его должен одобрить владелец сервера; после подтверждения новую конфигурацию можно развернуть, а при необходимости откатить к ранее известной версии. Это важно и для автоматически созданных описаний, и для дальнейших поправок к ним: изменение того, как модель понимает инструмент, проходит через контролируемый процесс.

Оригинальный экран MCP Registry показывает каталог с поиском и фильтрами, карточки сервисов, число инструментов на карточках и признаки статуса. На отдельном экране logging-mcp видны список инструментов, разделы Tools, Prompts и Resources, JSON-схема выбранного инструмента и действие обновления из IDL Registry. Например, среди названий перечислены инструменты работы с журналами и поиском по следу запроса. Это показывает, что владелец работает не с абстрактным «доступом ко всему сервису», а с конкретными инструментами и их описаниями.

На снимке отдельного logging-mcp есть метка Authorization Disabled, описывающая показанную конфигурацию этого сервера; её нельзя переносить на весь Gateway. Там же интерфейс предупреждает, что настройки Request/Response нельзя править прямо для MCP-инструментов. Снимки иллюстрируют интерфейс управления, тогда как требование обязательного одобрения владельца сформулировано в тексте статьи.

Как изменения каталога попадают в работающий шлюз

Теперь перейдём от подготовки инструментов к моменту, когда агент уже выбрал действие. Рабочий контур Gateway получает конфигурации серверов и инструментов из управляющего контура и с фиксированной периодичностью обновляет их в памяти. Поэтому новое описание или изменение состояния доступности может начать действовать без перезапуска сервиса и повторного развёртывания приложения. «В реальном времени» здесь означает обновление в работающем процессе, а не мгновенное распространение в момент редактирования.

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

На пятой оригинальной схеме этот путь раскрыт подробнее. После входного HTTP-обработчика и маршрутизации изображены общие проверки (наблюдаемость, ограничение частоты, работа с персональными данными и разрешениями), затем выбор инструмента, проверка его схемы и выполнение. Ниже показаны отдельные преобразователи для Thrift, HTTP, gRPC и прокси для нативного MCP. Схема также подписывает передачу метрик использования в Kafka и M3. Это детализация устройства шлюза, а не измерение его пропускной способности.

Разрешения и скрытие чувствительных данных

Управление публикацией отвечает на вопрос, появился ли инструмент в рабочем каталоге. Авторизация решает другой вопрос: может ли конкретный вызывающий субъект использовать его сейчас. MCP Gateway применяет внутреннюю систему контроля доступа Uber (Access Control System) и политики charter, которые учитывают тип вызывающей стороны. В статье выделены люди, сервисы и агенты.

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

В ответах инструментов предусмотрена автоматическая редакция чувствительных данных — удаление или скрытие персональной информации (PII) и других секретных сведений перед передачей результата агенту. На рисунке рабочего контура этот компонент подписан как AIGuard – Response PII Data Redactor. Наблюдаемость, проверка полномочий и очистка ответа встроены в общую инфраструктуру, чтобы их не приходилось самостоятельно реализовывать каждой команде.

Как вызов MCP превращается в запрос к старому API

После проверки прав исполнитель должен обратиться к сервису, который может ничего не знать о MCP. Для каждого инструмента обработчик Proxy Gateway хранит в памяти сведения о месте назначения: конфигурацию HTTP endpoint либо описание процедуры gRPC или TChannel. Такой обработчик понимает одновременно контракт MCP-инструмента и формат целевой системы.

Входящий структурированный JSON-запрос переводится в формат выбранного сервиса. Для интерфейсов на Protobuf или Thrift шлюз сериализует соответствующие сообщения в байты, направляет запрос и затем преобразует ответ обратно в JSON, пригодный для MCP-клиента. На схеме рядом также показан путь HTTP/JSON к REST-сервису. Преобразование позволяет оставить существующую реализацию API без изменений и при этом предоставить её агенту как инструмент.

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

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

Почему нативному MCP-серверу не нужен конвертер IDL

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

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

Что получила платформа и как понимать её масштаб

Uber выделяет четыре результата централизации: инструменты проще обнаружить и подключить; действующие API можно открыть для MCP без ручной разработки отдельных обёрток; правила безопасности и наблюдаемость сосредоточены в общей инфраструктуре; сервисные команды сохраняют владение и контроль над инструментами. Эти выгоды связаны: реестр без одобрения владельцев облегчал бы поиск, но не решал бы вопрос безопасного доступа; единый прокси без автоматического обнаружения не убрал бы ручное описание тысяч API.

По состоянию на публикацию 1 октября 2026 года авторы сообщают, что в Gateway размещено более 800 MCP-серверов и более 5000 инструментов. Это размеры размещённого каталога по самоотчёту Uber. Они не обозначают число автономных агентов, активных пользователей, успешных вызовов или увеличение производительности команд. В заключении статьи также говорится о возможности подключения новых команд за минуты, но без отдельного количественного исследования времени подключения.

Это разбор работающей инфраструктуры и её проектных решений, а не отчёт о сравнительном A/B-тесте. Авторы не приводят измерений задержки, пропускной способности, точности автоматического обнаружения, полноты редакции PII, экономии токенов или влияния на бизнес-метрики. Поэтому содержательный итог статьи — архитектура и заявленный масштаб её использования; переносить на неё несуществующие проценты улучшения нельзя.

Почему тысячи инструментов снова создали проблему

После объединения инструментов возникла уже другая задача: как агенту выбрать нужный из большого каталога. В обычном подключении MCP клиент заранее знает адрес сервера и получает его список инструментов. Межсерверного поиска по всем подключениям сам протокол MCP, согласно описанию авторов, не предоставляет. Если у компании сотни серверов, пришлось бы заранее прописывать множество URL, учётных данных и описаний инструментов.

Такая статическая конфигурация отнимает место в контекстном окне модели — объёме текста и определений, который ей доступен для рассуждения и выбора действия. Чем больше не относящихся к запросу схем попадает туда заранее, тем выше затраты и тем меньше пространства остаётся для самой задачи. Авторы называют эту проблему разрастанием контекста (context bloat). Они не утверждают, что каждый запрос уже содержал все 5000 инструментов: речь о неудачном направлении масштабирования через постоянное подключение всего каталога.

Чтобы исправить это, Uber добавила способы получать определения постепенно и возвращать не весь результат вызова. Решения различаются: Omni MCP помогает находить инструменты, Response Projection сокращает поля ответа, а Code Mode позволяет агенту работать через терминал и файлы.

Omni MCP: сначала найти инструмент, затем открыть его схему

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

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

Главный результат такой последовательности — описание большого каталога не загружается в контекст модели целиком. Инструменты появляются по мере надобности, а вызов по-прежнему проходит через авторизацию и остальные механизмы Gateway. Разные виды обнаружения не нужно путать: AutoCrawler заранее пополняет корпоративный Registry, Omni MCP во время задачи помогает конкретному агенту найти уже доступный инструмент.

Response Projection: получать нужные поля ответа

Даже если агент правильно выбрал инструмент, тот может вернуть объёмный JSON с множеством вложенных полей. Модели для решения конкретного вопроса часто нужна лишь часть результата. Чтобы не передавать весь ответ дальше, в Gateway предусмотрена Response Projection — выбор полей ответа по принципу, похожему на запрос в GraphQL.

В схему запроса MCP-инструмента добавляется поле, куда модель записывает массив путей к требуемым данным, включая вложенные поля. Gateway принимает результат вызова и во время обработки оставляет только перечисленные значения. Например, механизм позволяет сохранить названные поля ответа вместо всей вложенной структуры; конкретный синтаксис путей авторы не приводят, поэтому не будем придумывать имя параметра или формат команд.

Смысл в сокращении возвращаемой модели информации и в удобстве работы со сложными корпоративными API-схемами. Описанная в статье операция — обрезка ответа в Gateway: из этого не следует, что целевой сервис изначально пересчитывает меньше данных или отправляет по сети сокращённый Protobuf/Thrift-ответ.

Code Mode: результаты вызовов остаются в файлах

Для агентов-программистов Uber предусмотрела отдельный способ использовать тот же каталог. Такой агент уже умеет выполнять команды в терминале, работать с файлами и выбирать нужные участки текста. Поэтому не обязательно превращать каждое описание MCP-инструмента в постоянно доступное определение в контексте языковой модели.

Утилита aifx, интерфейс командной строки Uber для агентных операций, направляет вызовы через MCP Gateway. Отдельно устанавливать MCP-серверы для такого использования не требуется. В статье приведены три команды:

aifx mcp list
aifx mcp search
aifx mcp call

Первая показывает доступные серверы, вторая ищет инструменты по всем серверам, третья вызывает выбранный инструмент. Команды можно объединить в цепочку: найти инструмент, выполнить запрос и сохранить ответ в файл. Затем агент ищет по файлу нужный фрагмент, например через grep, и переносит в контекст только отобранные строки. Большой исходный ответ при этом не обязан целиком становиться частью переписки с моделью.

На шестой оригинальной схеме показаны два пути к общей платформе: обычный MCP-клиент обращается через Omni MCP с четырьмя операциями постепенного обнаружения, а агент-программист — через команды aifx. Справа общий Gateway применяет контроль доступа и проекцию ответа; нижняя подпись отдельно подчёркивает запись вывода в файлы и выборочное чтение. По словам авторов, Code Mode уже стал стандартным способом использования MCP-инструментов в агентах для программирования внутри компании. Это сообщение о принятой практике, а не запланированная функция.

Итог: как агент находит и вызывает инструмент через MCP Gateway

Uber построила MCP Gateway, чтобы агенты могли пользоваться действующими API компании через единый протокол. Архитектура разделяет подготовку инструментов и выполнение запросов. В фоне AutoCrawler читает IDL внутренних сервисов либо получает список инструментов нативных MCP-серверов, а владельцы проверяют определения и разрешают их использование. Registry сохраняет конфигурацию, которую рабочий Gateway обновляет без перезапуска. Для самого обращения агента путь выглядит так:

По данным авторов на 1 октября 2026 года, Gateway размещает более 800 MCP-серверов и более 5000 инструментов. Это масштаб каталога, а не измерение качества агентов или эффекта для бизнеса. Статья показывает рабочие архитектурные решения, но не приводит сравнительных тестов задержки, надёжности и экономии токенов. Её главный практический вывод — сочетать автоматическое обнаружение с ответственностью владельцев, общими проверками доступа и экономным представлением инструментов в контексте. Omni MCP раскрывает каталог постепенно, Response Projection убирает лишние поля ответа, а Code Mode оставляет объёмные данные в файлах. Эти способы решают разные задачи и дополняют основной шлюз.