1. Designing MCP Gateway Uber’s MCP Management Platform

推荐理由： 这是少见的企业级 MCP 平台完整实践。Uber 没有让每个团队各自部署 MCP server，而是把已有 HTTP / gRPC / TChannel API 自动转成 Agent 可发现、可治理的工具，再由统一 Gateway 承载 discovery、authorization、redaction、runtime routing 和 context 控制。平台目前已托管 800+ MCP servers、5000+ tools。

核心要点：

  • MCP Gateway 被明确拆成 control plane 与 data plane：Registry 维护 tool catalog、ownership 和 enablement；Proxy Gateway 在运行时把 MCP JSON-RPC 转成已有 HTTP / gRPC / TChannel 调用。AutoCrawler 再从 IDL registry 自动发现 API、生成 schema 和 agent-friendly tool descriptions，并默认以 disabled 状态注册，避免每个业务团队重复建设 Agent integration。
  • 当工具数量进入几千级，关键问题从“能不能连接”变成“怎样不把所有 tool schema 塞进 context”。Uber 的 aifx mcp search/list/call 让 coding agent 在 shell 中按需发现并调用工具，并把大响应先写入文件，再通过 grep 等方式选择性加载；Code Mode 已成为 Uber coding agent 使用 MCP 的默认方式。
  • Gateway 也是统一治理边界：它按 human / service / agent actor 应用 server 或 tool 级 authorization，并对返回结果做敏感信息过滤；Response Projection 还允许 Agent 只请求真正需要的字段，从源头减少无用 context。

核心启示：企业 Context Engineering 最终很可能不是“建设一个更大的知识库”，而是建设一个统一的 tool/context control plane：自动发现现有能力、按需暴露、最小化返回、统一鉴权，让不同 Agent 共用同一套组织能力。

推荐理由： 这篇把“动态加载工具”从经验做法变成了一个可测量的 retrieval 问题。Conversion 的 Agent 已有 114 个工具，团队没有继续把完整 catalog 塞进 prompt，而是把 tool selection 独立成一个 decision layer，并用真实 benchmark 比较 lexical、BM25、原生 tool search 和 Jev 的效果、精度与成本。

核心要点：

  • Tool search 需要理解任务链，而不只是关键词相似度。很多请求依赖前置步骤，例如先找到 Airtable base ID，再读取 schema；单纯 lexical search 很容易命中相关工具，却漏掉真正完成任务所需的 prerequisite。
  • 在冻结配置后的 100 个新请求上，Jev 在共享的 95 个有效比较任务中实现 84/95 complete retrieval、80.3% precision；多步骤任务里覆盖全部 required capabilities 的结果是 43/47，而 local BM25 为 19、lexical 为 12。它平均暴露的工具不到 2 个。
  • Context reduction 很显著：114 个工具完整定义平均约 153.32 kB，Jev 选择后的定义平均约 2.68 kB。团队模拟 30-turn、6 次 tool search 的会话时，预计 tool-input + search 成本从约 74 美分降到 20 美分，约 73%；同时保留“找不到合适工具时返回空集合”的能力。

核心启示：Tool selection 应该像 retrieval 一样拥有独立 benchmark。真正可扩展的 Agent 不应预加载所有能力，而应使用 task intent → capability retrieval → minimal tool set → execution 的动态路径，并把 recall、precision、context size 和 cost 一起作为 eval。