用户交互模型
提示被设计为由用户控制,意味着它们从服务器暴露给客户端,意图是让用户能够显式地选择使用它们。 通常,提示会通过用户界面中由用户发起的命令触发,这允许用户自然地发现和调用可用的提示。 例如,作为斜杠命令:
然而,实现者可以自由地通过任何适合其需求的界面模式暴露提示——协议本身不强制规定任何特定的用户交互模型。
能力
支持提示的服务器**必须(MUST)**在初始化期间声明prompts 能力:
listChanged 指示服务器是否会在可用提示列表变化时发出通知。
协议消息
列出提示
要检索可用的提示,客户端发送一个prompts/list 请求。此操作支持分页。
请求:
获取一个提示
要检索一个特定的提示,客户端发送一个prompts/get 请求。参数可以通过补全 API自动补全。
请求:
列表变更通知
当可用提示列表变化时,声明了listChanged 能力的服务器**应当(SHOULD)**发送一个通知:
消息流
数据类型
Prompt
一个提示定义包括:name:提示的唯一标识符title:用于显示目的的可选人类可读提示名称。description:可选的人类可读描述icons:用于在用户界面中显示的可选图标数组arguments:用于自定义的可选参数列表
PromptMessage
提示中的消息可以包含:role:“user” 或 “assistant”,以指示说话者content:以下内容类型之一:
提示消息中的所有内容类型都支持可选的注解,用于关于受众、优先级和修改时间的元数据。
文本内容
文本内容表示纯文本消息:图像内容
图像内容允许在消息中包含视觉信息:音频内容
音频内容允许在消息中包含音频信息:嵌入的资源
嵌入的资源允许在消息中直接引用服务器端资源:- 一个有效的资源 URI
- 适当的 MIME 类型
- 文本内容或 base64 编码的 blob 数据
错误处理
服务器**应当(SHOULD)**为常见的失败情况返回标准的 JSON-RPC 错误:- 无效的提示名:
-32602(Invalid params) - 缺少必需的参数:
-32602(Invalid params) - 内部错误:
-32603(Internal error)
实现考量
- 服务器**应当(SHOULD)**在处理之前校验提示参数
- 客户端**应当(SHOULD)**为大型提示列表处理分页
- 双方**应当(SHOULD)**尊重能力协商