渐进式工具发现
朴素的 MCP 主机实现会在每次对话开始时,直接将每个已连接服务器的工具定义传递给模型。对于少量工具而言,这完全合理。但当主机可访问数十个服务器、暴露数百个工具时,仅这些定义就可能在模型甚至还没读到用户消息之前,占用上下文窗口的大部分空间。 渐进式发现可以避免这一点:- 主机像往常一样通过
tools/list获取工具定义,但推迟将其注入到模型上下文中。 - 主机向模型提供一个轻量级的
search_tools元工具。 - 主机仅在需要时才将完整定义加载到上下文中。
何时使用渐进式发现
当工具定义占据上下文窗口较大部分时,渐进式发现最适合使用。对于一小组工具、且工具定义只占上下文窗口很小一部分的情况,直接加载所有工具就足够了。一旦工具定义占用了可用上下文窗口的显著部分,客户端就应切换到渐进式发现。我们建议客户端实现阈值来决定何时切换:
- 将阈值实现为上下文窗口的百分比。例如,1%-5%。
- 加载工具定义。一旦达到阈值,就切换到渐进式发现。
选择发现策略
一旦模型调用了search_tools 工具,我们就需要选择一种搜索策略:
- 基于关键词:关键词匹配(BM25、正则表达式)。简单且有效,尤其适合描述性强的工具名称和描述。
- 基于嵌入:对工具描述进行向量相似度检索。对同义词和语义匹配的处理更好。
- 基于子代理:由第二个模型,通常是更小更快的模型,例如 Claude Haiku 或 Gemini Flash,来为任务选择工具。这个方法通常效果很好,但成本可能比基于嵌入或基于关键词的方案更高。
- 混合:结合多种方法。例如,对关键词和嵌入排名共同打分,或者根据使用场景或查询选择不同策略。
使用渐进式发现
一种常见的渐进式发现实现方式,是使用基于搜索的三层方法: 第 1 层:目录。 主机提供一组较小的元工具,用于搜索可用能力。search_tools 工具接受自然语言查询,并返回匹配的工具名称及简短描述。
动态服务器管理
渐进式发现不仅适用于单个工具,也适用于整个服务器。主机无需在启动时连接所有已配置的服务器,而可以:- 维护一个可用服务器及其高层描述的注册表。
- 只有在模型判断需要某个服务器能力时,才连接该服务器。
- 断开当前任务不再相关的服务器,从而释放上下文。
实现指南
实现渐进式发现时:与提示缓存的交互
大多数提供商会缓存提示前缀,包括tools 数组。在对话过程中添加或移除工具定义会使该缓存失效,而产生的未命中成本可能比你移除的定义还要消耗更多 token。为了保留缓存:
- 在缓存断点之后追加新发现的定义,而不是对
tools数组重新排序,或者让每次调用都通过一个稳定的call_tool({name, args})元工具进行,这样数组就不会改变。 - 将服务器断开连接视为会话边界操作,而不是逐轮操作。
- 除了上面的工具搜索链接外,还要参考你提供商的缓存文档。
程序化工具调用 / 代码模式
使用直接工具调用时,每次工具调用都是一次往返:模型生成一个工具调用,客户端执行它,完整结果再回到模型的上下文中。当任务需要串联多个工具(读取文档、转换文档、再写到别处)时,每个中间结果都会经过模型,消耗 token 并增加延迟,即使这些结果与模型本身并无关系。 程序化工具调用(有时称为“代码模式”)为客户端提供了一种有效组合工具调用的方法。模型不再直接调用工具,而是编写调用工具的代码。代码在沙箱环境中执行,只有最终结果会返回给模型。 程序化工具调用功能强大,能够更高效地使用 MCP 工具和资源,但要求客户端实现一个沙箱环境。工作原理
宿主会将 MCP 工具模式转换为可在沙箱中使用的类型化 API。当模型需要工具时,它会编写脚本并执行它。 第 1 步:根据 MCP 模式生成程序化 API。 宿主读取每个服务器的工具定义,并根据每个工具的参数生成类型化函数:LogEntry)必须来自服务器文档或手动配置。
当无法获得精确返回类型时,优先选择简单路径:
- 使用通用类型并继续。 接受
any或string,并在下游处理非结构化输出。 - 使用快速模型提取类型化结果,适用于沙箱外的单次调用。通过与 MCP 工具调用相同的存根拦截路径,暴露一个由宿主代理的
extract(value, ExpectedType)辅助函数,这样沙箱本身不会建立网络连接。该辅助函数会路由到一个小模型(例如 Claude Haiku 或 Gemini Flash),将值强制转换为ExpectedType。这会增加每次调用的延迟,并且可能产生幻觉或丢失字段,因此在使用前要根据ExpectedType验证结果。
console.log 输出,也就是一行摘要,会返回给模型。
选择沙箱
合适的沙箱取决于你希望模型编写的语言、宿主应用的语言,以及你需要的隔离强度。下表列出的是示例运行时而非推荐;请根据你的使用场景评估其成熟度:
无论使用哪种沙箱,集成模式都相同:宿主注入函数存根,通过进程内或 stdio 通道拦截调用(因此可以保持网络权限完全拒绝),并将它们作为
tools/call 请求分发到 MCP 服务器。
执行架构
该实现包含三个组件: 沙箱在隔离环境中运行模型生成的代码,不允许直接访问网络。它唯一与外界交互的方式是通过生成的函数存根,这些存根会将调用路由回宿主。 宿主充当代理。它接收来自沙箱的函数调用,将其映射到正确的 MCP 服务器,执行工具调用,并将结果返回给沙箱。授权令牌和凭据由宿主管理,且永远不会暴露给生成的代码。 模型只能看到沙箱返回的内容,通常是console.log 语句的输出或最终返回值。这样可以让模型(以及客户端开发者)精确控制哪些内容进入上下文窗口。
安全注意事项
程序化工具调用引入了代码执行面,因此需要仔细进行沙箱隔离:- 逐次调用授权:从规范角度看,代理仍然是 MCP 宿主。对沙箱发起的调用,应应用与你对直接调用相同的人工确认策略(参见 Tools: Security)。批准脚本并不意味着批准它在运行时发出的每一次工具调用;宿主可以授予分类别的批准(例如,“允许这个脚本运行期间使用
ticketing_createIssue”),而不是每次迭代都提示,但代理仍必须根据该授权评估每次调用。 - 跨服务器数据流:来自一个服务器的工具结果,对另一个服务器而言是不可信输入。代理对经由代理转发的调用,应采用与直接调用相同的输入审查策略;仅靠输出截断并不能阻止数据外泄。
- 网络隔离:沙箱不应具有直接网络访问权限。所有外部通信都应通过宿主代理完成,由宿主执行授权和访问控制。
- 不暴露凭据:API 密钥和令牌由宿主管理。生成的代码只调用类型化函数;宿主在转发到服务器时补充身份验证。
- 资源限制:为沙箱执行设置超时和内存限制,以防脚本失控。
- 输出过滤:在将沙箱控制台输出反馈给模型之前,先进行验证和截断。
错误处理
MCP 工具错误会以成功响应的形式返回,其中isError: true 而不是传输
失败。生成的包装器应将其转换为抛出的异常,这样模型编写的代码
就可以使用 try/catch。如果未捕获的错误终止了脚本,应将其作为脚本的
结果返回给模型,以便模型自我纠正;模型负责报告任何已经提交的部分副作用。