1.提示词功能 #

协议修订: 2025-06-18
来源: Anthropic MCP 规范

2.📖 概述 #

Model Context Protocol (MCP) 为服务器提供了一种标准化方式，使其能够向客户端公开提示模板。提示功能让服务器能够提供结构化消息和与语言模型交互的指令。客户端可以发现可用提示、获取其内容，并通过提供参数来自定义这些提示。

3.🎯 用户交互模型 #

提示词的设计旨在用户可控，这意味着它们从服务器暴露给客户端，目的是让用户能够明确选择使用它们。

通常，提示会通过用户界面中用户发起的命令触发，这使用户能够自然地发现并调用可用的提示。

3.1 典型使用场景 #

例如，作为斜杠命令：

/代码审查

然而，实现者可以自由地通过任何适合其需求的接口模式来公开提示——协议本身并不强制要求任何特定的用户交互模型。

4.🔧 能力声明 #

支持提示(prompts)的服务器必须声明prompts能力期间初始化:

{
  "capabilities": {
    "prompts": {
      "listChanged": true
    }
  }
}

listChanged表示当可用提示列表发生变化时，服务器是否会发出通知。

5. 协议消息 #

5.1 列出提示 #

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

请求:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "prompts/list",
  "params": {
    "cursor": "optional-cursor-value"
  }
}

响应:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "prompts": [
      {
        "name": "code_review",
        "title": "Request Code Review",
        "description": "Asks the LLM to analyze code quality and suggest improvements",
        "arguments": [
          {
            "name": "code",
            "description": "The code to review",
            "required": true
          }
        ]
      }
    ],
    "nextCursor": "next-page-cursor"
  }
}

5.2 获取提示 #

要检索特定的提示，客户端会发送一个prompts/get请求。参数可能会自动补全补全API。

请求:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "prompts/get",
  "params": {
    "name": "code_review",
    "arguments": {
      "code": "def hello():\n    print('world')"
    }
  }
}

响应:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "description": "Code review prompt",
    "messages": [
      {
        "role": "user",
        "content": {
          "type": "text",
          "text": "Please review this Python code:\ndef hello():\n    print('world')"
        }
      }
    ]
  }
}

5.3 变更列表通知 #

当可用提示列表发生变化时，已声明该列表的服务器listChanged能力应该发送通知：

{
  "jsonrpc": "2.0",
  "method": "notifications/prompts/list_changed"
}

6.🔄 消息流 #

7.📊 数据类型 #

7.1 提示 #

一个提示定义包含：

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

7.2 提示信息 #

提示中的消息可以包含：

• role: "user"或"assistant"，用于标识发言者身份
• content: 以下内容类型之一：

注意: 提示消息中的所有内容类型均支持可选功能注释用于存储关于受众、优先级和修改时间的元数据。

7.2.1 文本内容 #

文本内容代表纯文本消息。

{
  "type": "text",
  "text": "The text content of the message"
}

这是用于自然语言交互最常见的内容类型。

7.2.2 图像内容 #

图片内容允许在消息中包含视觉信息。

{
  "type": "image",
  "data": "base64-encoded-image-data",
  "mimeType": "image/png"
}

图像数据必须需进行base64编码并包含有效的MIME类型。这使得在视觉上下文至关重要的场景中能够实现多模态交互。

7.2.3 音频内容 #

音频内容允许在消息中包含音频信息。

{
  "type": "audio",
  "data": "base64-encoded-audio-data",
  "mimeType": "audio/wav"
}

音频数据必须经过base64编码并包含有效的MIME类型。这能实现需要音频上下文的多模态交互场景。

7.2.4 嵌入式资源 #

嵌入式资源允许直接在消息中引用服务器端资源。

{
  "type": "resource",
  "resource": {
    "uri": "resource://example",
    "name": "example",
    "title": "My Example Resource",
    "mimeType": "text/plain",
    "text": "Resource content"
  }
}

资源可以包含文本或二进制（blob）数据，并且必须包含:

• 有效的资源URI
• 适当的MIME类型
• 文本内容或base64编码的二进制数据

嵌入式资源使提示能够无缝整合服务器管理的内容，如文档、代码示例或其他参考资料，直接融入对话流程中。

8.⚠️ 错误处理 #

服务器应该返回标准JSON-RPC错误以处理常见故障情况：

• 无效的提示名称：-32602(参数无效)
• 缺少必要参数：-32602(参数无效)
• 内部错误：-32603（内部错误）

9. 实施注意事项 #

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

10.🔒 安全 #

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