MCP 的三大原语（Tools / Resources / Prompts）分别干什么？
谁在问：一二面；接过或写过 MCP Server 的面试官用它验证你是读文档还是真实现过
口语化问法
- MCP Server 能暴露哪几类能力？分别什么用？
- Resources 和 Tools 都是给模型提供信息，为什么要分成两个东西？
- 你自己写过 MCP Server 吗？除了 Tools 还实现了什么？
考察意图
这题看着是记忆题，实际有两个坎：
- 能不能说出分类依据。 三个原语的差别不在"提供什么内容"，而在谁来控制触发。答不出这条的人，基本是照着文档目录背的。
- 知不知道 2026 的落地现实。 三大原语里 Tools 一枝独秀，Resources 和 Prompts 在生态里实现率低得多；而 07-28 规范还把客户端侧的 Roots / Sampling / Logging 推进了弃用窗口。只讲"MCP 有三大原语，很完备"的人，没接过真实生态。
顺带，面试官也在观察你会不会把 Resources 用对——它是少数能绕开模型决策直接补上下文的机制，用好了能同时省钱和提准确率。
参考答案
60 分答案（及格线）
三个原语按控制权归属划分：
| 原语 | 谁控制 | 干什么 | 类比 |
|---|---|---|---|
| Tools | 模型控制 | 模型自己决定要不要调、传什么参数，可能有副作用 | 动词：做一件事 |
| Resources | 应用控制 | 用 URI 寻址的只读数据，由客户端应用决定要不要读进上下文 | 名词：一份资料 |
| Prompts | 用户控制 | 预置的提示词模板/工作流，通常由用户显式触发（比如斜杠命令） | 快捷方式：一套流程 |
一句话记忆：Tools 是模型自己伸手去拿，Resources 是应用递给它，Prompts 是用户点了一下。
分开的意义在于安全和成本边界不同：Tools 可能改变世界，所以要权限和确认；Resources 只读，可以放心大胆地注入；Prompts 是人主动发起的，不消耗模型的选择判断。
90 分答案（有生产经验的回答）
补三层。
1. Resources 的真正价值：绕开模型决策。 一份数据如果做成 Tool，模型得先"想到要查"、再选对工具、再填对参数，三个环节都可能失手，而且每一环都要花 token。做成 Resource，客户端可以在建请求之前就把它塞进上下文——比如当前打开的文件、当前工单的详情、用户的偏好配置。这类"反正一定会用到"的信息，走 Resource 比走 Tool 又快又准又便宜。反过来说，要不要用取决于场景的东西不该做成 Resource，否则就是无差别往上下文里灌数据，成本和 context rot 都会上来。这个判断本身就是很好的分水岭。
2. Prompts 的价值是"把专家的用法固化下来"。 同一套工具，老手写的提示词效果远好过新手随口一说。Prompts 让 server 方把推荐用法打包好，用户一键触发。注意它和 Agent Skills 的区别：Prompts 是用户显式触发的模板，Skills 是模型按需自取的手册（四级渐进式披露，约 100 token 广告 → 5000 token 以内的 SKILL.md → references → scripts）。触发方不同，设计动机也不同。
3. 2026 的落地现实要说，这是高区分度点（截至 2026-08）。
- 生态里Tools 的实现率远高于另外两个。多数第三方 server 只做 Tools，客户端对 Resources / Prompts 的支持也参差。所以架构上不能假设"对方一定支持"，要做能力探测和降级。
- 07-28 规范把客户端侧的 Roots / Sampling / Logging 与 HTTP+SSE 传输一并推入 12 个月弃用窗口，Tasks、MCP Apps、企业级授权等挪成扩展。也就是说规范正在收窄核心、把花哨的能力外移，方向是让核心尽量小而稳。
- 协议核心转无状态之后，原本可能用会话承载的东西改由工具返回显式 handle表达。handle 常常就是一个可寻址的引用——这让 Resources 那套"URI 寻址只读内容"的模型和长结果处理自然衔接上了（见 Q3-05）。
4. 一个实现层的经验：写 server 时，先把 Tools 做扎实（描述、参数、错误文案、返回裁剪），Resources 只在"客户端一定会用到且能提前确定"时提供，Prompts 视客户端支持度再说。一上来就把三样都实现一遍，投入产出很差。
追问链
一份产品文档，你会做成 Tool 还是 Resource？依据是什么？
期望看两点：必用性 + 能否提前确定。必然要用（用户正在该文档页提问）→ 做 Resource 由应用注入，省掉模型判断与一次往返；用不用取决于问什么（上万份得先搜）→ 只能是 Tool。误用两例：知识库全量注入推高 context rot；每次必用的工单做成 Tool 白多一轮往返信号用「必用性 + 可提前确定性」判断、各举一个反向误用例子 → 真设计过；答「都能实现，看喜好」→ 没想过成本差异控制权这个区分，在工程上有什么实际后果？
期望安全：Tools 有副作用要校验与分级确认，Resources 只读但 URI 外部可控，要防穿越；成本：Tools 描述每轮重发，Resources 读时才进上下文；可预测性：Prompts 人触发可审计，Tools 时机不定得按分布看。错配：给只读资源做确认、给写工具不设权限信号能把控制权映射到安全/成本/可预测性三条后果 → 自己推过；只重复「一个模型控制、一个应用控制」→ 停在文档表层接的第三方 server 只实现了 Tools，你的设计怎么改？
期望先做能力探测（看对方声明什么），再降级：缺 Resources 就拿只读 Tool 顶上，认下多一轮往返；或让 adapter 层预取数据注入，自己补上「应用控制」。截至 2026-08 只做 Tools 的 server 是多数——「对方支持什么」是运行时变量，不是编译期常量信号提能力探测 + adapter 层自己补齐 → 接过多个 server；答「那就等对方支持」→ 没有工程弹性Roots / Sampling / Logging 进弃用窗口，你怎么理解？
期望这三项都是反向能力（server 反过来要客户端替它调模型、读本地目录、打日志），实现复杂、安全边界难划。方向是核心收窄、扩展外移：核心只留稳定必要的（配合无状态化），Tasks、MCP Apps 挪去扩展里迭代。存量要在 12 个月窗口内排迁移，新建别把架构压在弃用中的能力上信号指出这几项都是「server → client 的反向能力」并总结出核心收窄 → 读过变更说明；只背弃用清单 → 是记忆不是理解你写的 MCP Server 要给公司外部团队用，只做 Tools 够吗？三个原语怎么排优先级？
期望Tools 做扎实 → Resources 视场景补 → Prompts 最后：只有 Tools 全客户端支持，另两个投了可能没人用。「扎实」= 参数 enum 与格式说明、可操作错误文案、长结果给 handle、稳定命名空间——对外的 server，描述质量决定别人家 Agent 的成功率，你却收不到 badcase。额外：版本兼容与变更日志、限流配额信号优先级建立在「客户端支持度 + 投入产出」上、主动想到对外版本兼容与限流 → 做过对外接口；答「三个都实现才完整」→ 没吃过下游被打崩的亏
评分要点
- 说出三大原语并给出正确的分类依据（控制权：模型 / 应用 / 用户）
- Tools 可能有副作用、需要权限与确认
- Resources 是 URI 寻址的只读数据，由应用决定注入
- Prompts 是用户显式触发的模板/工作流
- 能说清 Resources 的价值是绕开模型决策，省一轮往返也省判断失误
- 知道全量注入 Resources 会推高成本与 context rot
- 加分：知道生态中 Tools 实现率远高于另两者，设计上要能力探测 + 降级
- 加分：知道 07-28 规范把 Roots/Sampling/Logging 与 HTTP+SSE 推入弃用窗口、Tasks/MCP Apps 改扩展（截至 2026-08）
- 加分：能把 handle 范式与 Resources 的可寻址只读模型联系起来