8. 技术取舍与优势对比 · 协议指南 · 技术对比
MCP Resource vs Tools
窄屏可在表格区域横向滚动；键盘用户可聚焦表格区域后滚动查看。
理解 MCP 的 Resources 和 Tools，先问两个问题：应用需要给模型补充什么资料？模型需要调用什么能力？
Resources 将信息组织成可读取的上下文；Tools 将操作组织成可调用的函数。两者可以配合使用，也都可能返回数据。仅用“一个读、一个写”来区分，会误判搜索、查询和计算这类只读工具。
本文依据 MCP 2026-07-28 版本撰写，核对日期为 2026 年 10 月 24 日。实际连接以双方协商的协议版本及客户端支持为准。下文业务名称和 URI 均为说明性示例，不代表某个服务已经实现或通过测试。官方规范
一、定义对比：上下文与可调用能力
| 维度 | Resources | Tools |
|---|---|---|
| 核心定义 | 服务器提供的数据或内容，为模型补充上下文 | 服务器暴露的可执行函数，用于检索信息、计算或执行操作 |
| 设计上的控制方 | Application-controlled，由宿主应用组织、选择和纳入上下文 | Model-controlled，模型根据任务提出工具调用 |
| 关注点 | “这里有什么信息可以参考？” | “现在需要调用什么能力？” |
| 常见内容 | 文件内容、数据库结构、产品文档 | 搜索、查询、计算、创建或修改记录 |
这里的“控制方”描述的是交互设计，不是强制的界面或权限规则。应用可以让用户手动选资源，也可以自动加入相关内容；工具调用同样要经过客户端执行和应用的授权机制，不能把“模型控制”理解为“模型可以绕过用户权限”。服务器能力概览、MCP 架构说明
二、场景对比：先判断你在提供什么
下面是接口设计上的取舍建议，不是协议对业务场景的硬性划分。
| 场景 | 更适合 Resources 的部分 | 更适合 Tools 的部分 |
|---|---|---|
| 代码助手 | 项目 README、接口文档、代码文件 | 按条件搜索代码、运行检查、创建修改 |
| 数据分析 | 表结构、字段含义、指标口径 | 按日期和筛选条件查询数据、计算统计结果 |
| 客服助手 | 产品说明、退换货规则、常见问题 | 查询具体订单、创建工单、发起售后流程 |
| 差旅助手 | 差旅制度、目的地介绍 | 按出发地和日期搜索航班、创建行程 |
例如，“差旅制度”适合作为可重复引用的上下文；“查询下周一从上海出发的航班”更像一次带参数的操作。后者即使不修改外部状态，也完全可以是 Tool。官方教学文档的航班搜索示例采用的就是工具接口。理解 MCP 服务器
判断时可以使用一个简单标准：如果重点是访问一个有明确标识的内容对象，优先考虑 Resource；如果重点是表达“执行某种操作及其参数”，优先考虑 Tool。同一数据源可以同时提供两者，无须把整个服务归为其中一类。
三、接口与示例：同一套系统，两种入口
以下用一个虚构的客户支持系统说明接口差异。表中的工具调用是概念写法，不是完整 JSON-RPC 报文。
| 对比项 | Resource 示例 | Tool 示例 |
|---|---|---|
| 标识方式 | support://policies/refund，指向退款规则 |
search_orders，标识订单查询能力 |
| 发现入口 | resources/list；参数化资源通过 resources/templates/list 发现 |
tools/list，返回工具定义及输入 Schema |
| 使用入口 | resources/read，传入目标 URI |
tools/call，传入工具名和参数 |
| 参数化示例 | 模板 support://orders/{order_id}，展开后读取某个订单资源 |
search_orders({status: "pending", limit: 10})，按条件搜索订单 |
| 结果形态 | 文本或二进制资源内容 | 文本、图片等内容，也可以提供结构化结果或资源链接 |
Resource 不等于静态文件。资源可以由 API 或数据库动态生成，URI 模板也能表达参数化的内容访问。服务器是否提供模板，要以实际实现为准，不能看到 Resources 就假定模板可用。Resources 规范
Tool 的结果也不必与 Resource 分离。例如，订单搜索工具可以返回订单资源链接，由应用按需继续读取。规范明确指出，工具返回的资源链接不保证出现在 resources/list 中，不能仅凭资源列表为空，就断言服务没有可读取的资源。Tools 规范
四、三个容易影响选型的误区
1. “Tools 一定会修改数据”
搜索、天气查询和计算都可以是只读 Tool。规范中的 readOnlyHint 用于提示工具是否不修改其环境，但它是服务器提供的行为提示，不是运行时隔离机制，也不是安全认证。尤其不能把不可信服务器的声明当成已经验证的事实。ToolAnnotations 定义
2. “支持 Resources，就支持实时同步”
资源内容更新通知和资源列表变化通知是独立的可选能力。需要先检查服务器声明，再验证客户端是否实际支持。2026-07-28 版本通过 subscriptions/listen 订阅相应资源的更新；不要将旧版订阅流程直接套用到新版实现。收到变更通知也不等于应用已经刷新了模型上下文。资源订阅与能力声明
3. “Resource 是只读的，所以天然安全”
只读访问仍可能涉及敏感内容泄露、越权读取或不可信内容。资源访问需要权限检查；工具执行需要适当的用户控制。MCP 提供接口规范，具体实现仍须落实授权、数据保护和安全边界，协议本身不能代替这些措施。安全与信任原则
五、回到 CapaLens：用实测证据判断能力
区分 Resources 和 Tools，最终是为了更准确地判断：一个 MCP 服务是否真正适合你的应用。
在 CapaLens 的智能接入（Intelligent Access，简称 IA）选型语境里，“支持某个接口”只是起点。值得依赖的实测结论，应能说明测了什么、在什么条件下测、得到了什么结果。下面四类状态尤其需要分开理解，不能互相替代：
| 证据状态 | 可以说明什么 | 不能直接说明什么 |
|---|---|---|
| 已收录 | 条目及来源已被整理 | 已成功连接或调用 |
| 机器检查 | 指定自动检查在记录的环境与时间下得到某个结果 | 已人工核验，或业务任务一定可完成 |
| 人工核验 | 人工检查了明确列出的项目与证据 | 所有功能、权限和场景均已覆盖 |
| 业务实测 | 指定客户端、权限、版本和用例下完成了端到端验证 | 其他环境也必然成功，或服务长期稳定 |
对 Resource，可以检查目标内容能否读取、权限边界是否正确、更新是否能被应用正确使用。对 Tool，可以检查参数与返回值是否符合约定、异常能否处理，以及有副作用的操作是否得到正确约束。这些是验证维度建议，不表示 CapaLens 已经完成全部检查。
因此，阅读 CapaLens 条目时，应把具体测试记录、覆盖范围和限制条件放在能力标签之前。未附实测证据的项目，不能仅凭“已收录”理解为“已验证”；也不应由本文推断 CapaLens 的智能检测引擎已经上线。
Resources 帮助应用提供合适的上下文，Tools 帮助模型请求合适的操作。CapaLens 值得呈现的实测价值，是让每一项“可用”都有清楚、可复核的依据。