Scaling Model Context Protocol (MCP) Infrastructure for Enterprise Agentic AI

uber · Tech · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: enterprise agent platform infrastructure

Uber needed a standardized way for a large population of agents and engineers to access thousands of internal services through MCP without creating ungoverned custom integrations, unsafe data access, or poor-quality tools.

Constraints:

More than 5,000 engineers and thousands of non-engineering users were already using agentic workflows.
The platform had to work across more than 10,000 services and 1,500 monthly active internal agents.
Security, privacy, governance, discovery, and tool quality had to be centralized without blocking service-owner control.

Architecture

Uber built an MCP Gateway and Registry as the control plane for MCP interactions. A gateway orchestrator crawls proto/thrift IDLs, uses an LLM to generate MCP tool descriptions, stores definitions in object storage, and lets the gateway service expose MCP servers to Agent Builder, Agent SDK, and coding-agent consumers. Service owners control exposed tools and descriptions, while authorization, PII redaction, scanning, observability, and guardrails govern access.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  A["Service IDLs"] --> B["MCP gateway orchestrator"]
  B --> C["LLM tool-description generator"]
  C --> D["Object storage and registry"]
  B --> D
  D --> E["MCP gateway service"]
  F["Service owners"] --> E
  F --> G["Security scanning APIs"]
  G --> D
  H["Authorization and PII services"] --> E
  E --> I["Agent Builder"]
  E --> J["Agent SDK"]
  E --> K["Coding agents"]

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Service IDLs`	Proto and thrift definitions for Uber's service endpoints.	`MCP gateway orchestrator`
`MCP gateway orchestrator`	Crawls service IDLs and triggers MCP definition generation.	`Service IDLs`, `LLM tool-description generator`, `Object storage and registry`
`LLM tool-description generator`	Generates MCP tool descriptions from IDL message names and comments.	`MCP gateway orchestrator`, `Object storage and registry`
`Object storage and registry`	Stores MCP definitions and acts as the discoverable source of truth for MCP versions.	`MCP gateway orchestrator`, `LLM tool-description generator`, `MCP gateway service`, `Security scanning APIs`
`MCP gateway service`	Serves MCP servers and exposes definitions to consuming agent surfaces.	`Object storage and registry`, `Service owners`, `Authorization and PII services`, `Agent Builder`, `Agent SDK`, `Coding agents`
`Service owners`	Domain experts who choose exposed tools and refine LLM-facing descriptions.	`MCP gateway service`, `Security scanning APIs`
`Security scanning APIs`	Scan diffs and metadata before MCP definition changes are committed.	`Service owners`, `Object storage and registry`
`Authorization and PII services`	Centrally enforce access controls and redact sensitive data.	`MCP gateway service`
`Agent Builder`	No-code agent surface that scopes MCP servers and tools through system instructions and UI choices.	`MCP gateway service`
`Agent SDK`	Code-first surface that loads selected MCP tools from YAML configuration.	`MCP gateway service`
`Coding agents`	Developer companions that add and use MCP servers for software engineering workflows.	`MCP gateway service`

Data flow

Service IDLs are crawled by the MCP gateway orchestrator; an LLM generates tool descriptions from message names and comments; definitions are stored in object storage/registry; the gateway service loads and serves MCP servers to no-code agents, SDK agents, and coding agents; service-owner updates flow through diffs and security scans before redeploying to storage and the gateway.

3 supporting quotes

“The gateway orchestrator crawls all of these IDLs, which are proto and thrift files. Then it calls an LLM to generate MCP tool descriptions.”transcript, stated

“The gateway service then has a conflict provider that's going to pick up these definitions and serves these MCP servers to the different consumers we have at Uber”transcript, stated

“the scan report is attached to the diff and the diff is committed and deployed to our object storage.”transcript, stated

Why this architecture

Uber centralized MCP infrastructure because ad hoc server integrations were becoming non-reusable, unsafe, hard to discover, and difficult to trust in production. The gateway/registry kept service-owner expertise in the loop while enforcing consistency, security, discovery, and quality controls.

3 supporting quotes

“Without a central framework or guidance, there was no standard way to develop and deploy these MCP servers at Uber.”transcript, stated

“Think of this as the control plane for all MCP interactions at Uber.”transcript, stated

“Service owners, which are basically the experts, still stay in control of which tools actually get exposed.”transcript, stated

Models used: LLM for MCP tool-description generation · agentic workflow models · Claude · Cursor

Scale

More than 5,000 Uber engineers use AI monthly for agentic workflows.
“At Uber, we have more than 5,000 engineers with more than 90% of them using AI every single month for agentic workflows.”transcript, stated
Uber's MCP infrastructure has to span more than 10,000 services.
“The reality is of a company this big is really that we have more than 10,000 services.”transcript, stated
Uber sees more than 1,500 monthly active internal agents and over 60,000 executions per week.
“we are now seeing more than 1,500 agents just internally monthly active and over 60,000 executions per week.”transcript, stated
A coding-agent harness produces roughly 1,800 code changes per week.
“The cloud harness as well and it's actually producing about 1800 code changes a week right now.”transcript, stated
Coding-agent surfaces are used by 95% of Uber engineers.
“And it is being used by all of these are being used by 95% of our engineers across Uber.”transcript, stated

Alternatives considered (roads not taken)

Independent custom MCP integrations by each team

Rejected because: They were non-reusable, duplicated work across silos, and could not be trusted in production without a managed lifecycle.

“we had a lot of teams building out these custom integrations independently, and most of this was non-reusable.”transcript, stated

One-off standalone playground environments

Rejected because: Uber moved MCP definitions into centrally committed, code-managed infrastructure for auditability and consistency.

“We also deprecated all one-off standard playground environments that people started, you know, uh spawning off.”transcript, stated

Treating third-party MCPs the same as internal MCPs

Rejected because: External systems required more gating, scanning, and checks because of data-handling risk.

“We introduced a lot more levels of gating, scanning, and rigorous checks for the external systems compared to our own trusted internal systems.”transcript, stated

Exposing every MCP tool and parameter choice to the LLM

Rejected because: Uber reduced hallucinated tool/parameter choices by letting builders pick tools and apply parameter overrides.

“we actually allow you to pick the specific tools from the MCP server, so that the LLM doesn't have to make a decision there.”transcript, stated

Patterns

`tool-use-orchestration` (agent-architecture)

Uber standardized MCP as the way agents discover and call internal service tools across no-code, SDK, and coding-agent surfaces.

“MCPs are not just like important, they really are what make AI usable at Uber.”transcript, stated

`structured-output-contract` (integration-contracts)

The gateway turns service IDLs into MCP definitions, making service interfaces available to agents through a standardized contract.

“We now translate all Uber service endpoints into MCP tools automatically.”transcript, stated

`safety-policy-enforcement` (safety-governance)

Authorization, PII redaction, scanning, external-system gating, and guardrails enforce enterprise access and privacy policies around agent tool use.

“We integrated into our authorization service centrally, so there was no access to any data that is actually not supposed to be there.”transcript, stated

`observability-tracing` (operations)

Uber added logging, metrics, tracing, and call-pattern visibility to make MCP usage governable and debuggable at scale.

“complete visibility into the call patterns and who was accessing what data.”transcript, stated

`context-engineering` (context-management)

Agent Builder and SDK configurations scope MCP servers, selected tools, and static parameter overrides so the model sees a narrower, more reliable context.

“you can mention the MCP server name as an app mention inside the system instructions. So you can actually scope the MCP within the system instructions.”transcript, stated

Tradeoffs

MCP platform architecture

Chose central gateway and registry over decentralized team-owned MCP servers.

Rationale: Centralization enabled lifecycle management, discovery, security, and consistent tool descriptions while still letting service owners control exposure.

“We also introduced a central registry. Um this is the single source of truth to discover all the MCPs at Uber and their versions.”transcript, stated

Tool-description generation

Chose LLM-generated descriptions from IDL metadata over manual description authoring for every service endpoint.

Rationale: Automated generation scales across more than 10,000 service IDLs, while service owners can later refine descriptions.

“orchestrator, which is responsible for generating the MCP definitions from the 10,000 plus service IDLs at Uber.”transcript, stated

Consumer integration surfaces

Chose three tailored surfaces: Agent Builder, Agent SDK, and coding agents over one generic MCP consumption interface.

Rationale: Different user personas needed no-code, code-first, and IDE-agent workflows over the same MCP infrastructure.

“there's actually three main surfaces at Uber that use MCPs. One is our Uber Agent Builder”transcript, stated

LLM tool choice

Chose explicit tool selection and static parameter overrides over letting the model choose all tools and parameters dynamically.

Rationale: Constrained tool and parameter context reduces hallucinated choices and makes agents more reliable.

“what that means is the LLM doesn't have to make a decision even to pass in a parameter anymore. We can scope the parameter to something static instead.”transcript, stated

Gotchas (what bit them)

MCP proliferation became chaotic without standardization.

Root cause: Teams built custom MCP integrations independently, creating duplicate non-reusable work and no common deployment lifecycle.

Resolution: Centralize MCP development and discovery through a gateway, registry, and code-managed definitions.

“without standardization, this starts becoming chaotic very quickly.”transcript, stated

Agent blast radius is higher than human blast radius.

Root cause: Agents can access endpoints quickly and repeatedly, so accidental unauthorized access can happen faster than with human workflows.

Resolution: Centralize authorization, guardrails, PII redaction, and endpoint blocking around MCP calls.

“with agents, as you know, it's a lot faster, it's a lot quicker, and the blast radius is a lot higher.”transcript, stated

Low-quality tools degrade agent performance rather than merely failing locally.

Root cause: Agents rely on discovered tools as part of their reasoning/action loop, so unreliable or unsafe tools contaminate the whole task.

Resolution: Build registry-level quality evaluation, SLAs, and discovery tiers for MCP servers.

“Bad tools just don't fail, they also degrade the agent performance at the end of the day.”transcript, stated

Large tool catalogs create context bloat and discovery errors.

Root cause: Loading too many MCP tools into context wastes tokens and makes tool choice harder.

Resolution: Develop tool search and on-demand loading so agents can discover relevant tools without carrying the full catalog.

“That also helps us with context bloat, reduces context bloat as as well.”transcript, stated

Evaluation

Uber evaluates platform scale through adoption, agent counts, execution counts, code changes, and planned registry-level quality metrics such as evaluations, SLAs, reliability, availability, and skill-invocation correctness.

Metrics: monthly engineer AI usage · monthly active agents · weekly executions · weekly code changes · MCP reliability · MCP availability · skill output quality · skill invocation correctness · A/B test performance

“we want to extend our MCP registry to include more uh evaluation information. We want to surface the highest quality MCP servers to our users.”transcript, stated

“by exposing the evaluation metrics, by including the SLA service SLAs for these MCPs, this includes reliability and availability of the service”transcript, stated

Outcomes

Uber standardized MCP interactions for more than 5,000 engineers and thousands of non-engineering users.
The MCP platform supports more than 1,500 monthly active internal agents and over 60,000 executions per week.
The platform supports no-code agents, SDK-based production agents, and coding agents.
Uber's coding-agent harness produces about 1,800 code changes per week.

The case describes enterprise-wide MCP infrastructure at production scale, but it is a platform-team presentation and gives more adoption and throughput metrics than quality/failure-rate metrics.

“this is no longer a pilot program at Uber, it's the new standard for how we work.”transcript, stated

“Those top use cases include our grocery assistant agent our care care coordination agent as well as our customer support agent”transcript, stated