工具发现与延迟加载

多 server 连接导致工具数量膨胀时，如何用分页懒取与语义路由控制上下文占用

核心要点：

多 server 连接导致工具爆炸

每个工具定义约 500-1000 token

工具越多，模型选择准确率越低

MCP 层：分页懒取 + 动态工具暴露

应用层：按需 schema、语义检索路由

本文承接 03-MCP-协议的工具列表机制，讲规模化后的工具爆炸应对。

工具爆炸是什么问题？

核心问题：连上十几个 MCP server 后，为什么 agent 反而变差了？

工具定义本身要占上下文，数量膨胀既费 token 又降低模型选择准确率[1]。每个工具定义估算约 500-1000 token，连接多个 server 后工具总数可达数百，把上下文窗口塞掉一大块。

这是一个双重成本：token 成本（工具 schema 常驻上下文）+ 决策成本（候选工具越多，模型越容易选错或犹豫）。它和 02-工具设计原则的"集合最小不重叠"是同一问题的两个尺度——单工具要精简，工具集也要控量。

核心问题：MCP 协议自身提供了哪些减负机制？

MCP 提供分页懒取和动态工具暴露两个协议级机制[2]。它们让工具列表不必一次性全量加载。

分页懒取：tools/list 支持 cursor 分页，可分批获取而非一次拉全。
动态工具暴露：server 声明 listChanged: true 后，可通过 notifications/tools/list_changed 通知更新工具列表；MCP 规范明确指出工具列表设计上是动态的。

这意味着 server 可以按上下文按需收窄工具集，只暴露当前相关的工具，而非把全部能力一次性摊给模型。

核心问题：在协议机制之上，应用还能怎么进一步控制工具注入？

三种应用层模式：按需 schema、语义检索路由、分组激活[1]。它们把"加载哪些工具"变成一个主动决策。

模式	做法
按需 schema 加载	初始只给工具名 + 一行描述，模型决定调用前才拉完整 schema
语义检索路由	用向量或关键词索引，每轮只注入最相关的 K 个工具
分组激活	按任务阶段激活相应工具组，非当前组不进上下文

@tbl-agent-tool-lazy-loading-patterns 应用层三种工具延迟加载模式：按需 schema 加载、语义检索路由、分组激活及各自做法

这套思路与 02-上下文工程/02-核心原则的 just-in-time 一致：工具定义也是数据，默认不放、需要时再拉。更激进的方案是把工具暴露为代码 API 按需读取(见 05-代码执行vs工具编排)。

核心问题：是不是所有 agent 都该上延迟加载？

不是——工具数少于约 50 个时，全量注入仍是最简方案[1]。延迟加载本身有复杂度成本（检索索引、schema 二次拉取），小规模下得不偿失。

可借鉴的判断：先数工具。几十个工具直接全量注入；上百个工具、或工具 schema 明显挤占上下文时，再引入语义路由或代码 API。不要为还没出现的规模问题提前优化。