MCP 的 Prompts 是什么?一文介绍及使用

深入了解模型上下文协议(MCP)中的 Prompts 核心概念。本文从基础讲起,通过具体示例分步教学如何发现、获取和使用标准化的 Prompt 模板,助你掌握与语言模型交互的新方式。

用 Apifox,节省研发团队的每一分钟

MCP 的 Prompts 是什么?一文介绍及使用

免费使用 Apifox

相关推荐

最新文章

API

一体化协作平台

API 设计

API 文档

API 调试

自动化测试

API Mock

API Hub

立即体验 Apifox
目录

与大语言模型(LLM)交互时,我们通常会输入一段文本,也就是所谓的 "Prompt"。但随着应用变得复杂,如何系统性地管理和复用这些 Prompts,成了一个值得思考的问题。模型上下文协议(Model Context Protocol, MCP)为此提供了一套标准化的解决方案,其核心之一就是 Prompts 机制。

   

MCP Prompts 并非简单的文本字符串,而是一种由服务端定义、供客户端发现和使用的结构化提示词模板。它允许服务端向客户端暴露一系列预设好的、可定制的交互模式,从而规范和简化与语言模型的沟通方式。

 

MCP Prompts 的核心理念

MCP Prompts 的设计核心是“用户控制”(user-controlled)。这意味着这些提示词模板并非在后台静默运行,而是明确地展示给用户,由用户主动选择和触发。

 

这种设计使得用户可以清晰地感知到应用提供了哪些与模型交互的能力。一个常见的界面交互模式是通过斜杠命令(slash commands)来触发,例如,在聊天输入框中输入 /,界面上就会展示出所有可用的 Prompts 列表。

 

当用户输入 /code_review 时,就代表他选择了一个名为 code_reviewPrompt。这种交互方式非常直观,用户可以自然地发现和调用各种预设功能,而无需记忆复杂的指令。当然,MCP 协议本身并不强制规定必须使用斜杠命令,应用开发者可以根据自身产品的需要,设计任何适合的界面模式来暴露这些 Prompts

 

一个 Prompt 模板通常包含名称、标题、描述以及一系列可供用户填充的参数。比如 code_review 这个 Prompt,它可能需要一个名为 code 的参数,让用户把需要评审的代码填进去。这种结构化的定义,使得每一次交互都变得清晰和可预测。

 

如何与 MCP Prompts 交互

客户端与服务端之间围绕 Prompts 的交互遵循一套标准的协议消息流程。这个流程主要分为两个阶段:发现可用的 Prompts,以及获取并使用一个具体的 Prompt

MCP 的 Prompts 是什么?一文介绍及使用

   

第一步:发现可用的 Prompts

客户端需要先知道服务端提供了哪些 Prompts。这个过程通过发送一个 prompts/list 请求来完成。这是一个基于 JSON-RPC 的请求,它会向服务端询问当前所有可用的 Prompt 列表。

 

一个最简单的 prompts/list 请求如下所示:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "prompts/list",
  "params": {}
}

 

服务端收到请求后,会返回一个包含 prompts 数组的响应。这个数组里的每一个对象都描述了一个可用的 Prompt

{
  "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": null
  }
}

 

从响应中可以看到,服务端提供了一个名为 code_reviewPrompt。它有明确的标题、描述,并且需要一个名为 code 的必需参数。客户端的界面可以依据这些信息,向用户展示一个功能清晰的选项。如果 Prompts 数量过多,服务端还可以通过 nextCursor 字段实现分页加载。

 

第二步:获取并使用 Prompt

当用户从列表中选择了 code_review 并提供了需要评审的代码后,客户端就需要根据用户的输入,去获取这个 Prompt 最终生成的内容。这个过程通过发送 prompts/get 请求完成。

 

prompts/list 不同,prompts/get 请求需要指定 Promptname,并提供用户填充的 arguments

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

 

服务端接收到这个请求后,会根据 code_review 模板和用户传入的 code 参数,动态生成最终要发送给语言模型的消息体,并将其返回给客户端。

{
  "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')"
        }
      }
    ]
  }
}

 

客户端拿到的 messages 数组,就是可以直接发送给大语言模型的标准格式内容。这个过程将 Prompt 的模板定义、参数填充和最终内容生成这几个环节清晰地分离开来,使得整个交互流程既灵活又规范。

 

Prompts 的丰富内容格式

MCP Prompts 的强大之处不仅在于其结构化的定义,还在于它支持多种类型的内容格式,使得与模型的交互超越了纯文本的限制,进入了多模态的领域。一个 Prompt 的消息体(PromptMessage)可以包含文本、图像、音频,甚至是服务端管理的资源文件。

 

不同内容类型的特点和用途可以通过下表进行对比:

内容类型 (Content Type) 描述 JSON 示例关键字段
text 普通文本内容,这是最基础和最常见的交互类型,用于传递自然语言指令或信息。 "type": "text", "text": "..."
image 图像内容,允许将图片作为上下文信息发送给模型,用于视觉问答或图像分析等场景。 "type": "image", "data": "base64...", "mimeType": "image/png"
audio 音频内容,支持将音频文件发送给模型,用于语音识别、情感分析等任务。 "type": "audio", "data": "base64...", "mimeType": "audio/wav"
resource 嵌入服务端资源,允许在 Prompt 中直接引用服务端已有的文件,如文档、代码片段等。 "type": "resource", "resource": { "uri": "..." }

 

imageaudio 类型的数据需要进行 Base64 编码,并附上对应的 MIME 类型,这为构建能够理解视觉和听觉信息的多模态应用提供了基础。

 

resource 类型则是一个非常实用的功能,它允许 Prompt 无缝地整合服务端管理的内容。例如,一个用于“根据最新API文档回答问题”的 Prompt,可以通过引用一个资源 URI,将最新的文档内容动态地注入到与模型的对话中,而无需客户端手动上传。

 

动态更新与能力声明

在一个持续演进的应用中,可用的 Prompts 列表可能会发生变化。MCP 为此设计了动态更新机制。

 

在客户端与服务端建立连接的初始化阶段,服务端必须声明它所支持的能力(capabilities)。如果服务端支持 Prompts,并且支持在列表变化时通知客户端,它就需要声明 prompts 能力。

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

 

这里的 "listChanged": true 是一个关键信号,它告诉客户端:当可用的 Prompts 列表发生增减或变更时,我会主动通知你。

 

这个通知通过一个名为 notifications/prompts/list_changed 的消息发送给客户端。客户端收到这个通知后,就明白本地缓存的 Prompts 列表可能已经过时,此时它应该重新调用 prompts/list 请求,去获取最新的列表。

 

这个简单的机制确保了客户端能够及时响应服务端的 Prompts 更新,而无需通过定时轮询等低效方式来保持同步,使得整个系统更加高效和实时。

 

在实际应用中,开发者需要注意对用户传入的参数进行严格校验,以防止注入攻击等安全问题。同时,客户端也应该妥善处理分页逻辑和错误情况,例如当请求的 Prompt 不存在或缺少必要参数时,服务端会返回标准的 JSON-RPC 错误码,客户端需要能够正确解析并给出相应提示。通过遵循 MCP 的这套 Prompts 规范,开发者可以构建出功能强大、体验一致且易于维护的语言模型应用。

     

开发必备:API 全流程管理神器 Apifox

介绍完上文的内容,我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档API 调试API 设计API 测试API Mock自动化测试等功能于一体的 API 管理工具,Apifox 可以说是开发者提升效率的必备工具之一。

 
如果你正在开发项目需要进行接口调试,不妨试试 Apifox。注册过程非常简单,你可以直接在这里注册使用

Apifox



注册成功后可以先看看官方提供的示例项目,这些案例都是经过精心设计的,能帮助你快速了解 Apifox 的主要功能。

 
使用 Apifox 的一大优势是它完全兼容 PostmanSwagger 数据格式,如果你之前使用过这些工具,数据导入会非常方便。而且它的界面设计非常友好,即使是第一次接触的新手也能很快上手,快去试试吧!

Apifox