MCP 的 Tools、Resources、Prompts 有什么区别？分别在什么场景使用？

知识点详解：把三类能力放进同一个助手

先看一次“检查报销规则”的任务

假设咱们在做一个企业知识库助手，员工想知道一份差旅报销申请是否符合规定。

开发者可以提供三项能力：

能力	一个具体例子	应用需要做什么
Resource	当前差旅制度的内容地址	读取内容，决定是否用于本轮任务
Prompt	“检查报销申请”的任务模板	传入申请信息，取得组织好的消息
Tool	根据申请编号查询明细	发起调用，得到实际查询结果

这三个例子并不是必须照着实现。它们的作用是让你看清：有时应用需要一份材料，有时用户需要一个任务入口，有时系统需要执行一次操作。

如果所有能力都做成工具，也可能完成任务。但应用就要通过工具调用承担内容选择、任务入口等职责。是否值得这样做，要看客户端能力和产品的交互方式。

Resources 的重点，是让内容可以被识别和读取

Resource 通常有一个 URI，也就是标识内容的地址。应用发现这个地址后，可以发起读取请求，再拿到文本或其他内容。

因此，Resource 不是“模型已经知道的知识”。

假设客户端列出了十份制度，模型本轮只收到了用户的问题。制度虽然能被发现，却没有被读出来、更没有放进模型输入，模型仍然不能据此回答。

读取以后也不一定要全部交给模型。应用可以只取当前任务需要的部分，检查用户权限，再组织进上下文。

还有一个容易答错的地方：Resource 不一定是静态文件。一个地址可以代表不断更新的监控摘要，每次读取的结果不同。内容会不会变化，不能作为 Tool 和 Resource 的唯一分界。

Tools 的重点，是带参数执行一次动作

查询报销明细时，系统需要提交申请编号。工具收到参数，再去相应系统查询，最后返回结果。

在支持工具调用的应用里，模型可以根据工具说明提出调用请求。不过，模型提出请求之后，真正的权限检查和执行仍由应用与服务端完成。

工具也不一定有写入副作用。搜索、计算、查询都可以是工具。因此，不能把 Tools 简化为“修改数据”，把 Resources 简化为“只读数据”。

更有用的判断是：你准备暴露一个可供读取的内容对象，还是一项需要传入参数并执行的能力？

Prompts 提供任务入口，不直接完成任务

假设用户选择“检查报销申请”，应用向 MCP Server 请求这个 Prompt，并传入相关参数。Server 返回的可以是一组组织好的消息，帮助应用把任务说清楚。

后面的推理和工具执行，还没有因此完成。

如果模板建议“发现异常就发送通知”，应用也不能因为用户选了模板，就默认用户授权向所有人发送消息。提示词表达任务，执行授权约束动作，两者需要分别判断。

MCP 的服务端规范把三类能力分别概括为模型、应用和用户控制的交互方式。这有助于理解产品职责，但它不是靠提示词就能落实的权限系统。具体客户端仍然可以设计不同的选择和呈现流程。

接入以后，怎样确认它真的起作用了？

先把三种动作分别记录下来：发现了什么、读取或取得了什么、实际调用了什么。

如果助手没有使用制度，检查 Resource 内容有没有进入模型请求。如果任务描述不对，检查 Prompt 参数和返回消息。如果查询越权，检查 Tool 的身份与参数校验。

只看到 MCP 连接成功，无法确认这些环节已经正常工作。

面试官继续追问

同一份文档既作为 Resource，又由 Tool 搜索出来，算重复设计吗？

不一定。直接读取已知文档和按条件搜索未知文档，解决的是不同需求。但如果客户端只需要一种访问方式，就不必为了凑齐三类能力增加重复接口。

Prompt 可以包含 Resource 吗？

可以组织引用或内容，但应用仍要理解相应消息和资源表示，按权限与输入预算处理。不要把“模板里有引用”理解为模型自动读取了所有外部内容。

为什么接入后，客户端只展示 Tools？

先确认客户端支持哪些能力、有没有完成能力协商与对应交互。Server 提供了三类能力，不代表每个客户端都会把三类都做成可见入口。

面试速记卡

• Tools：带参数执行能力，可以查询，也可以产生副作用。
• Resources：暴露可识别、可读取的内容，不限于静态文件。
• Prompts：提供可选择、可参数化的任务提示入口。
• 配合方式：准备材料、组织任务、执行动作可以分开承担。
• 工程边界：发现不等于使用，选提示词不等于批准所有操作。