提示
模型上下文协议(MCP)为服务器提供了一种标准化的方式,向客户端暴露提示模板。提示允许服务器提供用于与语言模型交互的结构化消息和指令。客户端可以发现可用的提示,检索其内容,并提供参数以定制它们。
用户交互模型
提示设计为 用户控制,意味着它们从服务器暴露给客户端,旨在让用户能够明确选择使用它们。
通常,提示会通过用户界面中用户发起的命令触发,这允许用户自然地发现和调用可用提示。
例如,作为斜杠命令:
然而,实现者可以自由选择适合其需求的任何界面模式来暴露提示——协议本身不强制要求特定的用户交互模型。
能力
支持提示的服务器 必须 在 初始化 期间声明 prompts
能力:
listChanged
指示服务器是否会在可用提示列表发生变化时发出通知。
协议消息
列出提示
要检索可用提示,客户端发送 prompts/list
请求。此操作支持 分页。
请求:
响应:
获取提示
要检索特定提示,客户端发送 prompts/get
请求。参数可以通过 补全 API 进行自动补全。
请求:
响应:
列表变更通知
当可用提示列表发生变化时,声明了 listChanged
能力的服务器 应该 发送通知:
消息流程
数据类型
提示
提示定义包括:
name
:提示的唯一标识符description
:可选的人类可读描述arguments
:可选的用于定制的参数列表
提示消息
提示中的消息可以包含:
role
:表示发言者的“user”或“assistant”content
:以下内容类型之一:
文本内容
文本内容表示纯文本消息:
这是用于自然语言交互的最常见内容类型。
图像内容
图像内容允许在消息中包含视觉信息:
图像数据 必须 进行 base64 编码,并包含有效的 MIME 类型。这支持多模态交互,其中视觉上下文很重要。
音频内容
音频内容允许在消息中包含音频信息:
音频数据 必须 进行 base64 编码,并包含有效的 MIME 类型。这支持多模态交互,其中音频上下文很重要。
嵌入资源
嵌入资源允许在消息中直接引用服务器端资源:
资源可以包含文本或二进制(blob)数据,并且 必须 包括:
- 有效的资源 URI
- 适当的 MIME 类型
- 文本内容或 base64 编码的 blob 数据
嵌入资源使提示能够无缝地将服务器管理的文档、代码样本或其他参考材料融入对话流程。
错误处理
服务器 应该 为常见失败情况返回标准的 JSON-RPC 错误:
- 无效提示名称:
-32602
(无效参数) - 缺少必需参数:
-32602
(无效参数) - 内部错误:
-32603
(内部错误)
实现注意事项
- 服务器 应该 在处理前验证提示参数
- 客户端 应该 处理大型提示列表的分页
- 双方 应该 遵守能力协商
安全
实现 必须 仔细验证所有提示输入和输出,以防止注入攻击或对资源的未授权访问。