本地小模型如何应对MCP工具膨胀

当前开发者社区围绕 MCP 的讨论，主要聚焦于企业治理和权限模型。这些确实是需要关注的问题。但还有一个更迫切、却较少受到关注的限制：对于运行较小型本地模型的用户来说，MCP 的 token 消耗模式是一个结构性问题，而不仅仅是带来一些不便。

下面来看看这个问题究竟是什么样的。

上下文窗口并不相同

拥有 128k 上下文窗口的云端托管模型，可以容纳来自三四个 MCP server 的冗长工具描述，同时仍为真正的对话留出空间。而上下文窗口只有 8k、在本地运行的 7B 模型则做不到这一点。当一个 MCP server 向上下文中塞入 30 个工具描述时，在用户发送第一条消息之前，你就已经消耗了相当一部分上下文预算。

这并非假设。实践中的工具描述通常很冗长，因为它们必须如此——模型需要根据这些描述，判断何时以及如何调用每个工具。简短的描述可以节省 token，却会降低路由准确率；详尽的描述会消耗更多 token，但效果更好。这种权衡客观存在，并不存在免费的解决方案。

研究这个问题的团队目前主要采用几种方案：将描述精简到最低限度，同时接受一定程度的错误路由；实现动态工具加载，根据检测到的任务上下文，仅注入相关工具；或者对每个会话中处于活跃状态的 server 数量设置硬性上限。这些方案没有一个足够干净利落。

本地部署面临不同的权限模型问题

很多关于权限的讨论，都将 MCP 非全即无的信任模型视为企业安全问题。对于本地部署而言，这个问题更加直接，也更切身：如果你运行的 MCP server 可以访问本地文件系统或本地数据库，那么在“Agent 可以读取这个目录”和“Agent 可以执行该 server 暴露的任何操作”之间，并不存在细粒度的权限范围。

一些实践者构建了轻量级网关层，在 MCP 调用到达 server 之前将其拦截，并应用权限范围规则。这种方式确实有效，但它增加了一个需要维护的组件，也引入了自身的故障模式。由于协议没有在规范层面解决这个问题，每个重视它的团队最终都会采用不同的解决方式。

Server 质量差异对小型模型影响更大

目前发布的大多数 MCP server 都是 REST API 的封装。它们暴露的工具集合反映了原始 API 的设计，而这些 API 是为人类开发者设计的，并非为语言模型消费而设计。面向 LLM 的优秀工具设计有所不同：工具的职责应该聚焦，名称应该清晰无歧义，描述应该优先呈现最具区分度的信息。

对于指令遵循能力较强的大型模型来说，质量一般的工具描述尚可弥补。但对于较小型的本地模型，如果一个工具的描述不佳，又与另一个工具看起来相似，就会持续产生错误路由。生态系统中的这种质量差距，对小型模型的影响更为严重。

这个协议真正做对了什么

支持 MCP 的核心理由在于减少胶水代码，而这一点确实成立。在统一标准出现之前，要将 Agent 连接到多个异构数据源，就意味着必须为每个数据源编写定制的集成逻辑：不同的认证模式、不同的错误处理方式，以及不同的工具接口约定。MCP 将这些差异收敛为一种统一的接口模式。即便目前仍存在一些粗糙之处，一旦完成初始配置，它在降低集成开销方面带来的收益仍然真实且可衡量。

实践者该如何应对

这个协议确实在解决一个有实际价值的问题。但其实现也存在具体问题，而且这些问题对本地模型用户的影响大于云端模型用户。整个生态系统仍处于早期阶段，server 质量和工具设计规范都尚未稳定。

对于目前使用本地模型进行开发的人来说，真正务实的问题是：你具体采用什么策略，来避免 MCP 工具描述耗尽上下文预算？当接入第三个或第四个 server 后，这套策略是否依然有效？

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。