多数人把 MCP 只用成”给模型加工具”，但协议里另外两块能力被严重低估：Resources 负责被动提供上下文，Prompts 负责把常用操作固化成用户可主动触发的模板。三者分工是：工具由模型控制，资源由应用控制，提示由用户控制。
三种原语的分工
| 原语 | 控制方 | 作用 | 典型例子 |
|---|---|---|---|
| Tools（工具） | 模型 | 执行动作、写数据、调外部 API | 搜索航班、发消息、建日程 |
| Resources（资源） | 应用 | 只读提供上下文数据 | 文档、数据库 schema 、日历 |
| Prompts（提示） | 用户 | 预置指令模板，带参数 | 代码审查、周报生成 |
判断该用哪种原语的标准：要产生副作用就用工具；只是给模型看的数据就用资源；需要用户主动点一下才触发的固定流程就用提示。把”生成周报”做成工具，模型会在不该发的时候自己调用它。
Resources：两种发现模式
直接资源
固定 URI 指向确定的数据，例如 calendar://events/2024。客户端通过 resources/list 枚举，用 resources/read 读取内容，还可用 resources/subscribe 订阅变更。
资源模板
带参数的动态 URI，例如 travel://activities/{city}/{category}，实际展开成 travel://activities/barcelona/museums。模板自带标题、描述与 MIME 类型，便于被检索与自解释。
Prompts：把重复流程固化
服务端在初始化时声明 prompts 能力（可带 listChanged），客户端用 prompts/list 拿到模板清单与参数定义，用 prompts/get 取回渲染后的消息。典型定义包含 name 、 title 、 description 与 arguments，参数可标记 required，并支持通过补全接口辅助填写。
一个代码审查提示的定义要点
name 用程序化标识如
code_review，title 面向人展示，arguments 至少包含一个 required 的 code 参数并在 description 里写清期望内容。返回的 messages 里 role 可用 user 或 assistant，content 除文本外还支持图片、音频与嵌入式资源。组合用法
- 用户选中一个 Prompt 触发固定流程；
- 流程中通过 Resources 拉取所需上下文（如文档、 schema）；
- 模型在流程里按需调用 Tools 完成动作。
协议的传输层与基础概念见 MCP 入门教程与MCP 传输方式 stdio 与 HTTP 对比；服务端搭建步骤见 MCP Server 搭建。
Resources 和直接让工具返回数据有什么区别？
资源是只读、可被应用侧管理和订阅的上下文，客户端可以决定如何裁剪与注入；工具是模型主动调用的动作，会带副作用。混用会让权限边界模糊。
Prompts 必须由用户触发吗？
协议设计意图是用户控制，常见形态是斜杠命令；但实现者可自由选择交互方式，协议不强制。
资源模板适合什么场景？
适合按参数查询的动态数据：按城市查天气、按项目查文档、按用户查订单。固定 URI 无法覆盖的组合用模板更合适。
提示消息里能带图片吗？
可以。 content 支持 text 、 image 、 audio 与嵌入式 resource，图片需 base64 编码并给出正确 MIME 类型。
评论 (0)