引言

大语言模型（LLMs）在处理复杂任务时，通常需要借助外部工具来扩展其能力范围。然而，当前LLM智能体与工具集成的主流范式存在显著局限性：它们往往将预定义的工具模式注入到系统提示中，导致模型扮演被动选择者的角色，而非主动发现所需能力。这种方法不仅造成了巨大的上下文开销，也限制了模型的决策自主性。

为了解决这些问题，本文引入了MCP-Zero，一个旨在恢复LLM智能体工具发现自主性的主动框架。MCP-Zero的核心思想是，智能体能够主动识别自身能力差距，并按需请求特定工具，从而将自身从大规模检索器转变为真正的自主智能体。该框架通过三大核心机制运行：主动工具请求、分层语义路由和迭代能力扩展。这些机制共同作用，使得MCP-Zero能够在最小化上下文开销和保持高准确性的前提下，动态构建多步工具链。

图：LLM 智能体的工具选择范例比较。(a) 基于系统提示的方法将所有 MCP 工具模式注入上下文，导致提示过长，效率低下。(b) 检索增强方法通过匹配一次用户查询来选择工具，这可能会导致工具选择不准确或不充分，尤其是在多轮情况下。© MCP-Zero 使 LLM 能够主动分析任务，根据需要迭代请求最相关的工具，并以最小的上下文开销和高准确度动态构建多步骤工具链。

MCP-Zero核心机制

MCP-Zero框架通过三大核心组件协同工作，旨在解决现有方法面临的上下文开销和多领域协调挑战。它从根本上将工具注入的被动模式转变为主动工具发现，使LLM能够以最小的上下文开销动态构建跨领域任务特定工具链。

主动工具请求 (Active Tool Request)

MCP-Zero的核心在于将工具需求规范的权限归还给LLM本身。当模型识别出需要外部协助时，它会生成一个结构化的请求块，而不是被动地消费预定义的工具。这种机制使模型能够在任务执行过程中，根据需要自发地表达工具需求。与原始用户查询相比，模型生成的请求能更好地与工具文档进行语义对齐。

请求块包含两个关键字段：server（指定平台或权限域要求）和 tool（描述所需的操作类型和目标）。这种设计与MCP规范自然契合，因为所有服务器和工具都必须提供描述性文档，确保了整个MCP生态系统中语义信息的一致性。重要的是，模型可以在一次对话中生成多个此类请求，每个请求都会触发独立的检索过程。

分层语义路由 (Hierarchical Semantic Routing)

为了从数千个候选工具中高效定位相关工具，MCP-Zero采用了两阶段的粗到细检索算法，利用OpenAI的text-embedding-3-large嵌入进行语义相似度匹配。

系统首先通过将server字段与服务器描述进行匹配来过滤候选MCP服务器。由于服务器描述通常是简短的单句，研究人员构建了扩展摘要，其中包含对准确匹配至关重要的全面使用示例。然后，系统对原始描述和增强摘要都执行匹配，并取两者中较高的相似度分数，以提高检索精度。

随后，根据工具字段和工具描述之间的语义相似度对选定服务器内的工具进行排名。最终的排名分数结合了服务器级别和工具级别的相似度。这种评分机制确保了任一维度的高相似度都能显著促进最终排名，从而有效地召回高度相关的工具。系统返回前k个工具，当相似度分数紧密聚集时，可以动态调整k值。

迭代能力扩展 (Iterative Capability Extension)

与传统的单次检索方法不同，MCP-Zero支持在整个任务执行过程中进行迭代工具发现。在接收到检索到的工具后，模型会自主评估其是否足以完成当前子任务。如果返回的工具不足或不合适，模型可以细化其请求规范并重新启动检索，从而提供自然的容错和自我纠正能力。这个迭代过程会持续进行，直到模型确定：(1) 找到了合适的工具并且任务可以继续，或者 (2) 不存在合适的工具并且任务应该依赖模型的参数知识。

该框架的关键优势在于其动态构建跨领域工具链的能力。对于需要跨多个领域协调的复杂任务（例如，图3中的文件系统操作、代码生成和命令执行），模型可以随着子任务需求的明确，逐步识别并请求来自不同服务器的工具，从而避免了预加载全面工具集合的上下文开销，同时保持了高任务完成准确性。MCP-Zero代表了从“预定义工具集”到“动态按需工具发现”的根本性转变。

理论分析

MCP-Zero的优势可以通过正式建模进行理论分析，这与主动学习和信息获取的既有理论相联系。

问题表述

设 T = {t1, t2, …, tn} 表示完整的工具集合，q 表示用户查询，st 表示当前对话状态，t* 表示最优工具选择。传统方法需要对整个集合进行同时评估：

MCP-Zero采用主动信息获取，其中智能体根据其当前状态和能力评估生成请求 r：

其中 P(r | st) 表示智能体根据当前理解表达其需求的能力。

主动信息获取

工具请求的生成可以建模为一个主动学习过程，其中智能体选择行动以最大化任务完成的信息增益：

其中 I(T*; r | st) 表示最优工具集与请求之间的互信息。这个公式捕捉了主动发现的本质：智能体主动减少其工具需求的不确定性。

可扩展性分析

传统方法面临根本性的可扩展性障碍：

• 搜索空间复杂度： 被动方法必须处理所有 n 个工具，复杂度为 O(n)。主动方法首先在 m 个服务器中进行过滤（m ≪ n），然后在过滤后的子集中进行匹配，将复杂度降低到 O(m + k)，其中 k 是每个选定服务器的平均工具数。

• 注意力分布： 在有限的认知资源下，被动方法将注意力平均分配到每个工具上，每个工具的注意力为 1/n，并受到噪声因子 η(n) ∝ log(n) 的影响。主动方法将注意力集中在相关子集上，保持 1/k 的有效性，其中 k ≪ n。

语义对齐优势

主动请求的核心优势在于改进的语义一致性。智能体生成的请求 r 与工具文档表现出更强的对齐，相比原始用户查询 q：

其中 e_r、e_q、e_t 分别表示请求、查询和工具描述的嵌入。这种改进源于智能体与工具文档在相同的语义空间中操作。

迭代信息增益

与单次检索不同，主动发现支持在 k 次迭代中累积信息获取：

其中 λ 表示每次请求的上下文开销。这个公式捕捉了MCP-Zero优化的信息增益和计算效率之间的权衡。

总之，主动范式提供了可衡量的优势：

• 复杂度降低： 从 O(n) 降至 O(m + k)，其中 m + k ≪ n。

• 语义一致性： 工具描述空间中的直接嵌入对齐。

• 信息效率： 针对性地减少不确定性，而非穷举搜索。

• 自适应能力： 随任务理解而演进的状态依赖型工具发现。

这些理论基础解释了我们在实验中观察到的性能提升：token消耗减少98%且准确性保持不变，反映了目标信息获取相对于穷举工具枚举的效率。

数据集：MCP-Tools

为了支持MCP-Zero的主动工具发现框架并实现全面的评估，研究人员构建了MCP-tools数据集，这是MCP领域中首个面向检索的数据集。与现有专注于服务器可用性和延迟测试的MCP评估框架（如MCPBench）不同，MCP-tools数据集专门设计用于促进大语言模型的语义工具发现和检索。

图：在不同工具集合大小的极端规模条件下，MCP-Zero 的性能表现。左栏显示的是采用标准工具调用模式的基准方法；中栏显示的是我们的 MCP-Zero 方法；右栏显示的是使用一个 ICL 示例来指导模型描述生成的增强型 MCP-Zero。我们的方法在 Claude-3.5-Sonnet 和 Gemini-2.5-Flash 上有显著提高，而 GPT-4.1 由于其基线性能已经很强，因此没有任何改进。

数据集构建

MCP-tools数据集的构建过程包括以下步骤：

1. 数据收集： 研究人员系统地从官方Model Context Protocol仓库收集了MCP服务器信息，涵盖了三类共396个服务器：20个参考实现、114个第三方官方服务器和262个社区贡献。这代表了MCP生态系统的当前状态及其工具能力的多样性。

2. 质量保证和过滤： 研究人员实施了严格的过滤，以确保数据集的完整性和语义丰富性。只有提供以下内容的服务器才被保留：(1) 符合MCP规范的工具定义，(2) 能够实现语义理解的全面文档，以及 (3) 足够详细以进行有意义的检索评估。经过此过程，最终得到了308个高质量服务器，代表了MCP生态系统的核心。

3. 结构化信息提取： 研究人员使用Qwen2.5-72B-Instruct模型和精心设计的少量示例来提取遵循标准化模式的结构化信息（如图4所示）。其中，服务器摘要字段是一个关键创新：由LLM生成的全面摘要，它提炼了服务器的能力，同时排除了操作细节。这种设计使得在各种查询形式（从正式的API规范到自然语言能力描述）下都能实现有效的语义匹配。

数据集特性

经过上述过程，数据集的最终特性如下：

• 规模和多样性： 最终数据集包含308个服务器和2,797个工具，全面覆盖了MCP生态系统。工具分布显示出显著差异（平均值：9.08，中位数：5.0，标准差：11.40），反映了生态系统从轻量级实用工具到综合API套件的多样性。超过一半的服务器（162个）包含少于或等于5个工具，而专业服务器则包含60多个工具。

• 语义基础设施： 为了支持高效的检索评估，研究人员使用OpenAI的text-embedding-3-large预计算了所有文本内容的嵌入，创建了一个可搜索的向量索引，从而实现了快速的语义匹配。这些嵌入包含在数据集发布中，以确保评估的可复现性。

MCP-tools代表了MCP领域中首个专门为语义工具发现设计的数据集，补充了MCPBench等注重性能的框架。该数据集的设计不仅支持MCP-Zero的主动发现框架，还为整个研究社区评估基于检索的工具选择方法提供了通用基础。

实验结果

为了验证MCP-Zero的有效性，研究人员进行了两项主要实验：针对极端规模条件下的“大海捞针”评估和针对真实对话场景的APIBank评估。

大海捞针评估 (Needle-in-a-Haystack Evaluation)

为了评估MCP-Zero在极端上下文条件下从大规模集合中准确检索工具的能力，研究人员在MCP-tools数据集上进行了“大海捞针”实验。该实验通过将1到2,797个工具注入到环境中，并从不同位置选择任务描述作为查询，要求模型检索目标工具，从而模拟了相关工具被埋藏在海量工具集合中的挑战性场景。

研究人员比较了三种方法：

• 基线 (Baseline)： 采用标准工具调用模式，将所有工具注入到上下文中。

• MCP-Zero： 本文提出的主动检索方法。

• MCP-Zero + ICL： 增强了MCP-Zero，使用一个上下文学习示例来指导描述生成。

结果分析： 如图所示，MCP-Zero在Claude-3.5-Sonnet和Gemini-2.5-Flash上表现出显著的性能提升，而GPT-4.1由于其本身强大的基线性能，在所有工具集合规模下均未显示出改进。图6展示了传统方法与MCP-Zero在token消耗上的巨大差异。当MCP工具数量增加时，标准工具调用方法的token成本呈指数级增长，而MCP-Zero则保持了持续较低的token使用量。

图：大海捞针实验中的token效率比较。图中显示了在不同规模的收集中，每次成功检索的平均token消耗量。

APIBank评估

为了验证MCP-Zero在真实对话工具检索场景中的有效性，研究人员在APIBank数据集上进行了全面实验。实验设置中，研究人员从APIBank level-1数据集中提取了描述信息用于检索任务，共得到48个独特的工具，并将其用于评估框架。由于APIBank的数据是按单个API组织，没有服务器级别的层次结构，因此直接检索工具，无需服务器过滤阶段。

研究人员从两个关键维度进行评估：对话上下文和工具集合范围。对于对话上下文，测试了单轮场景（一个用户查询对应一个响应）和多轮场景（包含多次交互的扩展对话）。对于工具集合范围，检查了领域集合（使用与特定领域相关的精选工具子集）和完整集合（从所有可用工具的完整集合中检索）。

结果分析： 如表所示，可以得出以下结论：

• 极致的上下文效率： MCP-Zero在所有设置下将提示长度减少了60-98%（例如，在完整单轮情况下，从6.3k token降至111 token），验证了其“按需付费”的能力。

• 强大的可扩展性： 当从人工精选的领域子集转移到完整工具池（API数量增加40倍）时，Claude-3.5上标准模式注入的准确性急剧下降（单轮从97.60%降至69.23%，多轮从100.00%降至60.22%）；而MCP-Zero的准确性分别保持在95.19%和90.32%，显示出对注意力稀释的强大抵抗力。

• 多轮一致性： MCP-Zero在对话轮次中保持了高准确性（从单轮到多轮下降不超过3%），而标准方法一旦上下文积累了先前的调用和更大的工具集，性能就会急剧下降。

• 主动请求的必要性： 纯粹的查询检索基线准确性停滞在65-72%，这证实了让模型生成语义对齐的请求至关重要。

这些APIBank实验结果证实了MCP-Zero的主张：它在大幅削减上下文使用量（高达两个数量级）的同时，提供了接近最优或更优的工具选择准确性，并在单轮和多轮对话以及大规模工具池扩展下均保持鲁棒性。这些结果突出表明，主动、迭代的工具发现是实现可扩展、成本高效智能体系统的实用途径。

表：APIBank 评估结果将 MCP-Zero 与标准工具调用方法在不同情况下进行比较。准确率基于第一名的结果。结果显示了三种 LLM 的准确率（%）和平均token消耗量。“Q.Retriaval ”表示基于用户查询的检索。

结论

这项工作确立了主动工具发现作为自主智能体系统的基本范式，使模型能够在解决工具调用架构中关键可扩展性挑战的同时，保持决策自主性。MCP-Zero证明，从被动工具消费转向智能体驱动的能力获取，能够实现显著的效率提升——在保持准确性的同时，token消耗减少98%——同时恢复了自主智能体的核心原则：评估局限性并主动获取必要资源的能力。MCP-Zero的理论框架、实证验证和MCP-tools数据集为随着工具生态系统呈指数级扩展而推进自主智能体架构奠定了基础和基础设施。

讨论

如何将MCP-Zero集成到智能体中

MCP-Zero从根本上说是一种简单而有效的方法，有望造福更广泛的MCP社区。其核心方法可归结为三个简单的步骤：提示模型主动请求工具、维护一个带有语义描述的轻量级工具索引，以及利用改进的语义对齐进行高精度检索。以下是将其思想集成到现有智能体框架中的实用指南：

• 步骤1：提示LLM请求工具。 赋予模型明确的“权限”来声明缺失的能力。实际上，这是一种系统指令，例如：“如果当前任务无法通过您的知识解决，请发出一个<tool assistant>块，指定您需要的服务器域和工具操作。”此外，还需要指定输出结构。此步骤旨在激发模型“主动”提出需求的能力。

• 步骤2：策划一个轻量级的MCP风格工具索引。 首先，根据需求选择范围：整个MCP-tools集合、垂直切片（例如，仅数据库）或内部API。然后，对于每个服务器/工具：从元数据中提取名称和描述；可选地，让一个强大的LLM生成一个增强摘要，强调能力和使用模式；将所有文本存储在带有预计算嵌入（如text-embedding-3-large）的向量存储中。

• 步骤3：将模型输出与检索结合。 当智能体发出一个<tool assistant>块时：将服务器字段与服务器描述和摘要进行匹配；选择前m个候选。在每个候选服务器中，通过工具字段和工具描述嵌入对工具进行排名。将最佳（或前k个）JSON模式反馈给LLM。由于请求文本已经与文档语义对齐，检索精度高于“用户查询→API文档”匹配，从而在显著节省上下文的同时保持性能。

单个ICL示例为何有帮助

在实验中观察到，添加一个上下文示例（“ICL-1”）有助于略微提高“大海捞针”的准确性。研究人员推测这有两个简单但有效的影响：

1. 风格锚定： 基础提示仅表示“输出您需要的服务器和工具”，但没有给出句子应如何呈现的示例。单个上下文示例提供了写作风格作为参考，有助于生成的请求更接近于策划的描述，从而使语义匹配变得更容易。

2. 语义基础： 示例还阐明了每个字段的含义，帮助模型理解MCP服务器和工具的具体定义，从而限制了其表达范围。看到这一点后，模型可靠地发出诸如“文件系统读取”之类的短语，而不是模糊的“读取文件”，从而大大减少了语义不匹配。

简而言之，一个微小的演示补丁充当了模式锚；未来的工作可以用一个简短的基于语法的解码器规则替换ICL，但这种一次性方法是免费且高效的。

与Alita的协同作用：同时使用和创建工具

与此同时，Alita提出了一个统一的管理器智能体，它创建自己的工具链：它通过网络搜索代码、克隆GitHub仓库、构建环境并执行生成的程序来完成任务。研究人员发现这两项工作是互补的：

• MCP-Zero： 高效地查找和调用现有工具。

• Alita： 自动即时构建缺失的工具。

MCP-Zero和Alita解决了同一个问题的互补部分：前者最大化工具发现，而后者最大化工具创建。当它们结合时，形成了一个良性循环：智能体首先主动从所有可用资源中发现工具；如果没有合适的工具，它会切换到Alita的工作流程来合成一个新的工具，然后将新构建的工具注册到社区。研究人员认为，这样的流程是实现自我进化、成本感知智能体系统的一个引人注目的方向。

未来工作

尽管MCP-Zero在工具检索效率和准确性方面取得了显著改进，但仍有几个有前景的方向值得进一步研究：

• 增强的实验验证： 未来的工作应将评估扩展到更多领域。计划在其他数据集上进行全面实验，以验证其通用性。

• 高级匹配算法： 当前的语义相似性方法可以得到增强。设想将多模态描述（例如，代码示例、使用模式、参数模式）纳入检索过程，并探索使用共现模式以改进上下文理解。

• MCP服务器实现： 一个自然的扩展是将MCP-Zero打包为一个专用的MCP服务器，提供工具发现服务。这个“元服务器”将暴露标准化的API，用于主动工具检索，从而实现与现有MCP生态系统的无缝集成，并作为分布式工具集合的集中发现中心。