MCP Server 能否按需改变工具列表并通过 listChanged 控制工具膨胀？

MCP Server 可以按需改变工具列表，并通过 `tools.listChanged` 通知客户端重新获取，但这并不等于协议会自动解决工具膨胀。`listChanged` 负责的是“目录已经变化”的一致性通知；是否只把当前相关工具放进模型请求，仍由客户端或宿主决定。要让 300 至 400 个后端工具真正减少上下文成本，需要把完整工具目录与模型可见工作集分开管理。

先明确 listChanged 能做什么

Server 在初始化 capability 中声明工具列表可能变化，客户端据此知道后续应列表变更。Server 增加、移除或替换工具后发送 `notifications/tools/list_changed`，客户端收到后重新调用 `tools/list`，用新结果刷新本地目录。

{
  "capabilities": {
    "tools": {
      "listChanged": true
    }
  }
}

因此，Server 完全可以初始只暴露一个轻量的 `get_tools` 或 `activate_domain` 元工具。模型选择 CRM、邮件或领域后，Server 把对应具体工具加入列表，发送列表变化通知，客户端重新拉取。下一次模型调用便可能看到刚激活的工具。

这里有两个必要条件：客户端必须支持并实际列表变化；宿主在重新拉取后，必须把新目录转化为下一次模型请求中的工具定义。若客户端忽略通知、只在连接时读取一次工具，Server 即使正确发送事件，也不会产生动态加载效果。

listChanged 不是服务器端过滤协议

当前工具列表请求没有“只返回 CRM”“只返回与这条用户消息相关的前十个工具”之类的标准过滤参数。Server 可以改变自己当时公布的集合，但客户端不能依赖标准字段向任意 Server 表达复杂检索条件。动态检索通常要通过自定义元工具、客户端侧索引或代理层实现。

`listChanged` 也不携带完整的新目录，更不会告诉模型为何发生变化。它只是失效信号。客户端收到信号后应把旧目录视为可能过期并重新 list，而不是把通知本身当成增量补丁。这样可以避免漏掉删除、权限变化或多个连续变更。

分页只能降低传输峰值，不能自动降低提示词

`tools/list` 支持游标分页，这使客户端不必在一次响应中接收几百个工具，对传输、内存峰值和超时有帮助。但如果客户端最终把每一页收齐，再把全部 schema 注入模型请求，模型仍然要承担全部 token、延迟和选择噪声。

所以不能把“目录分批获取”误认为“模型只看到一小部分”。前者是 MCP 传输层行为，后者是宿主编排策略。评估优化是否有效时，应检查发给模型的最终请求，而不只是观察 `tools/list` 响应大小。

可扩展架构：目录与工作集分离

更稳妥的设计保留一个完整 catalog，其中包含名称、短描述、参数 schema、权限范围、风险等级、是否产生副作用以及所属领域。模型每轮只看到一个受预算约束的 working set。完整目录可以在宿主侧建立索引，也可以由 Server 背后的注册中心维护。

catalog = all_authorized_tools
visible = baseline_tools
pinned = recently_used_tools

on user_message:
  candidates = retrieve_relevant_tools(message, catalog)
  visible = baseline_tools + pinned + policy_filter(candidates)

on successful_tool_call(name):
  pinned.add(name)

on task_end:
  pinned.clear()

基线工具通常只包括发现、激活、取消激活和少数安全的通用工具。检索器按任务召回候选，策略层再根据用户身份、租户、环境与风险过滤。最近已调用的工具在会话内固定若干轮，避免它刚出现在历史记录中却立即从当前工具定义消失。

为什么已用工具不能立刻卸载

动态工具的典型失败是：上一轮模型成功调用某工具，下一轮该工具因检索得分降低而从 tools 字段消失，但工具调用和结果仍留在对话历史中。模型会从历史推断该能力仍可用，直接再次生成同名调用，而不是先执行发现工具。

解决方法不是无限累积所有工具，而是采用带期限的固定策略。凡是本任务已调用、计划中即将调用或其结果仍待消费的工具，都放入 pinned 集合；连续若干轮未使用、任务阶段结束或完成安全压缩后才允许移除。若宿主需要硬性 token 上限，应优先缩短描述和可选参数，再按最近使用和任务相关度淘汰。

工具被真正撤销或权限失效时不能继续固定。此时宿主应刷新目录、从工作集移除，并在系统状态中明确能力已不可用。Server 对每次调用仍要重新鉴权，不能因为旧工具定义曾出现在模型上下文中就接受越权请求。

按需加载的推荐交互流程

第一步，客户端连接后读取一个很小的初始列表，其中包含 `get_tools`。第二步，用户提出任务，模型用简短查询描述所需能力，而不是要求返回几十份完整 schema。第三步，Server 或宿主在索引中检索，经权限和风险策略过滤后激活少量具体工具。

第四步，Server 发送列表变化通知，客户端重新执行 list。第五步，宿主在下一次模型请求中加入激活工具，并保留本任务已使用工具。第六步，任务结束后统一回收，而不是每轮根据相似度剧烈抖动。

元工具的结果最好只确认哪些工具已加载，不要把名称、长描述和完整 schema 全部作为普通工具结果塞进历史。否则虽然下一轮 tools 字段变小，目录文本却永久留在对话历史中，省下的 token 又从另一条路径被消耗。

多个 MCP Server 能改善组织，但不会天然省 token

按 CRM、邮件、数据库和文件系统拆成多个 Server，能带来独立部署、故障隔离、权限边界和按项目启停等运维收益。然而，只要客户端同时连接全部 Server 并把它们的所有工具放进同一个模型请求，十个 Server 各二十个工具仍然是二百个工具。

拆分能够省 token 的前提，是宿主按项目或当前任务只启用少数 Server，或在各 Server 目录之上继续做工作集筛选。它与动态加载并不冲突：可以先按领域拆分，再在大型领域内使用元工具和 `listChanged` 激活具体能力。

工具 schema 本身也需要减重

工具膨胀的主要成本往往不是名称，而是冗长描述、几十个可选参数、重复示例以及复杂嵌套 schema。每个参数只保留模型做出正确调用所需的信息；有效值适合用枚举就不要写成长段自然语言；罕用高级选项可以拆成单独工具或二阶段配置。

同时不要为了省 token 把关键约束删掉。副作用、确认要求、数据范围和互斥参数仍需清楚表达。可以把教程式说明放到资源或文档，把调用契约留在 schema，把风险策略放在不可由模型绕过的执行层。

列表变化要保持确定性和可观测性

同一授权状态和同一激活集合应产生稳定的工具顺序与稳定 schema。若每次 list 都随机排序或无意义地改写描述，会降低上游提示缓存命中率，也使差异日志充满噪声。只有集合或契约真实变化时才发送通知，短时间批量变化应合并。

建议记录目录版本、触发变化的原因、激活集合、重新 list 的耗时、最终注入模型的工具数和 token 估算。仅记录 Server 发出了通知不够，还要确认客户端收到、重新拉取并在下一轮采用了新工作集。这样才能区分协议链路故障与召回策略失误。

并发与会话隔离需要提前设计

如果一个 Server 同时服务多个用户或会话，不能简单用全局变量保存“当前已激活工具”。A 会话加载 CRM 后，不应意外改变 B 会话看到的目录。实现可以为每个会话建立逻辑视图，或让宿主持有完整目录并自行筛选。

还要注意客户端对工具集合的缓存粒度。有的客户端把列表绑定到 Server 连接，而不是绑定到某次模型请求。如果多个会话复用同一连接，频繁改变 Server 公开列表可能相互干扰。此时客户端侧工作集管理通常比服务端全局增删更清晰。

测试应覆盖动态链路而非只测 tools/list

基础测试要验证 capability 声明、初始小列表、激活后的新列表和取消激活后的删除。通知测试要断言客户端确实收到列表变化并重新 list，同时处理通知合并、断线重连和重复事件。

模型集成测试应查看每轮最终 tools 字段，确认未激活工具没有进入请求，已调用工具在所需阶段继续存在，任务结束后能够回收。再用一条跨领域长会话验证从 CRM 切到邮件时不会丢失尚未完成的调用，也不会无限增长。

安全测试需覆盖不同用户权限、撤权后的旧缓存、恶意检索词、提示注入诱导发现高风险工具以及并发会话串扰。无论模型看到什么，Server 的调用处理都必须使用当前真实身份重新授权。

结论

MCP Server 可以使用 `listChanged` 支持按需变化的工具列表，做法是声明能力、改变权威目录、发送通知并由客户端重新执行 `tools/list`。但通知和分页只维护目录同步，不保证模型上下文变小。

真正控制工具膨胀，需要宿主把完整 catalog 与模型可见 working set 分离，使用小型发现工具、相关性检索、权限过滤和会话内固定策略。多个领域 Server 提供组织与隔离，动态工作集提供实际 token 节省，两者组合比单独依赖任一种机制更可靠。