Skip to main content
模型上下文协议(MCP)为服务器提供了一种标准化的方式来向客户端暴露提示模板。提示允许服务器提供用于与语言模型交互的结构化消息和指令。客户端可以发现可用的提示、检索它们的内容,并提供参数来自定义它们。

用户交互模型

提示被设计为由用户控制,意味着它们从服务器暴露给客户端,意图是让用户能够显式地选择使用它们。 通常,提示会通过用户界面中由用户发起的命令触发,这允许用户自然地发现和调用可用的提示。 例如,作为斜杠命令: 作为斜杠命令暴露的提示示例 然而,实现者可以自由地通过任何适合其需求的界面模式暴露提示——协议本身不强制规定任何特定的用户交互模型。

能力

支持提示的服务器**必须(MUST)**在初始化期间声明 prompts 能力:
listChanged 指示服务器是否会在可用提示列表变化时发出通知。

协议消息

列出提示

要检索可用的提示,客户端发送一个 prompts/list 请求。此操作支持分页 请求:
响应:

获取一个提示

要检索一个特定的提示,客户端发送一个 prompts/get 请求。参数可以通过补全 API自动补全。 请求:
响应:

列表变更通知

当可用提示列表变化时,声明了 listChanged 能力的服务器**应当(SHOULD)**发送一个通知:

消息流

数据类型

Prompt

一个提示定义包括:
  • name:提示的唯一标识符
  • title:用于显示目的的可选人类可读提示名称。
  • description:可选的人类可读描述
  • icons:用于在用户界面中显示的可选图标数组
  • arguments:用于自定义的可选参数列表

PromptMessage

提示中的消息可以包含:
  • role:“user” 或 “assistant”,以指示说话者
  • content:以下内容类型之一:
提示消息中的所有内容类型都支持可选的注解,用于关于受众、优先级和修改时间的元数据。

文本内容

文本内容表示纯文本消息:
这是用于自然语言交互的最常见内容类型。

图像内容

图像内容允许在消息中包含视觉信息:
图像数据**必须(MUST)**是 base64 编码的并包含一个有效的 MIME 类型。这实现了视觉上下文重要的多模态交互。

音频内容

音频内容允许在消息中包含音频信息:
音频数据必须(MUST)是 base64 编码的并包含一个有效的 MIME 类型。这实现了音频上下文重要的多模态交互。

嵌入的资源

嵌入的资源允许在消息中直接引用服务器端资源:
资源可以包含文本或二进制(blob)数据,并**必须(MUST)**包含:
  • 一个有效的资源 URI
  • 适当的 MIME 类型
  • 文本内容或 base64 编码的 blob 数据
嵌入的资源使提示能够将服务器管理的内容(如文档、代码示例或其他参考材料)无缝地直接并入对话流。

错误处理

服务器**应当(SHOULD)**为常见的失败情况返回标准的 JSON-RPC 错误:
  • 无效的提示名:-32602(Invalid params)
  • 缺少必需的参数:-32602(Invalid params)
  • 内部错误:-32603(Internal error)

实现考量

  1. 服务器**应当(SHOULD)**在处理之前校验提示参数
  2. 客户端**应当(SHOULD)**为大型提示列表处理分页
  3. 双方**应当(SHOULD)**尊重能力协商

安全

实现**必须(MUST)**仔细校验所有提示输入和输出,以防止注入攻击或对资源的未授权访问。