Skip to main content
协议修订版: 草案
模型上下文协议(MCP)提供了一种标准化方式,使服务器可以向客户端公开提示模板。提示允许服务器提供用于与语言模型交互的结构化消息和指令。客户端可以发现可用的提示、检索其内容,并提供参数以进行自定义。

用户交互模型

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

功能能力

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

协议消息

列出提示

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

获取提示

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

列表变化通知

当可用提示列表发生变化时,声明了 listChanged 功能的服务器应该发送通知:

消息流

数据类型

提示(Prompt)

一个提示定义包括:
  • name: 提示的唯一标识符
  • title: 可选的人类可读名称,用于显示
  • description: 可选的人类可读描述
  • arguments: 可选的参数列表,用于自定义

提示消息(PromptMessage)

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

文本内容

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

图像内容

图像内容允许在消息中包含视觉信息:
图像数据必须采用base64编码,并包含有效的MIME类型。这使得在需要视觉上下文的多模态交互中成为可能。

音频内容

音频内容允许在消息中包含音频信息:
音频数据必须采用base64编码,并包含有效的MIME类型。这使得在需要音频上下文的多模态交互中成为可能。

嵌入资源

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

错误处理

服务器应该对常见失败情况返回标准的JSON-RPC错误:
  • 无效的提示名称:-32602(参数无效)
  • 缺少必需的参数:-32602(参数无效)
  • 内部错误:-32603(内部错误)

实现注意事项

  1. 服务器应该在处理前验证提示参数
  2. 客户端应该处理大型提示列表的分页
  3. 双方应该尊重功能协商

安全性

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