Designing MCP Gateway Uber's MCP Management Platform设计 MCP Gateway：Uber 的 MCP 管理平台

Introduction简介

Uber’s rapid adoption of AI agents has fundamentally changed how teams interact with code, data, and operational systems.  Early ad-hoc integrations with the MCP (Model Context Protocol) showed clear value: agents became dramatically more capable when they could access live business context, query internal services, and take meaningful actions on behalf of users. These early wins validated MCP as a powerful abstraction for building agentic systems inside Uber.Uber 对 AI 智能体的快速采纳，从根本上改变了团队与代码、数据以及运营系统的交互方式。早期与 MCP（模型上下文协议）的临时集成展现出了明显的价值：当智能体能够获取实时业务上下文、查询内部服务并代表用户采取有意义的操作时，其能力得到了显著提升。这些早期的成功验证了 MCP 作为在 Uber 内部构建智能体系统的一种强大抽象手段的地位。

However, as adoption accelerated, significant challenges emerged. Individual teams independently built integrations, leading to fragmentation in tooling and duplicated infrastructure. MCP tools were hard to discover, difficult to operate reliably, and tightly coupled to specific services or agent implementations. While these approaches worked at a small scale, they didn’t meet Uber’s needs as hundreds of teams began exploring agentic workflows. Without a unified architecture, scaling MCP would increase operational complexity, security risk, and developer friction, ultimately limiting its impact. 然而，随着采纳速度的加快，重大挑战随之而来。各团队独立构建集成，导致工具碎片化和基础设施重复建设。MCP 工具难以发现、难以可靠运行，且与特定服务或智能体实现紧密耦合。虽然这些方法在小规模环境下行之有效，但随着数百个团队开始探索智能体工作流，它们已无法满足 Uber 的需求。如果没有统一的架构，扩展 MCP 将增加运营复杂度、安全风险和开发阻力，最终限制其影响力。

To unlock MCP’s full potential at Uber’s scale, we needed a centralized, scalable solution to standardize how AI agents interact with existing back-end systems while preserving flexibility for teams. This solution needed to abstract protocol differences (HTTP, gRPC™, TChannel), enforce consistent security and observability guarantees, and make MCP tools easy to create, discover, and reuse across the company.为了在 Uber 的规模下充分释放 MCP 的潜力，我们需要一个集中且可扩展的解决方案，以标准化 AI 智能体与现有后端系统的交互方式，同时为各团队保留灵活性。该解决方案需要抽象协议差异（HTTP、gRPC™、TChannel），强制执行一致的安全和可观测性保障，并使 MCP 工具易于在全公司范围内创建、发现和复用。

We built the MCP Gateway to address this need. It’s a foundational microservice that powers all MCP interactions at Uber, serving as an orchestration and routing layer between AI agents and existing back-end services and native MCP servers. By centralizing MCP logic into a single gateway, we provide a consistent execution model for agent-to-service interactions while eliminating the need for teams to reinvent core infrastructure. Existing APIs can be seamlessly exposed as MCP tools, governed and operated in one place, and consumed by multiple agents in a uniform way. MCP Gateway unlocked a scalable, fast, and consistent path to building AI agents within Uber and is currently hosting over 800 MCP servers and over 5000 tools.我们构建了 MCP Gateway 来应对这一需求。它是一个基础微服务，为 Uber 的所有 MCP 交互提供支持，充当 AI 智能体与现有后端服务及原生 MCP 服务器之间的编排和路由层。通过将 MCP 逻辑集中到一个网关中，我们为智能体与服务的交互提供了一致的执行模型，同时消除了团队重复构建核心基础设施的必要。现有的 API 可以无缝地作为 MCP 工具公开，并在一个地方进行管理和运营，供多个智能体以统一的方式消费。MCP Gateway 为在 Uber 内部构建 AI 智能体开辟了一条可扩展、快速且一致的途径，目前托管着超过 800 个 MCP 服务器和 5000 多个工具。

Figure 1: MCP Gateway (APIs as tools).  图 1：MCP Gateway（将 API 作为工具）。

The Gateway网关

MCP Gateway follows a microservice-based architecture, with the gateway acting as the central integration point between AI-enabled systems and Uber’s back-end services. The platform comprises two primary components: the MCP Registry, which serves as the control plane, and the Proxy Gateway, which forms the data plane.MCP Gateway 遵循微服务架构，网关充当 AI 赋能系统与 Uber 后端服务之间的核心集成点。该平台包含两个主要组件：作为控制平面的 MCP 注册中心（MCP Registry），以及构成数据平面的代理网关（Proxy Gateway）。

The MCP Registry maintains a catalog of hundreds of MCP servers backed by internal services, along with thousands of MCP tools. These tools range from no-code definitions that expose existing APIs as MCP tools to fully native implementations built explicitly against the MCP specification. The registry provides a single source of truth for discovery, ownership, and enablement across the ecosystem.MCP 注册中心维护着一个由内部服务支撑的数百个 MCP 服务器的目录，以及数千个 MCP 工具。这些工具涵盖了将现有 API 公开为 MCP 工具的无代码定义，以及专门针对 MCP 规范构建的原生实现。注册中心为整个生态系统的发现、所有权和启用提供了一个单一事实来源。

The Proxy Gateway is responsible for executing MCP requests at runtime. It translates MCP protocol calls into HTTP, gRPC, or TChannel requests, forwards them to the appropriate back-end service, and converts the responses back into MCP-compatible results. This translation layer allows AI agents to interact with existing systems through a consistent MCP interface, without requiring changes to the underlying services.代理网关负责在运行时执行 MCP 请求。它将 MCP 协议调用转换为 HTTP、gRPC 或 TChannel 请求，将其转发到相应的后端服务，并将响应转换回 MCP 兼容的结果。这种转换层允许 AI 智能体通过一致的 MCP 接口与现有系统交互，而无需更改底层服务。

Control Plane控制平面

Uber has a microservice architecture and operates with thousands of internal services that expose APIs over HTTP, gRPC, and TChannel. These APIs provide valuable context to an AI system, but asking teams to manually author an MCP server would be slow and painful. To solve this problem, we built AutoCrawler, which continuously scans Uber’s IDL registry for APIs, translates them, and updates them in the registry. It also queries native MCP servers and adds them to the registry.Uber 采用微服务架构，运行着数千个通过 HTTP、gRPC 和 TChannel 公开 API 的内部服务。这些 API 为 AI 系统提供了宝贵的上下文，但要求团队手动编写 MCP 服务器既缓慢又痛苦。为了解决这个问题，我们构建了 AutoCrawler，它持续扫描 Uber 的 IDL 注册中心以获取 API，对其进行转换，并在注册中心中进行更新。它还会查询原生 MCP 服务器并将它们添加到注册中心。

AutoCrawler: Discovery EngineAutoCrawler：发现引擎

Autocrawler is a Cadence-powered distributed workflow system subscribed to Uber’s IDL registry and internal service signals. On a fixed schedule, a cron job triggers a Cadence workflow that scans for newly added services, APIs, and schema changes.AutoCrawler 是一个由 Cadence 驱动的分布式工作流系统，订阅了 Uber 的 IDL 注册中心和内部服务信号。按照固定计划，定时任务会触发一个 Cadence 工作流，扫描新添加的服务、API 和模式变更。

For every discovered entity, AutoCrawler is responsible for:对于每个发现的实体，AutoCrawler 负责：

• Creating or updating MCP server representations创建或更新 MCP 服务器表示
• Generating or fetching tool definitions and schemas生成或获取工具定义和模式
• Registering tools in the MCP Registry in a disabled-by-default state在 MCP 注册中心中以默认禁用状态注册工具

This shared foundation enables MCP discovery to scale across thousands of services while keeping service teams off the critical path.这一共享基础使 MCP 发现能够跨越数千个服务进行扩展，同时让服务团队不必处于关键路径上。

Figure 2: Auto Crawler. 图 2：Auto Crawler。

Discovery for IDL-Backed Services

For traditional back-end services defined through Protobuf or Thrift IDLs, AutoCrawler derives MCP servers and tools directly from the IDL Registry. For each service:API group, AutoCrawler performs the following steps:对于通过 Protobuf 或 Thrift IDL 定义的传统后端服务，AutoCrawler 直接从 IDL 注册中心派生 MCP 服务器和工具。对于每个服务:API 组，AutoCrawler 执行以下步骤：

• Upsert MCP server: Creates or updates a virtual MCP server corresponding to the discovered service.更新 MCP 服务器：创建或更新与所发现服务对应的虚拟 MCP 服务器。
• Parse IDL definitions: Parses the associated protobuf or Thrift files to extract method names, request and response schemas, and documentation comments.解析 IDL 定义：解析关联的 protobuf 或 Thrift 文件，以提取方法名称、请求和响应模式以及文档注释。
• Generate tool descriptions: Uses an LLM to generate enriched, agent-friendly MCP tool descriptions based on the extracted schemas and comments.生成工具描述：使用大语言模型（LLM）根据提取的模式和注释生成丰富的、对智能体友好的 MCP 工具描述。
• Schema translation: Translates protobuf or Thrift schemas into MCP-compatible JSON-RPC 2.0 schemas.模式转换：将 protobuf 或 Thrift 模式转换为 MCP 兼容的 JSON-RPC 2.0 模式。
• Upsert MCP tools: Registers or updates the generated MCP tools in the MCP Registry in a disabled-by-default state.更新 MCP 工具：在 MCP 注册中心中以默认禁用状态注册或更新生成的 MCP 工具。

Discovery for Native Servers原生服务器的发现

In addition to IDL-backed services, the MCP Gateway also supports native MCP servers—services that implement the MCP protocol directly and expose agent-optimized tools.除了 IDL 支撑的服务外，MCP Gateway 还支持原生 MCP 服务器——即直接实现 MCP 协议并公开针对智能体优化工具的服务。

MCPFx is the framework Uber uses to build native MCP servers. Each native MCP server emits a heartbeat metric that signals its presence and readiness. AutoCrawler continuously monitors these heartbeat signals to automatically discover new native MCP servers. When a native MCP server is discovered, AutoCrawler follows a different discovery path:MCPFx 是 Uber 用于构建原生 MCP 服务器的框架。每个原生 MCP 服务器都会发出一个心跳指标，以指示其存在和就绪状态。AutoCrawler 会持续监控这些心跳信号，以自动发现新的原生 MCP 服务器。当发现原生 MCP 服务器时，AutoCrawler 会遵循不同的发现路径：

1. It makes a listTools call to the native MCP server to retrieve the tools it explicitly exposes, along with their schemas.它向原生 MCP 服务器发起 listTools 调用，以检索其显式公开的工具及其模式。
2. It creates a virtual proxy MCP server in the MCP Registry that contains all discovered tools and their schemas, in a disabled-by-default state.它在 MCP 注册中心中创建一个虚拟代理 MCP 服务器，其中包含所有已发现的工具及其模式，并处于默认禁用状态。

3P MCP Servers第三方（3P）MCP 服务器

The MCP Gateway serves as the centralized orchestration layer for all MCP interactions across Uber, extending seamless support to third-party integrations such as Jira and Google. MCP Gateway 作为 Uber 所有 MCP 交互的集中式编排层，为 Jira 和 Google 等第三方集成提供了无缝支持。

Provisioning third-party MCP servers relies on the co-operation of two key components:第三方 MCP 服务器的配置依赖于两个关键组件的协作：

1. MCP Gateway: Relays the caller's user token downstream while enforcing essential gateway capabilities, including authorization, rate limiting, and sensitive data redaction.MCP Gateway：在向下游中继调用者用户令牌的同时，强制执行必要的网关功能，包括授权、速率限制和敏感数据脱敏。
2. Third-Party MCP Service: Exchanges the internal user token for a corresponding third-party authentication token before dispatching the request to the external MCP server.第三方 MCP 服务：在将请求分发到外部 MCP 服务器之前，将内部用户令牌交换为相应的第三方身份验证令牌。

Authoring and Enablement编写与启用

While we may create MCP servers without involving the service team, ownership and control of the MCP server must reside with the service team. A core design principle of the MCP Gateway is that discovery doesn’t imply exposure. Every MCP server and tool starts in a disabled state and must be explicitly reviewed and enabled by the owning team. Service owners can review and refine the generated tool definitions before enabling them.  虽然我们可以在不涉及服务团队的情况下创建 MCP 服务器，但 MCP 服务器的所有权和控制权必须归属于服务团队。MCP Gateway 的核心设计原则是：发现并不意味着公开。每个 MCP 服务器和工具最初都处于禁用状态，必须经过所有团队的明确审查和启用。服务所有者可以在启用之前审查和完善生成的工具定义。

Every change to the tool description triggers a config change diff, which must be approved by server owners. Owners can approve and deploy the config change, and, if needed, roll back to a previous known version.对工具描述的每一次更改都会触发配置变更差异（diff），该差异必须由服务器所有者批准。所有者可以批准并部署配置变更，并在需要时回滚到之前的已知版本。

Figure 3: MCP Registry UI.图 3：MCP 注册中心 UI。

Figure 4: MCP tool UI.图 4：MCP 工具 UI。

Data Plane

The MCP Gateway data plane is the core runtime service responsible for executing MCP requests. It continuously consumes server and tool configurations from the control plane and refreshes its in-memory state at a fixed cadence, allowing configuration changes, such as tool updates or enablement changes, to take effect in real time without service restarts or redeployments.  MCP Gateway 数据平面是负责执行 MCP 请求的核心运行时服务。它持续从控制平面消费服务器和工具配置，并以固定节奏刷新其内存状态，从而允许配置变更（如工具更新或启用状态更改）实时生效，而无需重启服务或重新部署。

Based on this configuration, the data plane dynamically materializes virtual MCP servers. For each virtual server, the Gateway exposes a single /<service-name>/mcp endpoint that serves as the entry point for AI agent execution. Incoming requests are resolved to their corresponding server handlers through a built-in proxy server.基于此配置，数据平面动态实例化虚拟 MCP 服务器。对于每个虚拟服务器，网关都会公开一个 /<service-name>/mcp 端点，作为 AI 智能体执行的入口点。传入的请求通过内置代理服务器解析到其对应的服务器处理程序。

Figure 5: MCP Gateway Data Plane. 图 5：MCP Gateway 数据平面。

Protocol Translation and Execution

Protocol translation in the MCP Gateway is handled by server handlers within the Proxy Gateway. Each server handler is tool-aware and downstream-aware, allowing it to correctly route and execute MCP requests at runtime.MCP Gateway 中的协议转换由代理网关内的服务器处理程序处理。每个服务器处理程序都具有工具感知和下游感知能力，使其能够在运行时正确路由和执行 MCP 请求。

Security安全性

MCP Gateway provides built-in authorization and redaction for all servers at tool-level granularity. MCP gateway uses Uber’s internal Access Control System to apply different charter policies configured on detected caller actors  (humans, services, and agents). Charter policies are created at the server level with optional tool-level overrides if required.MCP Gateway 为所有服务器提供工具级别的细粒度内置授权和脱敏功能。MCP Gateway 使用 Uber 的内部访问控制系统，根据检测到的调用主体（人类、服务和智能体）应用不同的章程策略。章程策略在服务器级别创建，并可根据需要进行可选的工具级别覆盖。

MCP Gateway also does out-of-the-box redaction for any PII or sensitive data from the tool responses. MCP Gateway 还对工具响应中的任何 PII（个人身份信息）或敏感数据进行开箱即用的脱敏处理。

IDL-Backed Downstream ServicesIDL 支撑的下游服务

For tools backed by existing back-end services, the server handler maintains an in-memory mapping that describes the downstream destination, such as HTTP endpoint config or gRPC/TChannel procedures. 对于由现有后端服务支撑的工具，服务器处理程序维护一个内存映射，描述下游目标，例如 HTTP 端点配置或 gRPC/TChannel 过程。

When an MCP request arrives, the handler:当 MCP 请求到达时，处理程序会：

1. Translates the incoming JSON payload into the appropriate wire format.将传入的 JSON 有效负载转换为适当的线路格式。
2. Serializes the request into Protobuf or Thrift bytes.将请求序列化为 Protobuf 或 Thrift 字节。
3. Forwards the request to the downstream service.将请求转发到下游服务。
4. Translates the Protobuf or Thrift byte responses back to MCP-compatible JSON, and returns to the calling agent.将 Protobuf 或 Thrift 字节响应转换回 MCP 兼容的 JSON，并返回给调用智能体。

The actual downstream request is executed via Muttley, Uber’s service mesh sidecar that runs alongside all back-end services. By delegating request execution to Muttley, the MCP Gateway automatically benefits from existing service-to-service routing capabilities. 实际的下游请求通过 Muttley 执行，这是 Uber 与所有后端服务一起运行的服务网格边车（sidecar）。通过将请求执行委托给 Muttley，MCP Gateway 自动受益于现有的服务间路由能力。

Native MCP Servers原生 MCP 服务器

Native MCP servers are also registered as virtual servers in the MCP registry, which acts as a proxy to the original server. At runtime, ‌native MCP requests are transparently proxied to the downstream server and responses are proxied back to the caller. 原生 MCP 服务器也作为虚拟服务器注册在 MCP 注册中心中，该注册中心充当原始服务器的代理。在运行时，原生 MCP 请求被透明地代理到下游服务器，响应则被代理回调用者。

Benefits of the Gateway网关的优势

By building the MCP-Gateway, Uber has achieved a scalable and unified approach towards building agentic systems, with most impactful benefits coming from:通过构建 MCP Gateway，Uber 实现了一种可扩展且统一的智能体系统构建方法，其最具影响力的优势包括：

• Easy discovery and installation易于发现和安装
• No-code approach towards existing APIs针对现有 API 的无代码方法
• Built-in observability and security内置的可观测性和安全性
• Centralized ownership and governance 集中的所有权和治理

Extending the Gateway扩展网关

Scaling MCP Gateway to hundreds of servers and thousands of tools revealed problems that don’t exist at small scale. Context Bloat and Excessive Cost将 MCP Gateway 扩展到数百个服务器和数千个工具后，我们发现了小规模下不存在的问题：上下文膨胀和过高的成本。

Runtime Discovery运行时发现

MCP has no native concept of cross-server search. An agent has to already know which server to talk to before it can ask what tools are available. Configuring an agent to use an MCP server requires explicitly wiring up the server URL, credentials, and tool list. Doing this for hundreds of servers doesn’t scale, as all this context would eat up the model context limit. We solved this problem with the following MCP 本身没有跨服务器搜索的概念。智能体必须预先知道要与哪个服务器通信，才能询问有哪些可用工具。配置智能体使用 MCP 服务器需要显式连接服务器 URL、凭据和工具列表。为数百个服务器执行此操作无法扩展，因为所有这些上下文都会耗尽模型的上下文限制。我们通过以下方式解决了这个问题：

• Omni MCP  - A single proxy server that allows MCP clients to access any of the MCP Gateway’s servers with a gradual discovery pattern, which also unlocks context/token optimization via incremental discovery.  Omni MCP exposes these tools.Omni MCP —— 一个单一的代理服务器，允许 MCP 客户端通过渐进式发现模式访问 MCP Gateway 的任何服务器，这也通过增量发现实现了上下文/令牌优化。Omni MCP 公开了以下工具：
• • discover_server - discover MCP server based on the query intentdiscover_server - 根据查询意图发现 MCP 服务器
  • discover_tools - lookup tools for a serverdiscover_tools - 查找服务器的工具
  • get_tool_schema - get the json schema for a toolget_tool_schema - 获取工具的 JSON 模式
  • invoke_tool  - invoke a toolinvoke_tool - 调用工具

Together, these tools enable incremental discovery and access to all MCP servers, with built-in access control and the rest of the gateway features.这些工具共同实现了对所有 MCP 服务器的增量发现和访问，并具备内置的访问控制和其余网关功能。

• Response Projection - MCP Gateway also offers Response Projection, a GraphQL-like calling pattern for MCP tools. It works by injecting a new field in the tool request schema, which instructs the gateway to request only the needed fields, not all. The LLM reads and injects the fields with an array of nested paths of only required fields. The Gateway then trims the response in runtime by only keeping the projected fields. This has allowed us to scale the API schema compatibility for MCP at the enterprise level.响应投影（Response Projection）—— MCP Gateway 还提供响应投影，这是一种针对 MCP 工具的类似 GraphQL 的调用模式。它的工作原理是在工具请求模式中注入一个新字段，指示网关仅请求所需的字段，而不是全部。LLM 读取并注入仅包含所需字段的嵌套路径数组。网关随后在运行时通过仅保留投影字段来修剪响应。这使我们能够在企业层面扩展 MCP 的 API 模式兼容性。
• Code Mode - Coding agents often operate in shell environments where writing tool output directly to files is more efficient than loading full responses into model context. Code Mode serves this pattern through aifx, Uber's CLI for agentic operations, routing MCP calls through the gateway without requiring any MCP server to be installed. It helps agents discover correct MCP tools for the job without the MCP definition being present in context. aifx exposes three commands:代码模式（Code Mode）—— 编码智能体通常在 shell 环境中运行，在这种环境中，将工具输出直接写入文件比将完整响应加载到模型上下文中更有效。代码模式通过 aifx（Uber 用于智能体操作的 CLI）支持这种模式，通过网关路由 MCP 调用，而无需安装任何 MCP 服务器。它帮助智能体在上下文中没有 MCP 定义的情况下发现正确的 MCP 工具来完成工作。aifx 公开了三个命令：
• • aifx mcp list - list available MCP serversaifx mcp list - 列出可用的 MCP 服务器
  • aifx mcp search - search for tools across all MCP serversaifx mcp search - 在所有 MCP 服务器中搜索工具
  • aifx mcp call - invoke an MCP tool through MCP Gatewayaifx mcp call - 通过 MCP Gateway 调用 MCP 工具

Agents can chain these in a single command and write output to files, which filesystem agents grep selectively, loading only what they need into context. Code Mode is now the company default for MCP tool use in coding agents.智能体可以在单个命令中链接这些操作并将输出写入文件，文件系统智能体有选择地 grep 这些文件，仅将它们需要的内容加载到上下文中。代码模式现在是公司内部编码智能体使用 MCP 工具的默认方式。

Conclusion结论

Building the MCP Gateway has fundamentally changed how AI agents operate at Uber. What began as a fragmentation problem, with dozens of teams independently wiring up MCP integrations with inconsistent tooling, no shared security guarantees, and duplicated infrastructure,  is now a unified, scalable platform that any team can plug into in minutes. 构建 MCP Gateway 从根本上改变了 AI 智能体在 Uber 的运作方式。最初的碎片化问题——数十个团队独立连接 MCP 集成，工具不一致，没有共享的安全保障，基础设施重复——现在已转变为一个任何团队都可以在几分钟内接入的统一、可扩展的平台。

The core insight driving our design was simple: existing APIs are the fastest way to provide tools to an agent. Rather than asking teams to rewrite their services for an agentic world, MCP Gateway meets them where they are—translating HTTP, gRPC, and TChannel calls into MCP-compatible interactions transparently, through Muttley, with zero changes to downstream services.推动我们设计的核心洞察很简单：现有的 API 是为智能体提供工具的最快途径。MCP Gateway 没有要求团队为智能体世界重写服务，而是与他们保持一致——通过 Muttley 透明地将 HTTP、gRPC 和 TChannel 调用转换为 MCP 兼容的交互，且无需对下游服务进行任何更改。

If you’re building agentic systems at scale, the hardest part isn’t the AI. It’s building the connective tissue—the discovery, the security, the reliability  that makes agents trustworthy enough to act on behalf of real users in a production environment. MCP Gateway is our answer to that challenge, and we hope the design decisions documented here are useful to others facing the same problem.如果你正在大规模构建智能体系统，最困难的部分不是 AI 本身，而是构建连接组织——即发现、安全和可靠性——这些使得智能体足够值得信赖，能够在生产环境中代表真实用户采取行动。MCP Gateway 是我们应对这一挑战的答案，我们希望这里记录的设计决策对面临同样问题的其他人有所帮助。

Acknowledgments致谢

Cover Photo Attribution: Generated with ChatGPT by OpenAI; no external images, logos, or third-party assets used.封面图片来源：由 OpenAI 的 ChatGPT 生成；未使用任何外部图像、徽标或第三方资产。

gRPC is a trademark of The Linux Foundation. gRPC 是 Linux 基金会的商标。

Stay up to date with the latest from Uber Engineering—follow us on LinkedIn for our newest blog posts and insights.随时了解 Uber 工程的最新动态——请在 LinkedIn 上关注我们，获取我们最新的博客文章和见解。