MCP 工具指南：发现、检查与调用工具

什么是 MCP 工具？

MCP 工具是模型上下文协议中的模型控制原语，可让 AI 助手执行查询 API 或执行代码等操作。 MCP 规范将工具定义为三个原语之一（以及资源​​和提示），具有可通过工具/调用调用的名称、描述和输入模式。

Anthropic 于 2024 年 11 月推出了模型上下文协议，将工具定位为将人工智能助手从被动响应者转变为主动代理的机制。 MCP 规范将工具定义为具有四个组件的函数： [参考链接]

• 名称：LLM 用于在工具/调用请求中选择工具的唯一标识符
• 描述：自然语言解释该工具的用途以及何时使用它——法学硕士用于选择工具的主要信号
• inputSchema：描述工具接受的参数的 JSON 模式
• 注释：（可选）元数据，包括该工具是否幂等、是否需要批准或其危险级别

核心执行RPC是tools/call。客户端必须使用 tools/list 返回的准确工具名称，根据 inputSchema 验证参数，应用授权和批准策略，发送请求，然后区分工具报告的错误与协议或传输故障。

与资源（让模型读取数据）或提示（提供任务模板）不同，工具是由模型控制的——LLM 根据对用户请求和工具描述的理解来决定调用哪个工具。这就是 MCP 工具成为协议的操作原语的原因。

MCP 工具现在得到了广泛的生态系统的支持，但受欢迎程度并不是信任信号。在启用工具之前评估服务器发布者、包或端点、请求的凭据、工具架构、副作用、数据处理、更新策略和事件历史记录。

MCP 工具、资源、提示

MCP 服务器可以公开工具、资源和提示。使用与控制和意图相匹配的原语：工具执行操作，资源公开可寻址上下文，提示提供可重用的交互模板。

工具是模型控制的原语：LLM 决定何时以及如何调用它们。每个工具调用都会经过一个工具/调用请求，并将结果反馈到模型的上下文中以进行下一个推理步骤。

资源是服务器管理的数据，LLM 可以读取但不能修改。资源具有 URI 方案（如 file:// 或 db:// ），并通过 resources/list 和 resources/read 接口公开。该模型不控制何时读取资源 - 它通过单独的资源/读取调用来请求它们。

提示是可重用的提示模板，服务器可以为特定工作流程公开这些模板。服务器可能会公开“安全代码审查”提示，指导模型完成安全检查表，或提供“客户支持响应”模板来处理支持票证。提示是服务器控制的，而不是模型控制的。

关键区别：工具让模型行动，资源让模型阅读，提示指导模型如何思考。在实践中，许多 MCP 服务器主要公开工具 - MCP 规范指出工具是生态系统中最常实现的原语。 [参考链接]

何时使用每种功能：当法学硕士需要动态、上下文感知控制何时调用它时（例如搜索网络或执行代码），将功能建模为工具。当您希望服务器控制可用数据以及模型何时可以访问数据时（例如从数据库或文件系统中读取数据），请使用资源。当您想要强制执行特定的工作流程或推理模式（例如安全审核清单或客户响应模板）时，请使用提示。单个 MCP 服务器可以公开所有三个原语，但大多数生产服务器主要关注工具，因为它们支持最灵活的模型驱动行为。

当操作具有类型化参数、显式授权、有限副作用以及客户端可以验证的结果时，将操作建模为工具。不要把每个端点都变成工具；更小的、连贯的表面更容易让模型和人类进行推理。

工具/列表和工具/调用如何工作

发现在初始化和能力协商之后开始。客户端发送工具/列表，遵循分页（如果存在），缓存返回的定义，并在服务器发出列表更改信号时刷新目录。

第一阶段：工具/列表发现

当 MCP 客户端连接到服务器时，它会发送工具/列表 JSON-RPC 请求。服务器响应可用工具的完整列表，包括每个工具的名称、描述和输入架构。（tools/list）

// tools/list JSON-RPC request (client → server)
{"jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {}}

// tools/list response (server → client)
{"jsonrpc": "2.0", "id": 1, "result": {
  "tools": [
    {
      "name": "web_search",
      "description": "Search the web for current information. Use when you need up-to-date facts or prices.",
      "inputSchema": {
        "type": "object",
        "properties": {
          "query": {"type": "string", "description": "The search query"}
        },
        "required": ["query"]
      }
    }
  ]
}}

第 2 阶段：LLM 工具选择

主机决定工具定义如何到达模型。一个简单的主机可能包含每个模式；生产主机可以按策略、任务、服务器、用户范围或上下文预算进行过滤，并仅加载相关定义。

第 3 阶段：工具/调用执行

当法学硕士选择一个工具时，它会生成一个工具/调用请求，指定工具名称和参数。客户端将其路由到适当的服务器，服务器执行该工具并返回结果。（tools/call）

// tools/call JSON-RPC request (client → server)
{"jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": {
  "name": "web_search",
  "arguments": {"query": "MCP protocol token overhead 2026"}
}}

// tools/call response (server → client)
{"jsonrpc": "2.0", "id": 2, "result": {
  "content": [
    {"type": "text", "text": "Tool call completed with a validated result."}
  ]
}}

工具定义具有可测量的上下文成本，但每个工具没有通用的令牌成本。使用您的确切模型和客户端测量序列化名称、描述、输入模式、可选输出模式、提供程序包装器和提示缓存行为。

对于多个服务器，主机决定是立即连接并列出每个服务器还是动态发现服务器。它可以缓存每个服务器的工具/列表响应，按源对工具进行分组，按用户策略进行过滤，并仅连接当前任务所需的服务器。测量发送到模型的最终定义，而不是假设每个配置的工具都进入上下文。（tools/list）

在调用之前检查 MCP 工具架构

对于小型目录来说，加载每个定义是合理的。由于模式消耗了模型上下文的有意义的份额，官方客户指南建议切换到渐进式发现，而不是依赖于固定的工具计数阈值。

不要根据通用的“每个工具的令牌”数量来规划容量。序列化主机发送的确切定义，使用部署的模型对其进行标记，并以实际目录大小测试选择质量。官方 MCP 客户端最佳实践指南建议在定义变得重要时采用上下文百分比阈值和渐进式发现。 [参考链接]

模式足迹取决于序列化名称、描述、嵌套属性、枚举、示例、注释、输出模式、提供程序包装器和标记器行为。官方 MCP 客户端指南建议测量已部署的上下文共享，并在定义变得重要时切换到渐进式发现。 [参考链接]

大量的候选者也使得选择变得更加困难。通过不同的名称、特定于任务的描述、策略过滤、服务器分组以及在加载完整模式之前返回简短候选列表的搜索阶段来减少歧义。

使用三个互补的控制：定义进入上下文时的渐进发现限制、策略过滤限制哪些工具符合条件，以及编程执行可以将大量中间结果保留在沙箱内，而不是通过模型发送它们。

通过渐进式发现扩展 MCP 工具

有用的生产模式是目录→检查→执行。搜索轻量级目录，仅加载选定候选人的完整架构，然后通过拥有凭据、策略、超时和审核日志的代理路由批准的呼叫。

目录：渐进式工具发现

官方的渐进式发现模式为模型保留了一个可用的轻量级目录，按任务搜索候选者，并且仅在选择候选者进行检查后才加载完整的定义。 [参考链接]

渐进式发现避免了预先注入每个定义。官方指南建议在定义消耗已配置的上下文份额（例如 1%–5%）时进行切换，并仅在模型选择候选者后加载完整模式。

Discovery 添加了目录或搜索步骤，并且可以在工具阵列更改时影响提示缓存。缓存定义主机端，刷新 list_changed，保持排序稳定，并测量整个会话中的延迟和缓存未命中。

检查：仅加载相关工具架构

OpenAI API 支持 allowed_tools 参数，该参数限制模型针对给定请求考虑的工具。您无需在每个请求中公开所有工具，而是将与当前任务相关的特定工具列入白名单。 [参考链接]

对于客户支持代理，您可以将 [“lookup_order”、“issue_refund”、“escalate_ticket”] 列入白名单 — 忽略服务器中与支持任务无关的 90 个其他工具。这减少了令牌开销和决策退化。（["lookup_order", "issue_refund", "escalate_ticket"]）

权衡： allowed_tools 需要任务分类来确定将哪些工具列入白名单。如果用户的请求不明确，您可能会将错误的集合列入白名单。当任务类型是可预测的并且可以映射到工具子集时，它是最有效的。

执行：通过 QVeris 路由批准的呼叫

QVeris 可以充当原始列表一切模式之外的功能发现和路由层。应用程序按任务搜索，检查候选模式和提供者注释，然后仅调用批准的功能。

使用 QVeris 流程作为发现 → 检查 → 调用。 Discovery 返回候选人；检查确认标识符、参数、单位、出处、认证和限制；调用阶段仅接收经过验证的参数和策略批准的凭据。

# QVeris CLI discover — shows available capabilities without schema injection
# This command runs outside the MCP protocol loop, consuming zero prompt tokens

$ qveris discover --category search --limit 5

# Returns:
# web_search       Search the web for current information
# news_search      Search news articles and press releases
# academic_search  Search academic papers and preprints
# image_search     Search for images by description
# video_search     Search video platforms for content

# Tool invocation via subprocess (zero context overhead)
$ qveris call web_search --query "MCP token overhead benchmark"

当代理需要跨多个提供商的功能并且目录无法轻松适应上下文时，此模式最有用。为需要隔离凭据、本地执行或确定性提供商选择的工作负载保留直接 MCP 服务器。

路由层并不能消除安全责任。主机仍必须强制执行允许列表、验证模式和输出、保护凭据、限制成本和运行时间、保留来源并记录部分副作用。

通过设置指南开始使用 QVeris CLI：阅读安装指南。 [参考链接]

权衡是额外的依赖性和政策边界。在生产采用之前评估支持的功能、提供商来源、数据处理、配额、延迟、错误行为、可观察性和退出路径。

MCP 工具安全和验证清单

好的 MCP 工具足够窄以进行验证，足够描述性以进行正确选择，并且足够明确以供用户了解风险。同时将工具设计视为 API、安全性和模型接口问题。

在生产之前，记录准确的序列化模式足迹、已知答案测试、无效输入行为、权限拒绝、超时和重试策略、输出验证、list_changed 处理、日志、指标和回滚过程。