MCP-Bench: Benchmarking Tool-Using LLM Agents with Complex Real-World Tasks via MCP Servers

A1 主要贡献

本文介绍了MCP-Bench，这是一个旨在通过复杂真实世界任务评估大型语言模型（LLM）代理的基准。这些任务要求使用工具、跨工具协调、精确的参数控制以及规划/推理能力。

核心问题: 现有用于评估工具使用的基准存在根本性局限。
1. 早期基准（如ToolBench, BFCL v3）：虽然聚合了大量API，但这些API功能孤立，导致任务要么是简单的几步工具调用，要么依赖于人为拼接的流程，因为工具的输入输出很少能自然地衔接。
2. 改进的基准（如τ-Bench）：选择了一小组接口兼容的API，但覆盖的领域和工具非常有限，难以扩展任务多样性或捕捉真实多领域工作流的复杂性。
3. 基于MCP的基准（如MCP-RADER, MCPEval）：虽然利用了模型上下文协议（MCP）的标准化调用模式，但范围仍然狭窄，只覆盖少数服务器和几十个工具，导致工作流较短。
4. 共同缺陷：现有基准（无论是API-based还是MCP-based）普遍缺乏对模糊指令下规划能力的测试，任务通常明确指定工具名称或执行步骤。此外，它们忽略了更复杂的场景，如多目标任务（如协调航班、酒店和交通的旅行预订）、基于证据的推理（要求引用中间工具结果而非幻觉生成）以及跨领域编排（如结合金融工具和新闻来源解释股票变动）。如表1所示，现有基准都未能充分反映真实世界工具使用的复杂性、模糊性和多样性。

图1 | MCP-Bench将LLM代理连接到真实的MCP服务器，这些服务器暴露了跨金融、科学和研究等领域的250个结构化工具。任务通过基于LLM的合成方式生成，然后由代理通过多轮工具调用执行。每个执行轨迹都使用基于规则的检查和“LLM作为评判者”的评分相结合的方式进行评估，评估代理在工具模式理解、多跳规划和真实世界适应性方面的表现。
图1 | MCP-Bench将LLM代理连接到真实的MCP服务器，这些服务器暴露了跨金融、科学和研究等领域的250个结构化工具。任务通过基于LLM的合成方式生成，然后由代理通过多轮工具调用执行。每个执行轨迹都使用基于规则的检查和“LLM作为评判者”的评分相结合的方式进行评估，评估代理在工具模式理解、多跳规划和真实世界适应性方面的表现。

研究目标与创新点: 为了克服上述局限，本文引入了MCP-Bench，一个在大规模、真实的、基于生态系统的工具使用场景中评估LLM代理的基准。其主要贡献如下：
1. 一个现实的工具使用基准：利用MCP服务器暴露了28个服务器上的250个工具，实现了服务器内的依赖链和跨服务器的编排。
2. 一个结构化的任务合成流程：生成基于真实工具语义的复杂、多跳任务的模糊指令。
3. 一个稳健的评估框架：结合了基于规则的执行检查和基于评分准则的“LLM作为评判者”评分，能够全面评估执行正确性和战略推理能力。
4. 一项大规模实证研究：在104个具有挑战性的任务上评估了20个最先进的LLM，揭示了在现实和复杂的工具使用场景中，代理能力仍然存在持续的弱点。

MCP-Bench通过弥合孤立API基准与真实世界生态系统之间的差距，为严格评估LLM的代理推理和工具使用能力提供了一个标准化且可扩展的平台。

表1 | 与现有工具使用基准的比较。
与现有工具使用基准的比较。

表2 | MCP-Bench中的任务示例。
MCP-Bench中的任务示例。

A3 背景知识/关键Observation/设计原则

2. 相关工作

LLM基准测试。近期的基准测试已从静态评估稳步发展到更具互动性的真实世界任务。早期的工作如MMLU【12, Measuring Massive Multitask Language Understanding, 2021, ICLR】和BIG-bench【34, Beyond the imitation game: Quantifying and extrapolating the capabilities of language models, 2023, TMLR】侧重于单轮或固定格式的评估，通过多项选择或自由形式的回答来测试广泛的事实知识和推理能力。HELM【18, Holistic evaluation of language models, 2023, TMLR】引入了一个多指标评估框架，用于在静态文本任务上全面比较LLM的准确性、校准度、公平性和鲁棒性。最近，焦点已转向推理和代理能力【15, Visualwebarena: Evaluating multimodal agents on realistic visual web tasks, 2024, arXiv】【16, Spectool: A benchmark for characterizing errors in tool-use llms, 2024, arXiv】【44, ActionStudio: A lightweight framework for data and training of large action models, 2025, arXiv】【8, Deepresearch bench: A comprehensive benchmark for deep research agents, 2025, arXiv】【36, Browsecomp: A simple yet challenging benchmark for browsing agents, 2025, arXiv】。MMLU-Pro【35, MMLU-pro: A more robust and challenging multi-task language understanding benchmark, 2024, NeurIPS】通过LLM生成的、推理密集型项目来增加难度以减少污染。MT-Bench【45, Judging LLM-as-a-judge with MT-Bench and Chatbot Arena, 2023, NeurIPS】评估多轮对话质量，衡量一致性和上下文连贯性。AgentBench【19, AgentBench: Evaluating LLMs as agents, 2024, ICLR】评估在模拟环境中的基于工具的决策。WebArena【47, Webarena: A realistic web environment for building autonomous agents, 2024, ICLR】探索开放式的网页导航，而REALM-Bench【10, REALM-Bench: A real-world planning benchmark for LLMs and multi-agent systems, 2025, arXiv】则关注动态干扰下的目标规划。尽管取得了这些进展，但大多数基准仍然未能模拟现实复杂的工​​作流，在这些工作流中，需要组合不同的工具，并在步骤之间集成中间输出。

评估工具使用能力。随着任务变得越来越复杂，评估现在针对跨工具接口的推理、规划和执行。Mind2Web【6, Mind2Web: Towards a generalist agent for the web, 2023, NeurIPS】使用固定的浏览器动作API进行“思考到行动”的规划，而WebArena【47, Webarena: A realistic web environment for building autonomous agents, 2024, ICLR】添加了带有嵌入式工具的自托管域，但两者都依赖于手工制作的工具集。为了扩大工具选择和协调范围，后续的基准以不同的方式追求更广泛的工具协调：τ-Bench【42, τ-Bench: Evaluating tool-augmented language agents through human-in-the-loop collaboration, 2025, ICLR】增加了模拟用户和通过??的最终状态检查；BFCL v3【31, The berkeley function calling leaderboard (BFCL): From tool use to agentic evaluation of large language models, 2025b, ICML】通过AST分析验证多轮API工作流；τ3-Bench【43, τ3-Bench: The things real disturbing llm based agent in multi-tasking, 2025, arXiv】强调工具间的依赖推理；ComplexFuncBench【46, ComplexFuncBench: Exploring multi-step and constrained function calling under long-context scenario, 2025, arXiv】采用基于评分准则、经执行验证的评分方法。然而，所有这些仍然依赖于定制的工具集，限制了真实性。这一差距推动了基于MCP的基准的发展，这些基准标准化了LLM与工具的交互，并自动暴露了与领域对齐的工具。MCPRADAR【9, MCP-RADAR: A multi-dimensional benchmark for evaluating tool use capabilities in large language models, 2025, arXiv】和MCPWorld【39, MCPWorld: A unified benchmarking testbed for API, GUI, and hybrid computer use agents, 2025, arXiv】测试MCP服务器内的工具选择、参数化和执行，但需要手动设置。MCPEval【21, MCPEval: Automatic MCP-based deep evaluation for ai agent models, 2025b, arXiv】也使用五个MCP服务器自动化了基于MCP的任务生成和评估。在具有复杂任务的真实世界MCP生态系统中进行可扩展的、跨服务器的评估仍然是一个开放问题，这激发了我们对这个方向的关注。

A2 方法细节

3. MCP-Bench形式化与设计原则

3.1. 使用工具的LLM代理的形式化

基于POMDP的框架。我们遵循Yao等人【41, React: Synergizing reasoning and acting in language models, 2023, ICLR】的工作，将我们的基准形式化为经典部分可观察马尔可夫决策过程（POMDP）的结构化扩展，专门针对跨多个外部服务器和工具操作的工具使用代理。我们的形式化包括两种执行范式：（1）一次性全局规划，以及（2）多轮规划和观察。每个基准任务由一个POMDP元组（S, A, O, τ, R, U, Σ）表示，其中：S是全局状态空间；A是包括规划步骤和工具调用的动作空间；O是包含工具执行结果和内部信号的观察空间；τ : S × A → S × O 是状态转移和观察函数；R : S → [0, 1] 是奖励函数；U表示任务指令空间；Σ = {$σ_1, σ_2, . . . , σ_K$} 是一组可用的MCP服务器。每个服务器$σ_k ∈ Σ$ 暴露一组工具$T_k$，定义了完整的工具集$T = ⋃_k T_k$。一个结构化的工具调用写作$a_{tool} = ⟨server_id, tool\_name, parameters⟩$。完整的动作空间是$A = A_{planning} ∪ A_{tools}$，观察空间是$O = O_{tools} ∪ O_{state}$。

多轮决策过程。对于代理的工作流，我们采用多轮决策过程【41, React: Synergizing reasoning and acting in language models, 2023, ICLR】。在每一轮$t$中，代理根据所有先前观察到的输出生成一个计划$a_t$，然后执行$a_t$中的工具，并更新其内部状态。这个过程会持续最多$T_{max}$（本文中为20）轮，或者直到代理发出停止信号。最终的推理在观察到完整的轨迹后进行。完整的流程详见算法1。在第4-6行，我们从任务指令$u$初始化执行层列表L、执行轨迹trajectory和初始代理状态$s_0$。在第7-13行，我们迭代地规划和执行动作：规划策略$π_{plan}$产生当前的工具计划，执行策略$π_{exec}$执行计划中的动作，压缩策略$π_{compress}$生成观察结果的简洁摘要。这个压缩步骤至关重要，因为一些工具返回的输出非常长，总结它们可以防止上下文窗口过大。计划被附加到L中，压缩后的观察结果被记录到trajectory中，代理状态被更新。在第14-15行，我们检查终止信号continue_t，如果为False则提前停止。在第16-17行，最终答案通过$π_{final}$从完整的执行轨迹中生成。用于代理执行的提示可以在附录A.2节中找到。

算法1 多轮规划与观察
算法1 多轮规划与观察

3.2. 使用工具的LLM代理的重要能力及其在MCP-Bench中的体现

设计原则。为了在工具增强的环境中有效执行任务，LLM代理应展示出超越标准语言建模的几种关键能力。

工具模式理解与合规性。代理必须忠实地解释并满足复杂的调用模式，这些模式涉及嵌套的JSON结构、枚举类型、受限的值范围以及必需和可选参数的混合。成功需要将自然语言推理与精确的形式化规范对齐。MCP-Bench在250个复杂程度各异的工具上强制执行严格的模式验证——从简单的标量输入到深度嵌套的层次结构——确保即使是微小的模式违规也能被检测到。附录A.5节提供了不同输入模式的示例。

模糊指令下的工具检索与选择。当面对模糊或未明确说明的任务描述时，代理必须从庞大、异构的工具空间中识别出正确的工具。这需要消除语义变体的歧义，处理命名不一致的问题，并避免由表面上看似合理但不相关的工具所设置的陷阱。MCP-Bench通过为每个任务附加10个干扰服务器来严格测试检索精度，为每个实例引入100多个额外的工具。此外，模糊的任务变体（第4.2节）故意省略了明确的工具名称和步骤，迫使代理纯粹从上下文线索中推断出合适的工具。
图2 | MCP-Bench中使用的MCP服务器生态系统概览。
图2(b) | 各服务器上的工具分布。
图2(a) | MCP服务器的类别分布。

长远规划与跨服务器大规模目标编排。现实应用要求多轮工作流能够跨越不同领域，在多轮之间保持相互依赖的状态，有时还需要同时追求多个目标。代理必须管理顺序和并行的依赖关系，协调异构的输出，并通过明智的编排来优化效率。MCP-Bench包括单服务器和多服务器任务，最多可进行20轮执行。其评估框架明确衡量结构连贯性、依赖感知、并行效率和反思性适应（第5节）。任务不仅包括线性工作流，还包括需要跨多个服务器同时进行交互并实现多个目标的复杂组合。

信息溯源与基于证据的推理。为了避免产生幻觉，代理必须将其回应建立在实际的工具输出之上，在多次调用中保持事实一致性，并为其主张提供可追溯的证据。MCP-Bench通过将执行历史与基于评分准则的LLM判断相结合来评估信息溯源能力，奖励那些正确引用工具输出的答案，并惩罚无支持的推理（第5节）。

真实世界适应性。最后，代理必须利用广泛的世界知识来解释特定领域的语义，稳健地处理多样的工具行为，并将异构的输出合成为连贯的解决方案。MCP-Bench涵盖了28个生产级的MCP服务器，覆盖从金融和医疗保健到科学计算和文化遗产等领域，确保任务能反映真实世界工具使用的多样性和不可预测性。

4. MCP-Bench构建

4.1. MCP服务器集合

服务器生态系统。我们的基准涵盖了28个代表性的MCP服务器，横跨11个功能领域（图2a）。最大的类别是媒体与娱乐和研究与知识（各占14.3%），其次是金融、科学和软件开发（各占10.7%）。较小的份额包括地理与旅行、社交与情报、数学和健康（各占7.1%），以及天气、时间和占卜等小众领域（各占3.6%）。这些服务器总共提供了250个工具。工具数量差异很大（图2b），从单一工具的服务器（例如，Call for Papers, FruityVice, Movie Recommender）到大型多工具平台，如BioMCP（35个工具）、Scientific Computing（26个工具）和Medical Calculator（22个工具）。这个多样化的生态系统涵盖了科学计算、金融、内容发现、地理空间服务和专门的分析工具，确保了MCP-Bench具有广泛的能力覆盖范围。所涉及的MCP服务器的详细信息以及所有工具的描述可以在表8中找到。

4.2. 任务合成

任务合成流程。在构建工具使用代理基准时，一个挑战在于如何将一系列真实世界的MCP服务器转化为具有现实自然语言描述的高质量任务。面对分布在不同服务器上的工具，我们如何才能大规模地构建有意义、可解决、结构化但又具有挑战性的任务？我们将这一挑战分解为三个关键阶段：依赖链发现、自动质量过滤和任务描述模糊化。合成任务的示例可以在表2和表9中找到。除了任务合成流程，MCP-Bench中的任务还经过人工检查，以确保其真实性、可执行性以及依赖链分析的合理性。我们使用o4-mini（【29, Introducing o3 and o4-mini, 2025c, OpenAI】）作为任务合成的LLM。所有使用的提示都可以在附录A.3节中找到。我们总共合成了56个单服务器任务，30个双服务器任务和18个三服务器任务。单服务器任务涵盖了我们基准中的所有服务器。用于多服务器设置的双服务器和三服务器组合列于表10。

依赖链发现与任务生成。我们通过分析所提供工具之间的依赖链来开始任务合成：即一个工具的输出自然地流入下一个工具输入的序列。这些链条作为任务生成的结构性支架。我们分析了由工具自然关系产生的内在依赖，以及为有意义的工作流构建的基于场景的依赖。对于多服务器配置，我们强调跨服务器的依赖，以确保不同数据源之间真正的工具协调。这产生了多样化的结构模式，包括线性工作流、并行执行组和混合组合。然后，任务合成LLM被要求根据依赖链的分析结果生成任务（见附录A.3节中的提示）。此外，依赖链的分析结果在评估阶段被用作LLM评判者的参考（见附录A.4节）。

自动质量过滤。每个生成的任务都经过严格的二维质量评估：可解性（Solvability）：任务是否可以使用可用工具完成。实用性（Practical utility）：任务是否解决了真实的用户需求，而不是人为设计的场景。未达到质量阈值（可解性：9.0/10，实用性：5.0/10）的任务将被丢弃（详见附录A.3节）。这确保只有符合我们标准的高质量任务才能进入最终的基准，以牺牲数量为代价来保持基准的完整性。

任务描述模糊化。对于通过质量过滤的任务，算法会生成模糊的任务变体，这些变体陈述了高层目标而没有明确的操作细节。这些模糊的描述将结构化指令转化为自然的业务请求，要求代理从可用的依赖结构中推断出适当的工具序列和执行策略。对于需要精确输入的领域（例如，科学计算、单位转换），模糊变体在采用对话式语言的同时，关键性地保留了所有数值和具体参数。这确保了任务在数学上仍然可解，同时测试了代理弥合用户意图和技术执行之间差距的能力。用于任务描述模糊化的详细提示可以在附录A.3节中找到。

5. 评估方法与指标

评估框架概述。我们使用一个结合了基于规则的指标和LLM评判者评分的综合评估框架。基于规则的部分从执行轨迹中衡量工具使用的稳健性，涵盖四个维度——名称有效性、模式遵守性、运行时成功率和依赖符合性。LLM作为评判者的部分则使用结构化评分准则，通过提示词重排和分数平均来确保公平性，评估任务完成度、工具选择和规划效率与效果方面的战略质量。

5.1. 基于规则的评估

工具使用评估指标。为了评估代理行为的模式理解和执行稳健性，我们从名称有效性、输入模式遵守性和运行时成功率等维度评估其工具使用情况。设 E = {$e_1, . . . , e_N$} 为执行期间所有工具调用的集合。

工具名称有效率。该指标评估代理选择的工具是否存在于允许的工具集 $T_{available}$ 中：$R_{valid} = \frac{| \{e \in E : \text{tool}(e) \in T_{available} \} |}{|E|}$，其中 $\text{tool}(e)$ 返回事件$e$中调用的工具的标识符。该指标惩罚幻觉或无效的工具引用，并反映了代理对工具可用性的理解程度。

模式合规率。该指标衡量每个工具调用是否提供了与工具预期输入模式相匹配的正确结构化参数：$R_{schema} = \frac{| \{e \in E : \text{valid\_tool}(e) \land \text{valid\_schema}(e) \} |}{| \{e \in E : \text{valid\_tool}(e) \} |}$，其中 $\text{valid\_tool}(e)$ 是一个布尔函数，如果 $\text{tool}(e) \in T_{available}$ 则返回True，而 $\text{valid\_schema}(e)$ 如果事件$e$中的参数与工具的预期输入模式匹配则返回True。这确保代理理解预期的API参数格式并避免格式错误的请求。

执行成功率。该指标量化了成功返回结果而未发生运行时失败的工具调用比例：$R_{success} = \frac{| \{e \in E : \text{success}(e) \} |}{|E|}$，其中 $\text{success}(e)$ 如果事件$e$中的工具调用在没有运行时错误的情况下执行并产生有效结果则返回True。高成功率表明与外部系统的交互稳健且错误处理得当。

5.2. “LLM作为评判者”的评估

战略质量评估。为了进一步评估代理行为在原始执行正确性之外的战略质量，我们采用了一个“LLM作为评判者”的框架。评估者被提示在三个核心轴上对代理表现进行评分：任务完成质量、工具选择/使用理由以及规划有效性。评估完全基于任务定义、最终解决方案和执行轨迹中的可观察证据。默认情况下，这里使用的评判模型是o4-mini（【29, Introducing o3 and o4-mini, 2025c, OpenAI】）。

基于评分准则的评判提示。LLM评判者会收到提供给执行代理的模糊任务描述、模糊化前的具体任务描述（不提供给被评估的代理；见第4.2节）、依赖性分析（不提供给被评估的代理；见第4.2节）、代理的最终解决方案、总执行轮数、一个总结的执行轨迹以及可用工具列表。它被明确指示要保持公正和以证据为导向，并严格根据比例成功来打分。评分遵循一个结构化的评分准则，将每个评估轴分解为多个子维度（详见附录A.4节）。它根据一个结构化的评分准则分配分数，该准则将每个评估轴分解为多个子维度（详见附录A.4节）。每个子维度在1到10的范围内评分。子维度的平均分得出该轴的总分，然后归一化到[0, 1]范围用于基准测试。

提示词重排和分数平均。Li等人【17, Evaluating scoring bias in llm-as-a-judge, 2025, arXiv】的研究表明，LLM评判者可能对评分准则维度的顺序表现出敏感性。为了缓解这个问题，我们采用了一种提示词重排策略，随机排列主要评估轴（例如，任务完成度、工具选择、规划效率）以及每个轴内子维度的顺序。重要的是，虽然顺序被打乱，但评分准则的语义内容和措辞保持不变，以确保公平性和一致性。默认情况下，我们对每个任务实例的评分准则提示进行五次独立的重排。每个重排后的提示分别提交给LLM评判者，从而产生五组基于评分准则的分数。对于每次评分运行，我们首先计算每个轴内子维度的平均分，并将其归一化到[0, 1]范围。然后，该任务的最终评判分数计算为五次独立获得的轴级分数的平均值。这种随机化的多遍评估策略大大降低了评估结果因提示结构而产生偏见的可能性，并增强了基于LLM的评判过程的鲁棒性和公平性。实证结果（第6.4节）表明，这种方法降低了分数方差，从而得到更可靠和稳定的评估。

A4 实验环境

A4 实验结果

6.1. 主要结果

总体性能。表3报告了在单服务器和多服务器设置下平均后的结果。我们发现，强模型的模式理解能力始终保持较高水平，o3、gpt-5、gpt-oss-120b、qwen3-235b-a22b-2507和gpt-4o在模式合规性和有效工具命名方面的得分均超过98%。然而，在更高层次的推理中出现了显著差异。最强的模型——gpt-5 (0.749)、o3 (0.715)和gpt-oss-120b (0.692)——获得了最高的总分，这反映了它们既能准确使用工具，又具备稳健的规划效能。相比之下，像llama-3-1-8b-instruct (0.428)这样的小型模型则落后，尽管执行成功率尚可，但在依赖感知和并行性方面表现较弱。这些结果凸显出，虽然基本的执行能力已基本趋同，但规划和推理能力仍然是模型之间的主要区别。

单服务器与多服务器性能对比。表4和表5提供了单服务器和多服务器设置下的详细比较。我们看到，一旦服务器数量增加，较弱模型的性能会明显下降。例如，llama-3-1-8b-instruct的总分从单服务器情况下的0.438下降到多服务器情况下的0.415，而nova-micro-v1从0.520下降到0.471。性能下降的主要原因在于依赖感知和并行性，这在分布式工作流中更难维持。有趣的是，性能下降并非总是平滑的——性能在不同服务器数量下会波动，这表明顺序依赖和并行编排的混合以不同方式给模型带来压力。相比之下，像gpt-5、o3和qwen3-235b-a22b-2507这样的强系统则保持了更高的稳定性。gpt-5在两种设置下的总分都保持在0.75左右的最高水平，而o3和qwen3-235b-a22b-2507则始终保持在0.70以上的竞争力。这些结果强调，执行质量本身不再是瓶颈——真正的区别在于对扩展的鲁棒性，顶级模型在处理长远、跨服务器任务方面显示出明显优势。

表3 | MCP-Bench排行榜，即不同模型在单服务器和多服务器设置下的平均结果。
MCP-Bench排行榜

6.2. 代理在不同能力上的表现及从MCP-Bench中得到的启示

不同能力上的得分。表4和表5还提供了六个评估轴上的性能细分：任务实现、信息溯源、工具适当性、参数准确性、依赖感知和并行效率。在任务完成方面，前沿模型如gpt-5、o3和gpt-oss-120b取得了最好的结果，在任务实现上超过0.63，在信息溯源上超过0.70，而像llama-3-1-8b-instruct和nova-micro-v1这样的小型系统则分别低于0.35和0.45，反映出较弱的语义一致性。在工具选择方面，顶级模型再次占据主导地位：gpt-5、o3和gemini-2.5-pro的工具适当性和参数准确性维持在0.70左右或以上，而较弱的基准模型则稳定在0.30–0.50之间。最显著的差异出现在规划效能上。gpt-5维持了最高的依赖感知能力（0.76）和有竞争力的并行效率（0.34），紧随其后的是o3（0.69和0.37）和qwen3-235b-a22b-2507（0.54和0.31）。相比之下，小型模型在这两个维度上很少超过0.30，这凸显了规划是区分最先进代理与较弱基准的最重要的前沿能力。

从MCP-Bench中得到的启示。表3、表4和表5的综合证据揭示了当前LLM代理的几个优势和劣势：
1. 模式理解能力趋同。低级能力，如模式合规性和有效工具命名，在各模型间已基本趋同。即使是中等规模的系统也能达到95%以上的准确率，表明基本的执行保真度不再是主要瓶颈。
2. 多服务器设置下的可扩展性。随着服务器数量的增加，任务复杂性上升，但性能曲线并非严格单调。强模型（如o3、gpt-5）在单服务器和多服务器设置下保持相对稳定的分数，而较弱/小型模型（如llama-3-1-70b-instruct）则显示出明显的性能下降，并伴有偶尔的波动。这表明在多服务器场景下的适应性是一种区分性能力。
3. 高阶推理的差距。最大的差距出现在规划效能上。顶级模型展示出连贯的结构化推理、依赖感知和自适应反思，在这些子维度上达到约0.72的分数，而较弱的模型很少超过0.30。这突出表明，长远推理和多跳协调仍然是开放的挑战。

总的来说，这些结果表明，虽然现代LLM已经掌握了执行保真度，但它们泛化到复杂、自适应、跨服务器工作流的能力仍然有限。MCP-Bench系统地揭示了这一差距，为推进代理LLM能力提供了一个严格的基准。

表4 | 不同模型在单服务器设置下的详细结果。
不同模型在单服务器设置下的详细结果。

表5 | 不同模型在多服务器设置下的详细结果。
不同模型在多服务器设置下的详细结果。

6.3. 不同模型执行任务所需的轮数和工具调用次数

执行效率分析。表6报告了不同模型完成MCP-Bench任务所需的平均交互轮数和工具调用次数。结果既突显了基准的复杂性，也反映了模型间的效率差异。MCP-Bench中的任务本质上是多步骤的，并且常常涉及跨服务器链接异构工具，既需要顺序推理也需要并行编排。因此，即使是强模型通常也需要几轮交互和多次工具调用，这反映了任务分布的非平凡性。然而，模型层面的差异是明显的。像llama-3-1-8b-instruct这样的小型系统消耗的资源最多，平均每项任务需要17.3轮和超过155次调用，而像gemini-2.5-flash-lite这样的模型也表现出对重复工具使用的高度依赖（平均86.8次调用）。相比之下，像gpt-4o、o3和qwen3-235b-a22b-2507这样更强的模型以更精简的执行实现了可比或更高的成功率，通常在30–40次调用和6–8轮以内。像gpt-5和gpt-oss-120b这样的前沿系统则处于中间地带：它们进行更深层次的多步推理（7–9轮），但调用预算更为可控（48–79次调用）。

表6 | 不同模型平均每项任务的轮数和工具调用次数。
不同模型平均每项任务的轮数和工具调用次数。

6.4. LLM评判者流程的消融研究

评估方法有效性。为了评估我们的LLM评判者流程中提示词重排和分数平均的有效性，我们在本节对其进行了消融研究。

不同LLM间的变异系数。为了量化LLM评判者在不同流程设计下的稳定性，我们计算了每个评判流程在一组50个基准任务上的变异系数（CV）。这些任务是使用两个真实世界的模型上下文协议（MCP）服务器——WebSearch1和Time2——自动合成的。WebSearch服务器支持信息检索和摘要，而Time服务器提供时间推理和日历工具。每个任务由三个LLM——o4-mini、gpt-4o、gpt-4o-mini——使用相同的LLM评判流程进行评分。我们提取任务完成分数（0–10分制）用于CV计算。具体来说，对于每个任务$i$，我们计算其变异系数为$CV_i = \frac{\sigma_i}{\mu_i} \times 100\%$，其中$\mu_i = \frac{1}{N} \sum_{j=1}^{N} s_{ij}$和$\sigma_i = \sqrt{\frac{1}{N} \sum_{j=1}^{N} (s_{ij} - \mu_i)^2}$，$s_{ij}$表示模型$j$给出的任务完成分数，$N$是模型数量。最终报告的CV是所有任务的平均值：$CV = \frac{1}{M} \sum_{i=1}^{M} CV_i$，其中$M=50$是基准任务的数量。如表7所示，去除提示词重排和分数平均导致CV为16.8%，而启用它们则将CV降低到15.1%，表明LLM之间的一致性有所提高。

人类一致性得分。我们进一步评估了LLM评判者与人类偏好的一致性。三名人类标注员独立审查了每个评判流程产生的不同维度的分数，并以3分制评定他们的一致性：0表示不同意，1表示部分同意，2表示完全同意。最终的人类一致性得分是所有标注员和任务的平均值。如表7所示，没有提示词重排和分数平均的流程平均一致性得分为1.24（满分2分），而采用提示词扰动的流程将该得分提高到1.43，表明该策略也影响了人类感知的评估质量。

表7 | 提示词重排和分数平均的消融研究。
提示词重排和分数平均的消融研究。

A5 结论

本文介绍了MCP-Bench，这是一个用于在现实的、基于生态系统的工具使用场景中评估LLM代理的大规模基准。MCP-Bench基于MCP，将代理连接到28个生产服务器和250个工具，从而实现了复杂的多跳工作流和跨领域编排。我们的自动化任务合成流程生成了104个具有挑战性的模糊指令任务，需要强大的代理能力才能解决。通过我们结合了基于规则的检查和LLM评判者评分的评估框架，我们揭示了即使是最先进的模型也在不同能力上存在困难，例如依赖链合规性、在嘈杂环境下选择工具以及长远规划。

A6 附录

A.1. 使用的MCP服务器详情

在表8中，我们展示了所涉及的MCP服务器及其相关工具的详细描述。

表8 | 使用的MCP服务器中的工具和描述详情。
使用的MCP服务器中的工具和描述详情。
表8（续）
表8（续）
表8（续）
表8（续）
表8（续）
表8（续）
表8（续）
表8（续）
表8（续）
表8（续）
表8（续）
表8（续）
表8（续）
表8（续）
表8（续）
表8（续）
表8（续）
表8（续）
表8（续）
表8（续）
表8（续）

A.2. 任务执行代理使用的提示详情

本节展示了MCP-Bench中任务执行代理使用的详细提示。

战略规划提示

目的：多轮执行的战略决策和工具规划

你是一个为多工具AI代理进行战略决策的专家，使用提供的工具来执行任务。

任务："{task}"
当前轮次：{round_num}
所有服务器上的可用工具：

决策与规划：

  1. 评估原始任务是否已完全完成
  2. 如果未完成，决定下一轮是否会带来显著价值
  3. 如果继续，为本轮规划并行工具执行

并行执行规划（如果继续）：

必需的JSON响应格式：

{
  "reasoning": "<对你的决定和并行执行计划的详细解释>",
  "should_continue": true/false,
  "planned_tools": [
    {
      "tool": "server:tool_name",
      "parameters": { "param": "value" }
    }
  ]
}

最终解决方案生成提示

目的：将多轮执行结果整合成最终的综合答案

你是一个为多工具AI代理执行提供解决方案的合成专家。

原始任务："{task}"

一个多轮执行过程已经完成，在多个MCP服务器上总共进行了{total_executions}次工具调用。

累积信息和结果：

{accumulated_information}

任务要求：

根据原始任务和从多个服务器收集的所有信息，提供一个直接解决用户请求的最终、全面且结构良好的答案。

综合关键发现，并以清晰、有组织的方式呈现，展示不同服务器能力是如何结合的。

综合指南：

内容摘要提示

目的：压缩大型执行结果以减少token使用

你是一个乐于助人的助手。我需要你帮助从内容中提取关键信息。

将以下内容总结到少于{threshold}个token，同时保留所有重要信息：

内容：{content}

总结后的内容：

摘要要求：

A.3. 任务合成使用的提示详情

本节展示了MCP-Bench中任务合成使用的详细提示。

任务生成提示

目的：生成具有深度工具依赖的复杂任务

你是一名任务设计师，负责测试使用MCP工具的AI代理。

步骤1：分析并创建工具依赖关系

分析这些可用工具，并为你的任务场景创建有意义的依赖关系：{tool_descriptions}

同时考虑：

A) 内在依赖（工具自然的输入/输出关系）
* 哪些工具自然地产生其他工具消费的数据
* 标准工作流模式（搜索 → 获取 → 分析）

B) 基于场景的依赖（为你的任务创建逻辑连接），例如：
* 工具A的结果决定下一步使用哪个工具
* 工具B的输出为工具C设置参数
* 工具D验证或反驳工具E的发现
* 并行工具的结果必须被组合
* 结果触发重新分析的迭代循环

在"dependency_analysis"字段中记录你的依赖分析，描述：
* 关键工具链和数据流
* 关键决策点
* 并行与顺序要求
* 跨服务器依赖（对于多服务器任务）

对于多服务器任务 ({server_name})，创建跨服务器依赖：
* 服务器A的数据影响服务器B的查询
* 不同数据源之间的交叉验证
* 一个服务器的限制触发回退到另一个服务器

步骤2：设计一个复杂任务

根据你的依赖分析，创建一个任务，该任务：
* 创造需要大量工具调用的最大复杂性
* 必须使用所有可用服务器的工具
* 如果可用服务器多于1个，必须考虑服务器间依赖

如果合适，你可以创建具有以下属性的任务：
* 深度依赖链，其中工具B需要工具A的输出，工具C需要B的输出，等等。
* 基于中间结果的多个决策分支
* 迭代优化：初步发现导致更深入的调查
* 交叉验证：使用多个工具验证关键发现
* 数据转换：一个工具的输出在进入下一个工具前需要处理
* 条件工作流：如果条件X，则工作流Y，否则工作流Z

关键数据要求：

  1. 所有任务必须是自包含的，并且可以在没有任何外部依赖的情况下执行

  2. 绝不引用外部资源，如：

    • URL（如 "https://api.example.com" 或任何外部API）
    • 本地文件（如 "user-management.yaml" 或 "config.json"）
    • 数据库或外部系统
    • "我们的API"、"我们的系统"、"我们的数据库"

  3. 所有数据必须来自：

    • 提供的工具本身（它们可以生成/获取/计算的内容）
    • 你在任务中指定的具体值（数字、名称、参数）

  4. 绝不使用模糊的引用：

    • "用户提供的参数" 或 "用户指定的"
    • "从数据库获取" 或 "从外部源检索"
    • "基于用户偏好" 或 "根据输入"
    • "指定的位置/值" 或 "待定"

  5. 始终提供具体值：

    • 具体数字（例如，"分析热交换器，入口温度80°C，出口60°C，流速0.5 kg/s"）
    • 命名实体（例如，"分析旧金山的天气"，而不是"指定的城市"）

    • 对于位置：使用城市名、地标名或一般区域，而不是具体的街道地址

      • 好的："旧金山"、"时代广场"、"中央公园区域"、"西雅图市中心"
      • 坏的："主街123号"、"公园大道456号"、具体的门牌号或街道地址

    • 确切的阈值（例如，"如果效率低于85%则报警"，而不是"期望的阈值"）

    • 始终使用相对日期/时间（例如，"未来7天"、"过去3个月"、"即将到来的一周"，而不是"2024年1月"或"2024-01-15"）

  6. 如果任务涉及分析，请在任务描述中提供所有输入数据：

    • 对于计算：提供所有需要的数字、公式和单位
    • 对于搜索：提供具体的搜索词和标准
    • 对于比较：提供具体项目及其属性
    • 对于优化：提供当前值和目标指标

要求：

  1. 必须要求以特定顺序使用多个工具
  2. 工具B应需要工具A的输出（依赖链）
  3. 包括基于中间结果的决策点
  4. 对商业/研究目的具有现实价值
  5. 定义预期的分析和输出格式
  6. 任务必须可立即执行——代理永远不需要请求更多信息
  7. 任务应可通过使用提供的工具执行和解决。你需要注意所提供工具的功能和输出。

输出格式：

仅输出一个JSON对象（不是数组）。始终使用相对日期/时间：

{
  "task_id": "task_XXX",
  "task_description": "利用已识别的工具依赖关系的详细任务",
  "dependency_analysis": "你在步骤1中的分析——描述此任务要求的关键依赖关系、工具链、决策点和数据流模式"
}

专注于创建一个不理解工具依赖关系就无法完成的任务。

任务质量评估提示

目的：在可解性和实用性维度上评估任务质量

在两个维度上评估此任务的质量：

任务描述: {task_description}

模糊描述（代理看到的内容）: {fuzzy_description}

可用工具: {tool_descriptions}

评估标准：

  1. 可解性 (1-10)：

    • 10：所有必需数据都已提供，工具与需求完美匹配，成功标准清晰
    • 8-9：任务明确可用给定工具解决，可接受轻微的模糊性
    • 6-7：大部分可解决，但某些步骤可能具有挑战性或不清楚
    • 4-5：工具覆盖范围或数据要求存在显著差距
    • 1-3：无法用可用工具有意义地完成任务

    考虑：
    * 所有必要的工具都可用吗？
    * 所有必需的数据都已提供（无外部依赖）？
    * 代理能根据工具的功能和输出来实现所述目标吗？
    * 成功标准是否清晰可衡量？

  2. 实用性 (1-10)：

    • 10：关键的商业/研究价值，完美解决现实世界问题
    • 8-9：强大的实用价值，对决策或运营有用
    • 6-7：中等价值，有趣但非关键
    • 4-5：实用价值有限，主要是学术练习
    • 1-3：琐碎或人为的任务，没有实际应用

    考虑：
    * 这是否解决了真实的商业或研究需求？
    * 结果是否具有可操作性和价值？
    * 复杂性是否因结果而合理？
    * 它是否测试了有意义的代理能力？

输出格式：

以JSON格式提供分数和简要反馈：

{
  "solvability_score": <number 1-10>,
  "utility_score": <number 1-10>,
  "solvability_feedback": "可解性评估的简要解释",
  "utility_feedback": "实用性评估的简要解释"
}

任务描述模糊化提示

目的：将详细任务转换为自然的、对话式的用户请求

将这个详细任务转换为一个自然的、对话式的用户请求，真正测试代理的推理能力。

原始详细任务: {detailed_task}

可用工具: {len(tools)} 个工具（但在模糊版本中不要提及它们）

关键：创建一个真正自然的请求

绝对禁止：

相反，创建一个自然的对话：

完全隐藏任务结构：

不要说："我需要分析AAPL、GOOGL和MSFT的财务指标"
而要说："我最近一直在考虑调整我的投资组合，很好奇像AAPL、GOOGL和MSFT这样的科技巨头最近表现如何。你觉得现在哪一个看起来最强劲？"

不要说："搜索关于CRISPR的最新论文并总结关键发现"
而要说："我下周要在一个报告会上做关于基因编辑的演讲。CRISPR最近有什么新动向？有什么我应该知道的突破性发现吗？"

不要说："计算热效率并优化热交换器参数"
而要说："我们的热交换器入口温度80°C，出口60°C，流量0.5 kg/s。我觉得效率不太高。你能帮我搞清楚是怎么回事，也许还能告诉我怎么改进吗？"

自然地保留关键数据：

让它听起来像一个真人：

自然模糊描述的例子：

例1（金融）：
"最近我一直在关注我的科技股，老实说，我不确定是该持有还是卖出。AAPL、GOOGL和MSFT占了我投资组合的大部分。考虑到市场上的各种情况，你认为哪一个前景最好？我特别担心它们的债务水平和现金流状况。我需要一些真实的数据来支持任何决定，而不仅仅是凭感觉。"

例2（研究）：
"我正在准备一个期刊俱乐部的报告，大家都在谈论CRISPR的新进展。过去几个月到底有什么新东西？我一直听说脱靶效应问题解决了，但找不到可靠的证据。如果能从最近的研究中得到具体的发现，而不仅仅是炒作，那就太好了。"

例3（技术）：
"我们的热交换器设置有问题——入口80°C，出口60°C，流量大约0.5 kg/s。我经理认为我们在浪费能源，但我需要用实际数字来证明。你能帮我算出我们目前的效率是多少，也许能建议我们应该调整哪些参数吗？我需要可靠的计算来说服他们批准更改。"

关键：自然地以证据要求结束对话：

不要说："请提供基于证据的分析和具体数据"
而要说："我真的需要这方面的实际数据——不能只凭意见去见老板。无论你找到什么，确保它有真实的数字或可靠的来源支持，好吗？"

始终使用相对日期/时间（例如，"未来7天"、"过去3个月"、"即将到来的一周"，而不是"2024年1月"或"2024-01-15"）

只返回自然的、对话式的模糊描述——让它听起来像一个真人在寻求帮助，而不是一个机器人在执行任务。

A.4. LLM评判者详情

本节展示了我们基准中LLM评判者使用的详细提示。

LLM评判者提示

系统角色：

你是一位公正的评估员，负责评判一个AI代理在多服务器上基于工具的任务执行质量。

用户：

你必须仅根据任务、解决方案和工具使用中的证据来评分。你的评估应是：
* 客观的（避免受语言流畅性或格式影响）
* 有理有据的（为每个分数附上具体原因）
* 抗偏见的（忽略叙事风格、冗长或格式修饰）

呈现给代理的任务："{task}"
具体任务参考（仅供评估上下文使用）：
注意：代理没有看到这个具体版本。它只看到了上面的任务。代理看到的任务是具体任务的模糊版本。代理对模糊任务的解释可能不同，但仍然有效。
"{concrete_task_description}"

依赖分析：
注意：此分析是在任务创建期间生成的，以帮助理解工具依赖关系。代理没有看到此分析。它作为评估目的的参考提供。
{dependency_analysis}
最终解决方案："{final_solution}"
总轮数：{total_rounds}
执行摘要：
{execution_summary}
可用工具（{num_tools}个工具）：

任务完成度评分准则（每个子维度1-10分）

1. 任务实现
* 1–3：完美完成10–30%的要求。
* 4–6：完美完成40–60%的要求。
* 7–8：完美完成70–80%的要求。
* 9–10：完美完成90–100%的要求。

2. 信息溯源
* 1–3：10–30%的声明完美地基于工具输出。
* 4–6：40–60%的声明完美地基于工具输出。
* 7–8：70–80%的声明完美地基于工具输出。
* 9–10：90–100%的声明完美地基于工具输出。

工具使用评分准则（每个子维度1-10分）

1. 工具适当性
* 1–3：10–30%的工具为其子任务的选择是完美的。
* 4–6：40–60%的工具为其子任务的选择是完美的。
* 7–8：70–80%的工具为其子任务的选择是完美的。
* 9–10：90–100%的工具为其子任务的选择是完美的。

2. 参数准确性
* 1–3：10–30%的工具调用具有完全准确和完整的参数。
* 4–6：40–60%的工具调用具有完全准确和完整的参数。
* 7–8：70–80%的工具调用具有完全准确和完整的参数。
* 9–10：90–100%的工具调用具有完全准确和完整的参数。

规划有效性与效率评分准则（每个子维度1-10分）

1. 依赖感知
* 1–3：10–30%的依赖链被完美执行。
* 4–6：40–60%的依赖链被完美执行。
* 7–8：70–80%的依赖链被完美执行。
* 9–10：90–100%的依赖链被完美执行。

2. 并行性与效率
* 1–3：超过70%的冗余调用 或 少于30%的可并行任务被并行执行。
* 4–6：40–60%的冗余调用 或 40–60%的可并行任务被并行执行。
* 7–8：20–30%的冗余调用 且 70–80%的可并行任务被并行执行。
* 9–10：少于10%的冗余调用 且 90–100%的可并行任务被并行执行。

基于百分比的评分系统：

如何计算分数：
对于每个维度，计算缺陷率：
* 缺陷率 = (问题数量 / 总机会数) × 100%
然后将缺陷率映射到分数：
* 0–10% 缺陷 → 9–10分（优秀到完美）
* 10–30% 缺陷 → 7–9分（良好表现）
* 30–50% 缺陷 → 5–7分（一般表现）
* 50–70% 缺陷 → 3–5分（差劲表现）
* 70–100% 缺陷 → 0–3分（失败）

如何评分：
1. 在评估百分比时，对于何为“完美执行”要极其严格
2. “完美”意味着以下所有条件都必须为真：
* 正确的工具选择（不仅是“能用”，而是最优选择）
* 完整且准确的参数（不仅是有效，而是理想）
* 零冗余（没有重复或不必要的调用）
* 适当的错误处理（从任何失败中优雅恢复）
* 高效执行（尽可能并行，最少轮次）
* 简洁的输出（除非要求，否则无冗长解释）

  1. 如果以上任何一项缺失，该部分就不是完美执行（计为0%）
  2. 示例：任务正确完成但有1个冗余调用 = 该部分完美度为0%

关键原则：
1. 始终按百分比计算，而非绝对数量
2. 100次调用中有10个错误(10%) = 与10次调用中有1个错误(10%)得分相同
3. 考虑每个维度的机会计数：
* 工具调用：总共进行了多少次调用？
* 并行化：有多少任务本可以并行？
* 参数：所有调用中总共有多少参数？
* 声明：做出了多少事实陈述？
* 依赖关系：存在多少依赖关系？

  1. 按复杂性归一化——不要惩罚复杂任务：
    • 简单任务：5步中有1个错误（20%缺陷）= 7分
    • 复杂任务：20步中有4个错误（20%缺陷）= 7分

关键：应用对“完美执行”最严格的解释。如有任何疑问，打分要更低。

具体评分示例与比例：

任务实现：

工具适当性：
* 19/20工具最优（5%缺陷率）= 9分
* 16/20工具最优（20%缺陷率）= 8分
* 12/20工具最优（40%缺陷率）= 6分
* 8/20工具最优（60%缺陷率）= 4分

并行性与效率：
* 10个可并行任务中有9个并行完成（10%错过）= 9分
* 10个可并行任务中有8个并行完成（20%错过）= 8分
* 10个可并行任务中有6个并行完成（40%错过）= 6分
* 10个可并行任务中有4个并行完成（60%错过）= 4分

信息溯源：
* 20个声明中有19个有证据支持（5%无支持）= 9分
* 20个声明中有16个有证据支持（20%无支持）= 8分
* 20个声明中有12个有证据支持（40%无支持）= 6分
* 20个声明中有8个有证据支持（60%无支持）= 4分

参数准确性：
* 100个参数中有95个完美（5%缺陷率）= 9分
* 100个参数中有80个完美（20%缺陷率）= 8分
* 100个参数中有60个完美（40%缺陷率）= 6分
* 100个参数中有40个完美（60%缺陷率）= 4分

格式注意：在不需要JSON时输出文本 = 无惩罚（0%缺陷）
格式注意：明确要求JSON但缺失 = 算作未完成要求

记住：大多数真实世界的执行得分应为4–6分。8分以上应属特例。

评分前最后提醒：
关键评估要求：
  1. 你必须将每个分数映射到评分准则中确切的百分比范围。
  2. 任务完成度和工具选择必须根据具体任务参考进行评估，而不是模糊任务。
  3. 规划有效性应根据正确处理的依赖关系比例进行评估，而不是执行的绝对步骤数或与依赖分析的完全一致性。
  4. 首先计算完成/成功的实际百分比，然后分配相应的分数范围。
  5. 重要：关注完成比例而非绝对数量——完成7/10步(70%)应与完成14/20步(70%)得分相似，无论任务复杂性如何。请根据完成百分比和比例成功进行评分，而不是调用的工具或执行的步骤的绝对数量。

请以这个确切的JSON格式返回你的评估评分和理由：

{
  "task_fulfillment_reasoning": "解释代理在多大程度上完成了详细的任务目标，引用具体任务描述中的具体内容以及完成了多少百分比。",
  "grounding_reasoning": "解释代理的输出在多大程度上基于实际的工具结果，而不是无支持的声明。",
  "tool_appropriateness_reasoning": "解释为每个子任务要求选择的工具是否适当。",
  "parameter_accuracy_reasoning": "解释工具调用中使用的参数的准确性和完整性，注意任何缺失的必需参数或不正确的值。",
  "dependency_awareness_reasoning": "解释代理在多大程度上理解并遵守了任务依赖关系（处理正确的依赖关系百分比），参考提供的依赖分析部分。",
  "parallelism_efficiency_reasoning": "解释执行的效率，包括并行性的使用和避免冗余，参考提供的依赖分析部分。",
  "task_fulfillment": X,
  "grounding": X,
  "tool_appropriateness": X,
  "parameter_accuracy": X,
  "dependency_awareness": X,
  "parallelism_and_efficiency": X
}

只返回JSON对象。

A.5. 所涉及工具的输入模式示例

输入模式示例1：医疗计算器中的血压百分位数

工具: bp_children
输入模式:

{
  "type": "object",
  "properties": {
    "years": {
      "type": "integer",
      "minimum": 1,
      "maximum": 17,
      "description": "年龄（年）"
    },
    "months": {
      "type": "integer",
      "minimum": 0,
      "maximum": 11,
      "description": "额外的年龄月份"
    },
    "height": {
      "type": "integer",
      "minimum": 50,
      "maximum": 250,
      "description": "身高（厘米）"
    },
    "sex": {
      "type": "string",
      "enum": ["male", "female"],
      "description": "患者性别"
    },
    "systolic": {
      "type": "integer",
      "minimum": 50,
      "maximum": 250,
      "description": "收缩压（mmHg）"
    },
    "diastolic": {
      "type": "integer",
      "minimum": 30,
      "maximum": 150,
      "description": "舒张压（mmHg）"
    }
  },
  "required": ["years", "months", "height", "sex", "systolic", "diastolic"]
}

输入模式示例2：肾功能计算器中的多参数eGFR

工具: egfr_epi_cr_cys
输入模式:

{
  "type": "object",
  "properties": {
    "scr": {
      "type": "number",
      "minimum": 0.1,
      "maximum": 50.0,
      "multipleOf": 0.01,
      "description": "血清肌酐水平 mg/dL (0.1-50.0)"
    },
    "scys": {
      "type": "number",
      "minimum": 0.1,
      "maximum": 10.0,
      "multipleOf": 0.01,
      "description": "血清胱抑素C水平 mg/L (0.1-10.0)"
    },
    "age": {
      "type": "integer",
      "minimum": 18,
      "maximum": 120,
      "description": "患者年龄（年）(18-120)"
    },
    "male": {
      "type": "boolean",
      "description": "如果患者为男性则为True，女性为False"
    }
  },
  "required": ["scr", "scys", "age", "male"],
  "additionalProperties": false
}

输入模式示例3：科学计算中的张量创建

工具: create_tensor
输入模式:
输入模式示例3：科学计算中的张量创建

"description": "张量形状，为整数列表（最多10个维度）"
    },
    "values": {
      "type": "array",
      "items": { "type": "number" },
      "minItems": 1,
      "maxItems": 1000000,
      "description": "用于填充张量的浮点数扁平列表"
    },
    "name": {
      "type": "string",
      "pattern": "^[a-zA-Z][a-zA-Z0-9_]*$",
      "minLength": 1,
      "maxLength": 50,
      "description": "变量名（字母数字和下划线，以字母开头）"
    }
  },
  "required": ["shape", "values", "name"],
  "additionalProperties": false
}

输入模式示例4：线性代数中的矩阵基变换

工具: change_basis
输入模式:

{
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "pattern": "^[a-zA-Z][a-zA-Z0-9_]*$",
      "description": "张量存储中矩阵的名称"
    },
    "new_basis": {
      "type": "array",
      "items": {
        "type": "array",
        "items": { "type": "number" },
        "minItems": 1,
        "maxItems": 1000
      },
      "minItems": 1,
      "maxItems": 1000,
      "description": "二维数组，其中列是新的基向量"
    }
  },
  "required": ["name", "new_basis"],
  "additionalProperties": false
}

输入模式示例5：生物医学研究中的多领域搜索

工具: article_searcher
输入模式:

{
  "type": "object",
  "properties": {
    "chemicals": {
      "anyOf": [
        {"type": "array", "items": {"type": "string", "minLength": 2}},
        {"type": "string", "minLength": 2},
        {"type": "null"}
      ],
      "description": "要搜索的化学品/药物名称"
    },
    "genes": {
      "anyOf": [
        {
          "type": "array",
          "items": {
            "type": "string",
            "pattern": "^[A-Z][A-Z0-9]*$",
            "minLength": 2,
            "maxLength": 20
          }
        },
        {"type": "string", "pattern": "^[A-Z][A-Z0-9]*$"},
        {"type": "null"}
      ],
      "description": "基因符号（大写字母数字）"
    },
    "variants": {
      "anyOf": [
        {
          "type": "array",
          "items": {
            "type": "string",
            "pattern": "^(p\.|c\.|g\.|m\.|n\.)?[A-Z]?[0-9]+[A-Z*]?$"
          }
        },
        {"type": "string"},
        {"type": "null"}
      ],
      "description": "遗传变异（HGVS表示法）"
    },
    "include_preprints": {
      "type": "boolean",
输入模式示例5：生物医学研究中的多领域搜索
输入模式示例5：生物医学研究中的多领域搜索

A.6. 任务详情

本节展示了MCP-Bench中更多任务的示例（表9），并列出了构建任务的服务器组合（表10）。

表9 | MCP-Bench中更多任务示例。
MCP-Bench中更多任务示例。
表9（续）
表9（续）
表9（续）
表9（续）
表9（续）
表9（续）

表10 | MCP-Bench中使用的MCP服务器组合。
MCP-Bench中使用的MCP服务器组合。