Uber 构建 MCP Gateway：把 Agent 工具接入拆成注册表与代理网关

• 架构拆分：MCP Registry 作为控制面维护 MCP 服务器与工具目录、配置启停和共享事实源；Proxy Gateway 作为数据面处理实际 MCP 请求，识别目标工具、执行访问控制并转发到后端服务。
• 工具发现：AutoCrawler 基于 Cadence 分布式工作流，从现有 API 的 IDL 或原生 MCP server 的心跳与 listTools 响应中提取方法、请求响应结构和输入 schema，并用 LLM 生成工具描述后注册。
• 权限边界：新发现工具默认处于禁用状态，需服务 owner 审核描述并批准变更后才部署；访问策略可按调用者（人、服务或 Agent）配置，并细化到单个工具，同时支持响应中的 PII 脱敏。第三方服务需将内部用户 token 换取外部认证 token。
• 请求转换：Gateway 将工具 JSON 参数转换为 gRPC Protobuf、HTTP 或 TChannel/Thrift 所需格式，再把后端响应转回 MCP 兼容结果；配置定期刷新到内存，工具变更无需重启或重新部署。
• 上下文规模控制：面对上千个工具，Omni MCP 提供 discover_server、discover_tools、get_tool_schema 等渐进发现能力；Response Projection 按请求字段裁剪工具响应；Code Mode 让编码 Agent 通过 shell 命令和文件处理结果。
• 行业意义：生产级 Agent 工具接入的工程量集中在发现、权限、可靠性与上下文控制。Uber 的路径是复用既有 API 作为工具来源，由统一网关承担连接、鉴权与格式转换，而不是要求各团队重写服务。

🔗 ByteByteGo 解析 | Uber Engineering Blog | Model Context Protocol