协议版本: 2025-03-26
用户交互模型
提示模板的设计是由用户控制的,意味着它们从服务器暴露给客户端,目的是让用户能够显式地选择并使用它们。 通常,提示模板会通过用户界面中的用户发起的命令触发,这允许用户自然地发现和调用可用的提示。 例如,作为斜杠命令:
能力声明
支持提示的服务器必须在初始化期间声明prompts 能力:
listChanged 表示服务器是否会在可用提示列表发生变化时发送通知。
协议消息
列出提示
要检索可用提示,客户端发送prompts/list 请求。此操作支持分页。
请求:
获取提示
要检索特定提示,客户端发送prompts/get 请求。参数可以通过补全API自动补全。
请求:
列表变化通知
当可用提示列表发生变化时,声明了listChanged 能力的服务器应该发送通知:
消息流
数据类型
Prompt(提示)
一个提示定义包括:name:提示的唯一标识符description:可选的、面向用户的描述arguments:用于自定义的可选参数列表
PromptMessage(提示消息)
提示中的消息可以包含:role:表示说话者的角色,可以是 “user” 或 “assistant”content:以下内容类型之一:
文本内容
文本内容表示普通文本消息:图像内容
图像内容允许在消息中包含视觉信息:音频内容
音频内容允许在消息中包含音频信息:嵌入资源
嵌入资源允许在消息中直接引用服务器端资源:- 有效的资源URI
- 合适的MIME类型
- 文本内容或base64编码的二进制数据
错误处理
服务器应该为常见的失败情况返回标准JSON-RPC错误:- 无效的提示名称:
-32602(参数无效) - 缺少必填参数:
-32602(参数无效) - 内部错误:
-32603(内部错误)
实现注意事项
- 服务器应该在处理前验证提示参数
- 客户端应该处理大量提示列表的分页
- 双方应该遵守能力协商