协议修订版: draft
用户交互模型
MCP 中的工具被设计为模型控制的,这意味着语言模型可以基于其上下文理解和用户的提示自动发现和调用工具。 但是,实现可以自由地通过任何适合其需求的界面模式来暴露工具——协议本身并不强制要求任何特定的用户交互模型。能力
支持工具的服务器必须声明tools 能力:
listChanged 表示当可用工具列表发生变化时,服务器是否会发出通知。
协议消息
列出工具
要发现可用工具,客户端发送tools/list 请求。此操作支持分页。
请求:
调用工具
要调用工具,客户端发送tools/call 请求:
请求:
列表变更通知
当可用工具列表发生变化时,声明了listChanged 能力的服务器应该发送通知:
消息流程
数据类型
工具
工具定义包括:name:工具的唯一标识符title:可选的用于显示的人类可读工具名称description:功能的人类可读描述inputSchema:定义预期参数的 JSON SchemaoutputSchema:可选的定义预期输出结构的 JSON Schemaannotations:可选的描述工具行为的属性
工具名称
- 工具名称应该在 1 到 128 个字符长度之间(包括)。
- 工具名称应该被视为区分大小写。
- 以下应该是唯一允许的字符:大写和小写 ASCII 字母 (A-Z, a-z)、数字 (0-9)、下划线 (_)、破折号 (-) 和点 (.)
- 工具名称不应该包含空格、逗号或其他特殊字符。
- 工具名称在服务器内应该是唯一的。
- 有效的工具名称示例:
- getUser
- DATA_EXPORT_v2
- admin.tools.list
工具结果
工具结果可能包含结构化或非结构化内容。 非结构化内容在结果的content 字段中返回,可以包含不同类型的多个内容项:
所有内容类型(文本、图像、音频、资源链接和嵌入资源)都支持可选的
注解,这些注解提供
关于受众、优先级和修改时间的元数据。这是资源和提示词使用的相同
注解格式。
文本内容
图像内容
音频内容
资源链接
工具可以返回指向资源的链接,以提供额外上下文或数据。在这种情况下,工具将返回一个可以被客户端订阅或获取的 URI:工具返回的资源链接不能保证出现在
resources/list 请求的结果中。嵌入资源
资源可以被嵌入以提供额外上下文或数据,使用合适的URI 方案。使用嵌入资源的服务器应该实现resources 能力:
结构化内容
结构化内容作为 JSON 对象在结果的structuredContent 字段中返回。
为了向后兼容,返回结构化内容的工具也应该在 TextContent 块中返回序列化的 JSON。
输出模式
工具也可以为结构化结果的验证提供输出模式。 如果提供了输出模式:- 服务器必须提供符合此模式的结构化结果。
- 客户端应该根据此模式验证结构化结果。
- 启用对响应的严格模式验证
- 为更好地与编程语言集成提供类型信息
- 指导客户端和 LLM 正确解析和利用返回的数据
- 支持更好的文档和开发者体验
错误处理
工具使用两种错误报告机制:-
协议错误:用于如下问题的标准 JSON-RPC 错误:
- 未知工具
- 无效参数
- 服务器错误
-
工具执行错误:在工具结果中报告,带有
isError: true:- API 失败
- 无效输入数据
- 业务逻辑错误
安全注意事项
-
服务器必须:
- 验证所有工具输入
- 实现适当的访问控制
- 对工具调用进行速率限制
- 清理工具输出
-
客户端应该:
- 对敏感操作提示用户确认
- 在调用服务器之前向用户显示工具输入,以避免恶意或意外的数据泄露
- 在传递给 LLM 之前验证工具结果
- 为工具调用实现超时
- 为审计目的记录工具使用情况