提示
协议版本: 2025-11-25
模型上下文协议（MCP）为服务器向客户端公开提示模板提供了标准化方式。提示允许服务器为与语言模型的交互提供结构化消息和指令。客户端可以发现可用的提示、检索其内容，并提供参数来自定义它们。
1 用户交互模型
提示被设计为用户控制的，这意味着它们从服务器公开到客户端，目的是让用户能够明确选择使用它们。
通常，提示会通过用户界面中用户发起的命令触发，这允许用户自然地发现和调用可用的提示。
例如，作为斜杠命令：
然而，实现者可以通过任何适合其需求的界面模式公开提示——协议本身不强制要求任何特定的用户交互模型。
2 能力
支持提示的服务器必须在初始化期间声明 prompts 能力：
{
"capabilities": {
"prompts": {
"listChanged": true
}
}
}listChanged 表示服务器是否会在可用提示列表更改时发出通知。
3 协议消息
3.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
}
],
"icons": [
{
"src": "https://example.com/review-icon.svg",
"mimeType": "image/svg+xml",
"sizes": ["any"]
}
]
}
],
"nextCursor": "next-page-cursor"
}
}3.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')"
}
}
]
}
}3.3 列表变更通知
当可用提示列表更改时，声明了 listChanged 能力的服务器应该发送通知：
{
"jsonrpc": "2.0",
"method": "notifications/prompts/list_changed"
}4 消息流程
5 数据类型
5.1 Prompt
提示定义包括：
name：提示的唯一标识符title：可选的用于显示目的的人类可读提示名称description：可选的人类可读描述arguments：可选的用于自定义的参数列表
5.2 PromptMessage
提示中的消息可以包含：
role："user"或"assistant"以指示说话者content：以下内容类型之一：
提示消息中的所有内容类型都支持可选注解，用于关于受众、优先级和修改时间的元数据。
5.2.1 文本内容
文本内容表示纯文本消息：
{
"type": "text",
"text": "The text content of the message"
}这是用于自然语言交互的最常见内容类型。
5.2.2 图像内容
图像内容允许在消息中包含视觉信息：
{
"type": "image",
"data": "base64-encoded-image-data",
"mimeType": "image/png"
}图像数据必须是 base64 编码的，并包含有效的 MIME 类型。这支持视觉上下文重要的多模态交互。
5.2.3 音频内容
音频内容允许在消息中包含音频信息：
{
"type": "audio",
"data": "base64-encoded-audio-data",
"mimeType": "audio/wav"
}音频数据必须是 base64 编码的，并包含有效的 MIME 类型。这支持音频上下文重要的多模态交互。
5.2.4 嵌入式资源
嵌入式资源允许在消息中直接引用服务器端资源：
{
"type": "resource",
"resource": {
"uri": "resource://example",
"mimeType": "text/plain",
"text": "Resource content"
}
}资源可以包含文本或二进制（blob）数据，必须包括：
- 有效的资源 URI
- 适当的 MIME 类型
- 文本内容或 base64 编码的 blob 数据
嵌入式资源使提示能够无缝地将服务器管理的内容（如文档、代码示例或其他参考资料）直接整合到对话流程中。
6 错误处理
服务器应该为常见故障情况返回标准 JSON-RPC 错误：
- 无效的提示名称：
-32602（无效参数） - 缺少必需参数：
-32602（无效参数） - 内部错误：
-32603（内部错误）
7 实现注意事项
- 服务器应该在处理前验证提示参数
- 客户端应该为大型提示列表处理分页
- 双方应该尊重能力协商
8 安全
实现必须仔细验证所有提示输入和输出，以防止注入攻击或未经授权访问资源。