MCP 的 Tools、Resources、Prompts 分别是什么？由谁决定使用？

简化版

这是 MCP Server 能对外提供的三类原语，区别在于由谁决定使用。Tools 由模型决定：Server 声明可执行的操作（名称、说明、输入 Schema），客户端用 tools/list 列出、交给模型，模型在对话中判断要不要调用，应用再用 tools/call 执行，适合查询和有副作用的动作。Resources 由应用决定：Server 暴露用 URI 标识的只读数据（文件、数据库记录、接口返回），应用用 resources/list、resources/read 读取，自己决定哪些内容放进上下文或展示给用户。Prompts 由用户决定：Server 提供可复用的提示模板，应用用 prompts/list 展示给用户，用户显式选中后用 prompts/get 拿到填好参数的消息，常见形式是斜杠命令。三类原语体现的是交互控制方式，不是安全等级，任何一类返回的内容都要当作不可信数据处理。

详细版

原语	谁决定使用	主要方法	典型用途
Tools	模型	`tools/list`、`tools/call`	查询数据、执行动作（发消息、写文件）
Resources	应用	`resources/list`、`resources/read`，可订阅变更	把文件、记录等作为上下文提供
Prompts	用户	`prompts/list`、`prompts/get`	可复用的提示模板、斜杠命令

工具定义：  name、description、inputSchema（JSON Schema），可选 outputSchema、annotations
调用结果：  content（文本、图片、资源等内容块），可选 structuredContent，isError 标记执行失败
资源：      uri、name、mimeType；也可以用 URI 模板描述一类资源
提示：      name、description、arguments；get 之后返回一组消息

Server 在初始化时声明自己支持哪些原语（能力协商），客户端只使用双方都声明的能力；列表发生变化时，Server 可以发送 list_changed 通知，让客户端重新拉取。

完整版教学

一、为什么要分成三类

把一个外部系统接到 AI 应用里，要提供的东西不止「可以调用的函数」：

代码仓库接入 AI 应用，可能要提供：
  可以执行的操作：创建分支、提交评论          → 模型判断何时执行
  可以读取的内容：某个文件、某次提交的 diff    → 应用决定放进上下文
  常用的提问方式：「帮我审查这个 PR」          → 用户主动选择

这三样东西的使用时机、控制方和风险都不同。如果全部做成工具交给模型，模型就要自己决定什么时候读文件、什么时候套模板，既浪费调用又不可控。MCP 按「谁来决定使用」把它们分开，让应用可以分别处理。Host、Client、Server 三层角色见「MCP 的架构是什么？它在 AI Agent 系统中解决了什么问题？」。

二、Tools：模型决定调用

Tools 是最常用的原语。Server 声明工具的名称、说明和输入 Schema，客户端拿到列表后转换成模型的工具定义；模型在推理过程中决定调用，应用通过 tools/call 把调用转给 Server：

{"method": "tools/call",
 "params": {"name": "get_weather", "arguments": {"city": "杭州"}}}

返回的结果是一组内容块，可以是文本、图片或资源引用；执行失败时，结果里用 isError: true 标出来，错误信息也放在内容里，这样模型能看到失败原因并决定下一步。这和协议层的错误（比如方法不存在、参数格式不对）是两回事，后者走 JSON-RPC 的错误响应。

工具定义里还可以带一些注解，比如「只读」「有破坏性」「幂等」这类提示。注意它们只是 Server 的自我声明，不能当成可信的安全依据，是否需要用户确认要由应用自己判断。

三、Resources：应用决定读取

Resources 是用 URI 标识的数据，例如 file:///project/README.md、postgres://db/customers/42。应用通过 resources/list 看有哪些资源，通过 resources/read 读取内容，然后自己决定怎么用：放进模型上下文、在界面上给用户选、还是只做展示。

它和 Tools 的关键区别在于控制权：资源读取由应用发起，模型不会自己去读。这适合「应用明确知道需要哪些背景资料」的场景，比如用户在界面上附加了某个文件。对于经常变化的资源，客户端可以订阅，Server 在资源更新时发通知。

记忆钩子：Tools 是模型伸手去拿，Resources 是应用递给模型，Prompts 是用户点名要用。

四、Prompts：用户显式选择

Prompts 是 Server 提供的可复用模板，带参数：

prompts/list →  [{"name": "review_pr", "description": "审查一个 PR", "arguments": [{"name": "pr_id", "required": true}]}]
用户在界面上选「审查 PR」，填入 pr_id = 128
prompts/get  →  返回一组已经填好参数的消息，应用把它们放进对话

它的使用由用户显式触发，常见的呈现方式是输入框里的斜杠命令或菜单。好处是领域专家可以把好用的提问方式沉淀在 Server 里，各个客户端都能直接用。

五、三类原语的对照与选择

你想提供的东西	用哪一类	理由
查询订单、发送邮件、创建工单	Tools	需要模型根据对话判断何时执行，可能有副作用
用户附加的文件、当前打开的文档	Resources	应用已经知道要哪些内容，不需要模型决定
「总结本周工作」「生成测试用例」这类固定问法	Prompts	由用户主动选择，模板由 Server 维护
数据量大、需要按条件检索的数据	Tools（检索工具）	资源读取是按 URI 取，按条件查询更适合做成工具

同一份数据可以同时以两种形式出现：例如数据库记录既可以作为资源让应用直接读，也可以提供一个按条件查询的工具让模型检索。

六、客户端也能提供能力

除了 Server 提供的三类原语，MCP 也允许客户端向 Server 提供能力，常见的有：

客户端能力	作用
Sampling	Server 请求客户端代为调用模型生成内容，Server 不需要自己持有模型密钥
Roots	客户端告诉 Server 可以操作的范围，比如允许访问的目录
Elicitation	Server 在执行过程中请客户端向用户索要补充信息

这些能力同样要在初始化时声明，并且都应该让用户知情和可控，比如 Server 发起的模型调用，客户端应当能让用户审阅和拒绝。

七、常见误区与追问

误区：MCP 就是工具协议。 除了 Tools 还有 Resources 和 Prompts，客户端也能提供 Sampling 等能力。
误区：三类原语代表安全等级，Resources 只读所以安全。 它们区分的是由谁控制使用，任何返回内容都可能包含恶意指令。
误区：工具注解说是只读，就可以不经确认直接执行。 注解是 Server 的自我声明，不能作为可信的安全依据。
误区：工具执行失败就返回协议错误。 执行失败放在结果里用 isError 标出，让模型看到原因；协议错误留给方法不存在、参数格式错误这类情况。
误区：所有数据都做成 Resources 最省事。 需要按条件查询的数据更适合做成检索工具，资源适合按 URI 直接读取的内容。
追问：Server 的工具列表变了，客户端怎么知道？ Server 声明支持列表变更通知后，在变化时发 list_changed 通知，客户端重新拉取列表。
追问：为什么 Prompts 要由用户选择而不是模型？ 模板代表一种完整的任务意图，由用户显式触发才符合预期，也避免模型在对话中擅自套用。

八、加强记忆

MCP 三类原语记「谁决定用」：Tools 由模型决定，tools/list 列出、tools/call 调用，结果是内容块，执行失败用 isError 标出而不是走协议错误，注解只是提示不能当安全依据；Resources 由应用决定，按 URI 用 resources/list、resources/read 读取，可订阅变更，适合应用已经知道要哪些内容；Prompts 由用户决定，prompts/list、prompts/get 拿到填好参数的消息，常见形式是斜杠命令。客户端还能提供 Sampling、Roots、Elicitation。能力要在初始化时声明，列表变化有通知，三类原语是控制方式不是安全等级。

简化版

详细版