MCP 工具膨胀治理：全量加载与按需检索对比

一、问题背景：工具定义为什么会挤爆上下文

在 AI 编程工具接入 MCP（Model Context Protocol）之后，一个容易被低估的问题会迅速暴露出来：工具本身不是免费的，它们在进入模型上下文的那一刻就开始消耗 Token。

传统 MCP 客户端的工作流程大致如下：

1. 客户端连接 MCP Server；
2. 通过 tools/list 拉取工具列表；
3. 将工具定义注册到客户端本地；
4. 客户端把工具定义提供给模型；
5. 模型根据工具名称、说明和 JSON Schema 选择调用哪个工具。

关键点在于第 4 步。客户端可以保存全部工具定义，但不一定要一次性全部提供给模型。如果客户端支持工具检索（Tool Search）或延迟加载能力，它完全可以只在需要某类能力时，再把对应工具的 Schema 动态注入上下文。

但现实是，很多客户端并不原生支持这一能力，只能把所有工具定义塞进初始上下文。于是问题来了：

• 一个工具不只是函数名，还包含 description、参数定义、JSON Schema；
• 简单工具可能只有几个参数，复杂工具却可能包含多层嵌套对象、枚举、约束和大量字段说明；
• 当工具数量达到数百个时，单个工具 Schema 动辄几百到上千 Token，总量可能轻松突破 25 万 Token。

在这个量级下，一个 256K 上下文窗口会被工具定义直接撑满，模型还没开始干活就没有空间了。即使换成更大上下文的模型，也会因为工具定义常驻而持续产生额外 Token 成本——这不是“能不能跑”的问题，而是“跑起来划不划算”的问题。

二、对比对象：四种工具治理路线

围绕“如何避免工具定义挤占上下文”这一目标，目前主要有四条技术路线。为保持中立，下面用方案 A、B、C、D 表示。

方案	处理方式	典型定位
方案 A：全量注入	客户端拉取全部工具，一次性提供给模型	客户端默认行为，最省事
方案 B：工具过滤与按场景挂载	只暴露当前任务需要的工具	客户端缺少检索能力时的过渡方案
方案 C：按需检索 / 延迟加载	使用时再加载完整工具定义	客户端原生支持时体验最佳
方案 D：代理聚合	用一个中间层代理多个工具源，对外只暴露精简接口	工具源多、需要统一治理时使用

需要强调的是，这四种方案不是互斥关系，而是可以组合的。比如“代理聚合 + 按需检索”就是常见的组合形态。

三、相同点分析

在展开差异之前，先看它们的共同目标与共同约束：

1. 目标一致：都是为了让模型在有限的上下文窗口内，尽可能高效地使用工具能力，而不是被工具定义本身拖垮。
2. 都依赖工具清单：无论哪种方案，都需要先获取工具的名称、描述和 Schema，区别只在于“何时注入、注入多少”。
3. 都涉及客户端与 Server 的协作：工具过滤可能需要 Server 侧支持分组；按需检索需要客户端支持动态加载；代理聚合则需要额外的中间服务。
4. 都面临一致性风险：工具版本变化、Schema 更新、权限变化，都需要在治理层同步，否则模型可能调用到过期定义。

四、核心差异分析

4.1 技术架构差异

• 方案 A：架构最简单，客户端直连 Server，无额外组件。缺点是上下文压力全部由模型承担。
• 方案 B：需要在客户端或配置层做工具白名单/分组，通常依赖人工维护，架构改动小。
• 方案 C：客户端需要维护完整工具目录，并具备检索、加载、卸载能力，对客户端实现要求较高。
• 方案 D：引入代理层，代理负责连接多个工具源、聚合与裁剪，对外暴露统一接口，架构复杂度最高。

4.2 上下文占用对比

方案	初始上下文占用	运行时上下文占用	是否常驻
方案 A	全部工具定义	全部工具定义	是
方案 B	仅挂载的工具定义	仅挂载的工具定义	是
方案 C	工具目录摘要	按需加载的具体 Schema	否
方案 D	代理暴露的精简接口	按需转发，视实现而定	部分

可以看到，方案 A 的问题不是“工具不好”，而是“全量常驻”。方案 C 与方案 D 的核心价值就在于把“全量常驻”变成“按需加载”。

4.3 接入与改造成本

• 方案 A：零改造，开箱即用，但代价是上下文成本。
• 方案 B：需要梳理任务场景与工具分组，人工维护成本较高，工具更新时容易遗漏。
• 方案 C：依赖客户端能力，若客户端不原生支持，可能需要插件或二次开发。
• 方案 D：需要部署与维护代理服务，涉及网络、鉴权、日志、版本管理等额外工作。

4.4 性能与稳定性

• 方案 A：响应快，因为工具已就绪；但上下文接近上限时，模型推理质量和稳定性都会下降。
• 方案 B：上下文压力小，响应稳定；但切换场景时需要重新挂载，存在操作成本。
• 方案 C：首次调用某工具时有检索与加载延迟，后续调用体验接近方案 A。
• 方案 D：多一层代理，理论上增加网络跳数和故障点，但可通过缓存与健康检查缓解。

4.5 安全与权限

• 方案 A：所有工具对模型可见，权限边界最宽，风险最高。
• 方案 B：可按角色或任务裁剪工具，权限收敛效果明显。
• 方案 C：检索层可结合权限过滤，只返回当前用户可用的工具。
• 方案 D：代理层是天然的权限控制点，适合做统一鉴权与审计。

4.6 运维与成本

• 方案 A：运维最简单，但 Token 成本随工具数量线性上升。
• 方案 B：运维中等，需要维护工具分组配置。
• 方案 C：运维取决于客户端实现，若自研则需承担检索服务维护。
• 方案 D：运维成本最高，但长期看更适合工具规模持续增长的团队。

五、典型场景选择

• 个人开发者、工具数量少于 30 个：方案 A 足够，不必过度设计。
• 工具数量 50～200，客户端不支持检索：优先方案 B，按任务挂载，快速见效。
• 客户端支持按需检索或可安装插件：方案 C 体验最佳，上下文占用与调用体验平衡最好。
• 多工具源、多团队共用、需要统一权限与审计：方案 D 更合适，代理层可长期演进。

六、选型建议

选型时建议按以下顺序判断：

1. 先看客户端能力：是否原生支持按需检索。支持则优先方案 C。
2. 再看工具规模：工具数量是否已经影响到上下文。未影响则方案 A 可继续使用。
3. 再看团队运维能力：是否有精力维护代理层。没有则方案 B 更务实。
4. 最后看长期规划：工具是否还会持续增长。会增长则应尽早引入代理或检索能力。

没有绝对最优的方案，只有与当前客户端能力、工具规模和团队条件匹配的方案。

七、迁移与使用注意事项

• 工具定义一致性：迁移过程中要确保代理层或过滤层与 Server 的工具版本同步，避免模型调用到过期 Schema。
• 权限模型对齐：过滤与检索都要与原有权限体系对齐，防止出现“工具不可见但可调用”的漏洞。
• 降级预案：按需检索失败时，应有回退到静态挂载的机制，避免任务中断。
• 监控与审计：记录工具调用日志，便于排查上下文异常与权限问题。
• 成本评估：迁移本身有改造成本，需与节省的 Token 成本做长期对比，避免为小规模工具集引入过重架构。

八、总结

MCP 工具膨胀的本质，是工具定义常驻上下文与上下文窗口有限之间的矛盾。方案 A 用最简单的方式换来最高的上下文成本；方案 B 用人工分组换取快速缓解；方案 C 用客户端能力换取最优平衡；方案 D 用架构复杂度换取长期可治理性。

决策思路可以归纳为一句话：先确认客户端是否支持按需检索，再根据工具规模与团队运维能力，在过滤、检索与代理之间选择组合方案。工具治理不是一次性工作，而是随着工具数量增长需要持续演进的工程实践。