Skip to main content
模型上下文协议 (MCP) 允许服务器暴露可由语言模型调用的工具。工具使模型能够与外部系统交互,例如查询数据库、调用 API 或执行计算。每个工具都由一个名称唯一标识,并包含描述其模式的元数据。
For brevity, the request examples on this page omit the _meta request metadata (io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientInfo, and io.modelcontextprotocol/clientCapabilities). Every request MUST include the required _meta fields; see _meta.

用户交互模型

MCP 中的工具设计为 模型控制,这意味着语言模型可以根据其上下文理解和用户的提示自动发现和调用工具。 然而,实现可以自由地通过任何适合其需求的接口模式暴露工具—协议本身并不强制任何特定的用户交互模型。
为了信任、安全和安全性,应当 始终有人类参与循环,能够拒绝工具调用。应用程序 应当
  • 提供清晰显示哪些工具正暴露给 AI 模型的 UI
  • 在调用工具时插入清晰的视觉指示器
  • 向用户呈现操作确认提示,以确保人类参与循环

能力

支持工具的服务器 必须 声明 tools 能力:
listChanged 指示服务器是否在可用工具列表更改时发出通知。 声明 tools 能力的服务器 必须 以当前可供请求客户端使用的工具集合响应 tools/list 请求。该集合 可以 为空,也 可以 随时间变化(参见 列表变更通知),但 不得 因连接不同而变化,也 不得 作为该连接上其他请求的副作用而变化。该集合 可以 随请求中提供的授权而变化——例如,仅返回调用方已获授权范围允许的工具——因为凭据是每次请求的输入,而不是连接状态。 服务器 应当 按确定性顺序返回工具(即当底层工具集合未发生变化时,不同请求之间保持相同排序)。确定性排序使客户端能够可靠地缓存工具列表,并在模型上下文中包含工具时提高 LLM 提示缓存命中率。

协议消息

列出工具

要发现可用工具,客户端发送 tools/list 请求。此操作支持 分页缓存 请求:
响应:

调用工具

要调用工具,客户端发送 tools/call 请求: 请求:
响应:

需要输入的工具结果

服务器 可以tools/call 返回 InputRequiredResult,以表明在工具调用完成前还需要额外输入。这遵循 多轮往返请求 机制。 在使用输入响应重试请求时,客户端会在请求参数中包含 inputResponses,以及如果服务器提供了 requestState,则也会包含它: 需要输入的响应:
使用输入响应重试:
请注意,初始请求与重试请求中的 JSON-RPC id 必须 不同。

列表变更通知

当可用工具列表发生变化时,声明了 listChanged 能力的服务器 应当 向已打开带有 toolsListChanged: truesubscriptions/listen 流的客户端发送通知:

消息流

数据类型

工具

工具定义包括:
  • name: 工具的唯一标识符
  • title: 用于显示的可选人类可读工具名称。
  • description: 功能的人类可读描述
  • icons: 用于用户界面显示的可选图标数组
  • inputSchema: 定义预期参数的 JSON Schema
    • 遵循 JSON Schema 使用指南
    • 如果不存在 $schema 字段,则默认为 2020-12
    • 必须 是有效的 JSON Schema 对象(不能为 null
    • 对于没有参数的工具,请使用以下有效方式之一:
      • { "type": "object", "additionalProperties": false } - 推荐:显式仅接受空对象
      • { "type": "object" } - 接受任何对象(包括带有属性的对象)
    • 属性 可以 包含 x-mcp-header 注解,以将参数值暴露为 HTTP 头
  • outputSchema: 用于定义预期输出结构的可选 JSON Schema
  • annotations: 描述工具行为的可选属性
为了信任、安全和安全性,客户端 必须 将工具注解视为不可信,除非它们来自受信任的服务器。

工具名称

  • 工具名称 应当 长度在 1 到 128 个字符之间(包含)。
  • 工具名称 应当 被视为区分大小写。
  • 以下 应当 是唯一允许的字符:大写和小写 ASCII 字母 (A-Z, a-z)、数字 (0-9)、下划线 (_)、连字符 (-) 和点 (.)
  • 工具名称 不应当 包含空格、逗号或其他特殊字符。
  • 工具名称 应当 在服务器内唯一。
  • 示例有效工具名称:
    • getUser
    • DATA_EXPORT_v2
    • admin.tools.list
工具名称的唯一性范围限定于单个服务器。聚合来自多个服务器的工具的客户端或代理 可能 遇到命名冲突(例如,两个服务器各自暴露一个 search 工具),并且 应当 实现消歧策略,例如在工具名称前加上服务器标识符前缀。服务器 name(来自 serverInfo)不能保证在各服务器之间唯一,不应当 依赖它来进行消歧。

x-mcp-header

x-mcp-header 扩展属性允许服务器在使用 Streamable HTTP transport 时,将特定工具参数镜像到 HTTP 头中。 这使得网络中介(负载均衡器、代理、WAF)无需解析请求体即可根据参数值路由和处理请求。 x-mcp-header 属性直接放置在要镜像的属性的 JSON Schema 内。其值指定结果 Mcp-Param-{name} HTTP 头中的名称部分。 x-mcp-header 值的约束:
  • 不得 为空
  • 必须 匹配 HTTP field-name token 语法(1*tcharRFC 9110 第 5.1 节
  • 不得 包含控制字符,包括回车符(CR,\r)或换行符(LF,\n
  • inputSchema 中所有 x-mcp-header 值之间,必须 以不区分大小写的方式唯一
  • 必须 仅应用于原始类型(integer、string、boolean)的参数。 不允许 number 类型的参数。integer 值 必须 位于使用 IEEE754 双精度浮点数表示的整数安全范围内(−253+1 到 253−1)
  • 必须 仅应用于从模式根节点可_静态到达_的属性,如 工具参数中的自定义头部 中所定义, 该部分还定义了如何从调用参数中提取头部值
使用 Streamable HTTP transport 的客户端 必须 拒绝任何 x-mcp-header 值违反这些约束的工具定义。拒绝意味着客户端 必须 将无效工具从 tools/list 的结果中排除。客户端 应当 在拒绝工具定义时记录警告,包括工具名称和拒绝原因。这样可确保单个格式错误的工具定义不会阻止其他有效工具被使用。使用其他 transport(例如 stdio)的客户端 可以 完全忽略 x-mcp-header 注解。 带有 x-mcp-header 的工具定义示例:
在此示例中,当工具以 "region": "us-west1" 被调用时,客户端会向 HTTP 请求添加头 Mcp-Param-Region: us-west1
服务器开发者 不应当 使用 x-mcp-header 标记敏感参数(密码、API 密钥、令牌、PII),因为头值对网络中介可见。

工具结果

工具结果可能包含 结构化非结构化 内容。 非结构化 内容在结果的 content 字段中返回,并且可以包含多种不同类型的内容项:
所有内容类型(文本、图像、音频、资源链接和嵌入资源)都支持可选的 注解,提供有关受众、优先级和修改时间的元数据。这与资源和提示使用的注解格式相同。

文本内容

图像内容

音频内容

资源链接

工具 可以 返回指向 资源 的链接,以提供额外的上下文或数据。在这种情况下,工具将返回一个 URI,客户端可以订阅或获取该 URI:
资源链接支持与常规资源相同的 资源注解,以帮助客户端了解如何使用它们。
工具返回的资源链接不保证出现在 resources/list 请求的结果中。

嵌入资源

资源 可以 嵌入以使用合适的 URI scheme 提供额外的上下文或数据。使用嵌入资源的服务器 应当 实现 resources 能力:
嵌入资源支持与常规资源相同的 资源注解,以帮助客户端了解如何使用它们。

结构化内容

结构化内容以结果的 structuredContent 字段中的 JSON 值返回。这可以是任何 JSON 值(对象、数组、字符串、数字、布尔值或 null),前提是它符合工具的 outputSchema(如果定义了)。 为了向后兼容,返回结构化内容的工具 应当 还在 TextContent 块中返回序列化的 JSON。
structuredContent is server-produced result data and is unrelated to LLM “structured outputs” (schema-constrained model generation).

Output Schema

工具还可以提供输出模式以验证结构化结果。 如果提供了输出模式:
  • 服务器 必须 提供符合此模式的结构化结果。
  • 客户端 应当 针对此模式验证结构化结果。
带有输出模式的工具示例:
此工具的有效响应示例:
带数组输出模式的工具示例:
带数组输出的工具有效响应示例:
提供输出模式有助于客户端和 LLM 理解并正确处理结构化工具输出,其方式包括:
  • 启用对响应的严格模式验证
  • 提供类型信息以便更好地与编程语言集成
  • 指导客户端和 LLM 正确解析和利用返回的数据
  • 支持更好的文档和开发者体验

模式示例

带有默认 2020-12 模式的工具:

带有显式 draft-07 模式的工具:

无参数工具:

有状态工具

本节是关于工具设计的非规范性指导。该协议并没有状态句柄的概念;从网络传输的角度来看,句柄只是工具结果中的普通字符串,以及后续工具调用中的普通参数。
MCP 在协议层面没有会话,因此服务器不能依赖每个连接的隐式状态来关联前后两次工具调用。需要在调用之间维护状态的服务器——例如购物车、打开的浏览器上下文、数据库事务——应通过在创建工具中返回一个显式句柄,并在后续调用中将该句柄作为参数接收来实现。 例如,管理购物车的服务器可能会暴露:
模型负责将 basket_id 继续传递下去;服务器将购物车内容存储在该键下,并在每次调用时查找它们。 在设计句柄时,服务器应考虑:
  • 授权。 对于已认证的服务器,句柄只是一个名称,而不是一个能力。服务器应在每次调用时根据句柄验证调用者的授权。对于未认证的服务器,由于句柄本质上就是持有者令牌,应使用足够的熵生成(例如 UUIDv4),并设置有界的有效期。
  • 不透明性。 编码了内部结构的句柄容易被解析或猜测;不透明标识符则不会。
  • 生命周期。 由于句柄会超出任何单次连接的存活时间,服务器的保留策略应在创建工具的描述中说明(例如:“购物篮在 24 小时无活动后过期”),这样模型在决定是否创建状态时就能看到。
  • 过期错误。 对已过期或未知句柄的调用应返回相应的工具执行错误,以便模型可以通过创建新的句柄来恢复。

错误处理

工具使用两种错误报告机制:
  1. 协议错误 表明请求结构本身存在问题,模型不太可能修复这些问题: 它们作为标准 JSON-RPC 错误返回:
  2. 工具执行错误 包含可操作的反馈,语言模型可以使用这些反馈进行自我纠正并使用调整后的参数重试:
    • API 故障
    • 输入验证错误(例如,日期格式错误、值超出范围)
    • 业务逻辑错误
    它们在工具结果中通过 isError: true 报告:
客户端 可以 向语言模型提供协议错误,尽管这些错误不太可能导致成功恢复。
客户端 应该 向语言模型提供工具执行错误以启用自我纠正。

安全注意事项

  1. 服务器 必须
    • 验证所有工具输入
    • 实施适当的访问控制
    • 限制工具调用速率
    • 清理工具输出
  2. 客户端 应该
    • 对敏感操作请求用户确认
    • 在调用服务器之前向用户显示工具输入,以避免恶意或意外的数据泄露
    • 在将工具结果传递给 LLM 之前进行验证
    • 在根据 inputSchemaoutputSchema 验证工具输入和输出时,遵循 $ref 解析要求
    • 为工具调用实现超时
    • 记录工具使用情况以供审计