Вступ
Стрімке впровадження 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: Proxy Layer (перетворення MCP на існуючі протоколи та навпаки), Discovery Layer (MCP Registry та сканування API) і площину управління (авторинг).
Шлюз (Gateway)
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 дають AI-системам цінний контекст, але просити команди вручну створювати сервери MCP було б довго й болісно. Щоб вирішити цю проблему, ми розробили AutoCrawler — систему, яка постійно сканує IDL-реєстр Uber на наявність нових API, транслює їх та оновлює в реєстрі. Вона також опитує нативні сервери MCP і додає їх до реєстру.
AutoCrawler: рушій виявлення
Autocrawler — це розподілена система робочих процесів на базі Cadence, підписана на IDL-реєстр Uber та сигнали внутрішніх сервісів. За фіксованим розкладом cron-задача запускає workflow Cadence, який сканує систему на предмет нових сервісів, API та змін у схемах.
Для кожного виявленого об'єкта AutoCrawler виконує такі завдання:
- Створює або оновлює представлення сервера MCP
- Генерує або отримує описи та схеми інструментів
- Реєструє інструменти в MCP Registry у стані «вимкнено за замовчуванням»
Ця спільна база дозволяє масштабувати виявлення MCP на тисячі сервісів, не залучаючи команди сервісів до критичного шляху.
Рисунок 2: Auto Crawler.
Виявлення для сервісів на базі IDL
Для традиційних бекенд-сервісів, описаних через Protobuf або Thrift IDL, AutoCrawler створює сервери та інструменти MCP безпосередньо з IDL Registry. Для кожної групи API сервісу AutoCrawler виконує такі кроки:
- Upsert MCP-сервера: створює або оновлює віртуальний сервер MCP, що відповідає виявленому сервісу.
- Парсинг IDL-описів: аналізує відповідні файли protobuf або Thrift, щоб витягти назви методів, схеми запитів і відповідей, а також коментарі документації.
- Генерація описів інструментів: використовує LLM для створення розширених, зручних для агентів описів інструментів MCP на основі витягнутих схем і коментарів.
- Трансляція схем: перетворює схеми protobuf або Thrift на сумісні з MCP схеми JSON-RPC 2.0.
- Upsert інструментів MCP: реєструє або оновлює згенеровані інструменти MCP в MCP Registry у стані «вимкнено за замовчуванням».
Виявлення для нативних серверів
Окрім сервісів на базі IDL, MCP Gateway також підтримує нативні сервери MCP — сервіси, які реалізують протокол MCP напряму та надають інструменти, оптимізовані для агентів.
MCPFx — це фреймворк, який Uber використовує для створення нативних серверів MCP. Кожен такий сервер генерує метрику heartbeat, що сигналізує про його наявність і готовність. AutoCrawler постійно моніторить ці сигнали, щоб автоматично виявляти нові нативні сервери MCP. Коли такий сервер знайдено, AutoCrawler діє за іншим сценарієм:
- Він робить виклик listTools до нативного сервера MCP, щоб отримати список інструментів, які той явно надає, разом із їхніми схемами.
- Він створює віртуальний проксі-сервер MCP у MCP Registry, який містить усі виявлені інструменти та їхні схеми, у стані «вимкнено за замовчуванням».
Сторонні (3P) сервери MCP
MCP Gateway слугує централізованим шаром оркестрації для всієї взаємодії через MCP в Uber, забезпечуючи безшовну підтримку сторонніх інтеграцій, таких як Jira та Google.
Підключення сторонніх серверів MCP залежить від злагодженої роботи двох ключових компонентів:
- MCP Gateway: передає токен користувача далі по ланцюгу, одночасно застосовуючи базові функції шлюзу, включно з авторизацією, обмеженням частоти запитів (rate limiting) та маскуванням конфіденційних даних.
- Сторонній сервіс MCP: обмінює внутрішній токен користувача на відповідний токен автентифікації третьої сторони перед тим, як надіслати запит до зовнішнього сервера MCP.
Авторинг та активація
Хоча ми можемо створювати сервери MCP без участі команди сервісу, право власності та контроль над сервером MCP мають залишатися за нею. Ключовий принцип дизайну MCP Gateway полягає в тому, що виявлення не означає автоматичного відкриття доступу. Кожен сервер та інструмент MCP починає роботу у вимкненому стані, і команда-власник має явно переглянути та активувати його. Власники сервісів можуть перевірити й доопрацювати згенеровані описи інструментів перед увімкненням.
Кожна зміна в описі інструменту створює diff конфігурації, який мають затвердити власники сервера. Вони можуть погодити та розгорнути зміни, а за потреби — відкотитися до попередньої відомої версії.
Рисунок 3: Інтерфейс MCP Registry.
Рисунок 4: Інтерфейс інструменту MCP.
Площина даних
Площина даних MCP Gateway — це основний runtime-сервіс, який відповідає за виконання запитів MCP. Він постійно отримує конфігурації серверів та інструментів із площини управління й оновлює свій стан у пам'яті з фіксованою періодичністю. Це дозволяє змінам конфігурації (наприклад, оновленню інструментів чи зміні їхнього статусу) набувати чинності в реальному часі без перезапуску чи передеплою сервісу.
На основі цієї конфігурації площина даних динамічно матеріалізує віртуальні сервери MCP. Для кожного віртуального сервера Gateway надає єдиний ендпоінт /<service-name>/mcp, який слугує точкою входу для виконання запитів AI-агентом. Вхідні запити спрямовуються до відповідних обробників серверів через вбудований проксі-сервер.
Рисунок 5: Площина даних MCP Gateway.
Трансляція протоколів та виконання
За трансляцію протоколів у MCP Gateway відповідають обробники серверів (server handlers) у межах Proxy Gateway. Кожен обробник «знає» як про інструменти, так і про нижчі рівні системи, що дозволяє йому коректно маршрутизувати та виконувати запити MCP у реальному часі.
Безпека
MCP Gateway забезпечує вбудовану авторизацію та маскування даних для всіх серверів із гранулярністю на рівні інструментів. Шлюз використовує внутрішню систему контролю доступу Uber, щоб застосовувати різні політики Charter, налаштовані для виявлених суб'єктів виклику (людей, сервісів та агентів). Політики Charter створюються на рівні сервера з можливістю перевизначення на рівні окремих інструментів, якщо це потрібно.
MCP Gateway також «з коробки» маскує будь-які персональні (PII) або конфіденційні дані у відповідях інструментів.
Нижчі сервіси на базі IDL
Для інструментів, що працюють на базі існуючих бекенд-сервісів, обробник сервера підтримує мапу в пам'яті, яка описує кінцевий пункт призначення — наприклад, конфігурацію HTTP-ендпоінта або процедури gRPC/TChannel.
Коли надходить запит MCP, обробник:
- Перетворює вхідний JSON-пейлоад у відповідний формат передачі даних.
- Серіалізує запит у байти Protobuf або Thrift.
- Надсилає запит до нижчого сервісу.
- Конвертує відповідь у байтах Protobuf або Thrift назад у сумісний із MCP JSON і повертає її агенту, який зробив виклик.
Сам запит до нижчого сервісу виконується через Muttley — sidecar сервісної сітки Uber, який працює поруч з усіма бекенд-сервісами. Делегуючи виконання запитів Muttley, MCP Gateway автоматично отримує переваги від існуючих можливостей маршрутизації між сервісами.
Нативні сервери MCP
Нативні сервери MCP також реєструються як віртуальні сервери в MCP Registry, який діє як проксі до оригінального сервера. Під час виконання нативні запити 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 зчитує це поле та передає масив вкладених шляхів тільки для необхідних полів. Потім Gateway у реальному часі обрізає відповідь, залишаючи лише спроєктовані поля. Це дозволило нам масштабувати сумісність схем 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, без жодних змін у нижчих сервісах.
Якщо ви будуєте агентні системи у великих масштабах, найскладніше — це не сам AI. Найскладніше — створити «сполучну тканину»: механізми виявлення, безпеку та надійність, які роблять агентів достатньо довіреними, щоб діяти від імені реальних користувачів у продакшені. MCP Gateway — наша відповідь на цей виклик, і ми сподіваємося, що задокументовані тут архітектурні рішення будуть корисними іншим, хто стикається з подібною проблемою.
Подяки
Атрибуція фото на обкладинці: згенеровано за допомогою ChatGPT від OpenAI; зовнішні зображення, логотипи чи сторонні ресурси не використовувалися.
gRPC є товарним знаком The Linux Foundation.
Слідкуйте за останніми новинами від Uber Engineering — підписуйтесь на нас у LinkedIn, щоб читати найсвіжіші статті та інсайти.
