Uber工程团队构建MCP Gateway，为AI智能体统一接入上千个内部工具
据ByteByteGo基于公开资料的梳理，Uber用MCP Registry与Proxy Gateway两层结构，把各团队分散的MCP集成收敛为一个共享平台，并加入渐进发现、响应字段裁剪和Code Mode来缓解上下文占用。所有细节来自公开分享的二手整理。
AI解读：ByteByteGo的这篇文章整理的是Uber工程团队公开分享的MCP Gateway设计，并非ByteByteGo自己的实测。文章明确标注，内容依据多方公开细节，读者指出不准确之处后可做修正。
Uber面对的问题是：各工程团队各自搭建MCP集成，重复处理工具暴露、连接管理、权限等问题，工具分散且难以发现；同时内部服务混用HTTP、gRPC、TChannel等协议，MCP请求无法直接跨这些服务转发。
Uber的MCP Gateway分为控制面MCP Registry和数据面Proxy Gateway：前者保存服务器与工具目录、管理启停配置并作为共享事实来源，后者处理实际请求、应用控制策略并返回MCP兼容结果。
工具发现由AutoCrawler自动化完成，它基于Cadence的分布式工作流定时扫描，从IDL定义生成工具schema，并用LLM改善工具描述；原生MCP服务器则通过心跳被发现，再调用listTools注册。
新发现的服务器和工具默认处于禁用状态，需由负责该服务的团队复核并启用；每次修改以diff形式提交审批，只有通过审批的变更才会部署，且支持回滚。
网关按调用方（人、服务或AI智能体）实施访问控制，可细化到单个工具，并对个人信息等敏感字段做脱敏；调用Jira、Google等第三方服务时，由第三方服务把内部令牌换成外部认证令牌。
ByteByteGo发布文章，梳理Uber工程团队如何构建MCP Gateway，让不同AI智能体发现并使用企业内部工具。文章标注内容来自多方公开分享，并非第一手采访或实测。
文章给出的背景是：Uber各团队最初各自搭建MCP集成，重复解决工具暴露、连接管理、权限等问题，工具分散、难以查找；内部服务又混用HTTP、gRPC、TChannel等协议，MCP请求不能直接跨这些服务转发。
两层结构：Registry管目录，Proxy Gateway跑请求
文章称，Uber的MCP Gateway分为两个组件。MCP Registry是控制面，保存MCP服务器和工具的目录，同时管理配置，例如在注册表中启用或禁用一个工具，并作为共享的事实来源。Proxy Gateway是数据面，处理智能体运行时的真实MCP请求：识别被请求的工具、施加必要控制、把请求发给正确的下游服务，再返回MCP兼容的结果。
这样拆分的目的，是让工具定义与权限管理可以独立于请求处理进行。
AutoCrawler：从现有API定义自动生成工具
文章指出，为上千个服务手工编写MCP集成工作量太大且容易出错，Uber因此用AutoCrawler自动化这部分。AutoCrawler是基于Cadence的分布式工作流系统，由定时任务启动，查找新的服务、API或schema变化。
它有两条发现路径。一条读取API的Internal Definition Language定义，提取方法名、请求与响应结构，生成或更新MCP服务器表示，再翻译成MCP可识别的工具schema，并用LLM根据提取到的细节改善工具描述。另一条针对原生MCP服务器：这类服务器会发出心跳指标表明存在与就绪状态，AutoCrawler跟踪这些信号，调用其listTools操作，把工具及其schema注册为代理表示。两条路径最终汇入同一目录。
默认禁用与审批：启用权留给服务负责团队
文章特别提到一个设计选择：新发现的服务器和工具初始为禁用状态，自动发现只让能力在平台上可见。之后需由负责该服务的团队复核并启用，文章称这是所有权决策，让服务团队有机会检查工具描述是否正确。
负责团队可在Registry界面修改工具定义，每次修改都是一份需要审批的新diff，只有获批的变更才会部署，也支持回退到上一版本。数据面以固定周期刷新内存中的工具配置，因此变更生效不需要重启或重新部署服务。网关据配置生成虚拟MCP服务器，例如把日志服务暴露在logging/mcp端点，客户端像连接MCP服务器一样连这个端点。
权限、脱敏与第三方认证
文章称，网关是所有工具访问规则的统一执行点，使用Uber内部访问控制系统，按调用方身份（人、服务或AI智能体）配置策略，粒度可到服务器级，也可细化到单个工具。例如事件管理服务器同时提供读取事件和修改事件状态的工具，两者可授予不同权限。网关还能对工具响应中的个人信息或其他敏感数据进行脱敏。
对Jira、Google这类第三方服务，需要额外的身份检查：网关把调用方的内部用户令牌发给第三方服务，由后者换成外部认证令牌，再带该令牌请求外部MCP服务器。按文章描述，网关负责通用访问与执行细节，第三方服务负责外部事务。
上下文压力与三项补充机制
文章指出，工具目录规模达到上千个后，工具定义会占用模型上下文窗口，挤压系统指令、对话历史和工具返回结果的空间；API返回的详细对象也可能远超任务所需。
Uber为此在网关上加入三项机制。Omni MCP是单一代理服务器，提供discover_server、discover_tools、get_tool_schema等工具，让智能体逐步发现能力，而不是预先加载全部工具描述。Response Projection类似GraphQL的做法，在工具请求中注入字段，告诉网关响应应包含哪些字段，其余字段由网关移除。Code Mode让编码智能体用shell命令和文件处理结果。
文章给出的事实边界
文章将MCP Gateway的效果描述为把分散的集成收敛为统一、可扩展的平台，任何团队可在几分钟内接入；核心思路是复用现有API，不要求团队重写服务。这些是文章对Uber设计的概括，文中没有给出接入团队数量、延迟、上下文节省比例等可核验数据。
文章也明确，其内容依据公开分享细节整理，并邀请读者指出不准确之处。因此上述机制可作为理解Uber公开设计的参考，不宜当作经过独立验证的生产指标。