为每个智能体提供单一端点，而非每个仓库 20 份 MCP 配置。

背景

该平台团队为分布于十余个产品小组中的约六十名工程师提供支持。在采用 MCP 的一年间，各小组各自将所需的服务器——GitHub、Postgres、Linear、Sentry，以及一款内部部署工具——直接接入 Claude Code 与 Cursor 的配置之中。每个仓库皆携带各自的 mcp.json，而引入一款新工具则意味着须向每一个需要它的项目提交拉取请求。

此种做法尚可运转，却难以扩展。二十余个服务器如今在数十份配置文件中重复出现，各自版本略有差异，凭证则由最初完成配置者随手粘贴其中。

挑战

以下三个问题在回顾会议中反复出现。

• 配置蔓延。 新增或升级一个服务器都须改动每个仓库。配置逐渐漂移，无人能确切说清哪个小组拥有哪些工具。
• 凭证所在失当。 个人访问令牌与 API 密钥散落于开发者机器之上，偶尔更会进入已提交的配置。轮换一枚泄露的令牌宛如大海捞针。
• 拥挤的上下文窗口。 每个 MCP 服务器都会在每次请求时将其完整的工具模式推入提示。在接入二十个服务器的情形下，智能体在看到实际任务的第一行之前，便已将大量上下文耗费于工具定义。

方法

该团队搭建了单一的 onemcp 门户，将其服务器一次性纳入其中，并就地对每个上游完成鉴权。各客户端不再各自与每个服务器通信，而是统一与门户通信，再由门户向各上游分发。

有两点改变了问题的形态：

• 以单一端点取代众多端点。 仓库不再罗列服务器，而是将 Claude Code 或 Cursor 指向门户 URL，即可继承整套经过甄选的工具。更换或升级服务器仅需在门户中执行一次。
• 以 Code Mode 取代成堆的定义。 门户不再预先注入每一份工具模式，而是仅暴露三个元工具——search、describe 与 execute。智能体自行发现某项任务所需的少数工具，并在一次往返中通过单个脚本予以调用。

落地

迁移历时两周，逐个小组推进。对每个仓库，团队删除其本地服务器清单，并置入单一门户条目。由于凭证已由门户保管，开发者在此过程中亦将令牌从各自机器上一并移除。

平台团队将门户作为唯一的管控点：新服务器经集中审核后加入，访问权限亦在同一处管理，而非散布于数十份 mcp.json 之中。

结果

• 20 余个服务器汇于单一端点之后。 各仓库引用同一个门户 URL。新增一款工具是一次门户变更，而非一次波及全体仓库的拉取请求。
• 每次请求的工具开销降低约 90%。 以三个元工具取代数百份预加载定义，使每次请求的工具开销从约 15,000 个令牌降至约 500 个——智能体得以将这部分上下文用于任务本身。
• 凭证移至服务端。 上游 OAuth 与令牌驻留于门户之内，绝不进入客户端配置或已提交文件。轮换只需在一处完成一次更新。

我们不再于拉取请求中提交 MCP 配置。如今仓库只需指向一个端点即可获得全部工具，令牌亦由安全团队而非我们掌管。

相关案例研究

• 某 AI 客服智能体的令牌瘦身
• 在不泄露凭证的前提下实现自助式数据智能体