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