MCP 工具太多时，别把所有描述塞进上下文

MCP 真正跑起来以后，团队最先遇到的往往不是“连不上工具”，而是“工具太多，模型根本选不准”。

当一个 Agent 只接一两个 MCP Server 时，这个问题还不明显。可一旦接入 Jira、Slack、GitHub、数据库、监控、工单和内部 API，工具数量就会快速膨胀。每个工具都有名字、描述、参数 schema，很多还带着权限和环境差异。模型要先读完这些信息，才能决定该用哪个工具。

这时候，瓶颈就不再是连接，而是发现。

为什么“全量加载”会先把上下文吃掉

MCP 官方文档的流程很直接：客户端先通过 tools/list 发现可用工具，再通过 tools/call 执行。这个设计让工具列表可以动态变化，但也意味着，默认思路仍然是“先把可用工具都摆出来，再让模型自己挑”。

问题在于，工具一多，描述、参数和返回结构都会挤占上下文。Kong 的工程文章直接指出，MCP Server 默认会把所有工具暴露出来，连接多个 Server 后，Agent 很容易在真正做事前就背上成百上千个工具描述。它把这类问题概括成两个词：权限过宽，和 context rot。

对模型来说，这不是“多一点信息更聪明”，而是“多到开始干扰选择”。

第一条是官方路线图。MCP 的 transport roadmap 已经在考虑更轻量的 discovery 机制，以及 Server Cards 这类结构化元数据，让客户端在真正握手前就能知道能力、鉴权和 primitives，而不是先完成一整轮初始化。

第二条是 AWS Prescriptive Guidance。它把 MCP 工具发现分成 static definition、dynamic discovery 和 search function 三种方式，说明“先筛选，再暴露”已经不是临时技巧，而是正式的架构选项。

第三条是研究结果。两篇 2026 年论文把问题说得更直白：

一篇对 856 个工具、103 个 MCP Server 做了实证分析，发现 97.1% 的工具描述至少有一个问题，56% 连用途都没说清。
另一篇提出语义工具发现，用向量检索把候选工具从 50-100+ 个压到通常 3-5 个；在 140 个查询、121 个工具、5 个 Server 的基准上，工具相关 token 消耗减少了 99.6%，K=3 时命中率达到 97.1%。

这说明一件事：单靠“把描述写得更长”不够，单靠“把工具全暴露出来”也不够。真正有效的是先筛选，再暴露。

如果把 MCP 当成生产系统看，比较稳的架构通常是四层：

Kong 近期推出的 MCP Registry 也在往这个方向走。它的定位不是替代工具，而是让 Agent 能动态发现工具、按环境管理访问，并摆脱硬编码配置。对多团队、多环境、多 Server 的场景，这比“每个 Agent 手写一份工具清单”更接近可维护状态。

如果你正在搭 AI 编程代理、内部助手或统一模型网关，下面几条比“再加几个工具”更重要：

从 RouterHub 这类统一路由层的视角看，模型路由和工具路由其实是同一类问题：都不是“全部打开”，而是“先判断，再放行”。前者决定用哪个模型，后者决定让模型先看到哪些工具。

MCP 进入大规模使用后，最值钱的能力不再只是“接了多少 Server”，而是“能不能让模型只看到该看的那一小撮工具”。

如果工具发现层做得好，Agent 会更快、上下文更干净、误选更少，网关和权限策略也更容易维护。反过来，工具越堆越多，模型就越像在一本没有目录的电话簿里找答案。