MCP 资源与工具：有什么区别，何时使用哪一种？

模型上下文协议（MCP）为 AI 应用程序提供了一种将模型与外部上下文和能力连接起来的标准方式。对于构建 MCP 服务器的开发人员来说，最重要的设计决策往往看似简单：一项能力应作为资源还是工具公开？

这种区别决定了智能体如何发现信息、何时消耗令牌、能够改变什么，以及用户如何评估风险。建模不当的能力会使集成更难理解：静态参考数据变成了不必要的函数调用，或者影响重大的操作看起来像是无害的上下文。

从实际角度来看，MCP 资源提供应用程序可供 AI 系统使用的只读信息。MCP 工具公开模型可以请求执行的操作。理解两者之间的边界，是开发可靠、安全且令牌高效的 MCP 服务器的基础。

为什么 MCP 中资源与工具的区别很重要

AI 智能体既需要信息，也需要采取行动的能力。不过，信息检索和操作执行具有不同的信任模型。

模型可能需要数据库架构来了解可以执行哪些查询。随后，它可能需要另一项能力来运行已批准的查询。将两者视为同一种集成会掩盖意图、增加权限管理的复杂性，并可能导致过度使用上下文。

资源与工具的区别之所以重要，是因为它明确了：

• 智能体行为： 模型可以在请求操作之外，单独检查稳定的上下文。
• 安全边界： 读取权限和写入权限可以采用不同的方式进行审查、限定范围和治理。
• 用户信任： 用户可以区分智能体是在了解某个系统，还是在改变该系统。
• 令牌效率： 可以在需要时获取相关上下文，而不是不加区分地将其插入每个提示中。
• 服务器设计： 能力会变得更容易命名、记录、测试和维护。

MCP 并不意味着每个可用资源都会自动放入模型上下文。资源通过 MCP 能力模型提供，而宿主应用程序决定如何以及何时将其呈现或读取。当可用信息范围广泛、敏感或加载成本高时，这种由宿主控制的方法至关重要。

什么是 MCP 资源？

MCP 资源是由 MCP 服务器公开的、基于 URI 的只读上下文内容。它们旨在提供 AI 系统在完成任务时可能需要检查、总结、推理或引用的信息。

资源并不只是任意文件或通用 API 端点。在模型上下文协议中，它是一个可发现的上下文数据单元，通常由 URI 标识。服务器可以公开表示文档、配置、架构、项目元数据、知识库页面或生成的状态信息的资源。

常见示例包括代码仓库架构指南、`README` 文件、OpenAPI 架构、数据库表定义或部署环境的当前配置。这些内容之所以有用，是因为它们帮助智能体在提出或执行工作之前了解系统的状态和规则。

在协议层面，服务器可以通过 `resources/list` 公告可用上下文。客户端随后可以通过 `resources/read` 检索特定项。这种分离使宿主和智能体能够在加载内容本身之前检查有哪些内容可用。

当答案应从现有的稳定信息中得出时，资源尤其有用。例如，审查陌生服务的智能体可以在建议集成之前，读取包含该服务 API 契约的资源。资源提供证据和上下文；它不会执行更改。

什么是 MCP 工具？

MCP 工具是模型可以通过 MCP 服务器发现和调用的可执行能力。它们表示操作：智能体可以请求已连接系统执行的任务。

工具可以发出 API 请求、创建问题、运行部署检查、生成报告、发送消息或写入数据库。许多工具可能具有副作用，但副作用并非必要条件。例如，只读数据库查询仍然可以正确建模为工具，只要它是一项具有输入、执行逻辑和结构化结果的操作。

服务器通过 `tools/list` 公开工具定义。每个定义都应清晰传达名称、描述和输入架构。模型通过 `tools/call` 调用选定的能力，并提供与工具预期输入相匹配的参数。

关键设计原则是：工具要求服务器完成工作。其输出可能是数据，但该数据是执行的结果，而不是可直接寻址的上下文工件。

例如，`create_linear_ticket` 是一个工具，因为它会使外部工作流创建新工单。当服务器必须使用提供的环境和服务参数查询实时系统时，`get_deployment_status` 也可以是工具。两项操作都需要显式调用，尽管其中只有一项必然会改变状态。

MCP 资源与工具：主要区别

该表总结了一个实用边界：资源描述或公开信息，而工具执行行为。在设计良好的 MCP 服务器中，即使两种能力支持同一个更广泛的工作流，这种区别依然清晰可见。

如何在资源与工具之间进行选择

先从一个问题开始：智能体是需要查看信息，还是需要服务器执行操作？

当信息是只读的、可自然寻址且可作为上下文使用时，请使用资源。配置文件、产品规格说明、策略文档或数据库架构通常都适合这种模型。客户端可以发现该项目，判断其是否相关，并在不触发业务逻辑的情况下读取它。

当任务需要输入、执行过程，或需要无法表示为静态上下文的结果时，请使用工具。创建支持工单、获取经过筛选的报告、启动构建或更新记录等操作都应通过工具完成。

有些工作流需要同时使用这两种原语。以发布管理集成为例：

1. 将发布策略和环境定义作为资源公开。2. 提供一个工具，用于获取所选服务的实时部署状态。3. 提供另一个工具，用于触发已获批准的部署。

这种设计使智能体能够先了解策略和环境约束，然后请求当前运营数据，最后才请求执行具有重要影响的操作。这种分离方式更便于用户审计，也更便于产品团队保障安全。

不要把每个查询都变成资源。如果信息是动态的、参数化的或计算成本高昂，工具通常更合适。反之，当基于 URI 的资源能更清晰地说明其用途时，也不要将简单、稳定的参考内容封装在工具中。

实用的 MCP 服务器设计示例

代码仓库文档服务器可以将编码标准、架构决策记录和服务归属映射作为资源公开。这些项目是具有可预测地址的有用参考材料。如果 `search_repository_docs` 功能接受关键词并在大型文档库中执行定向搜索，它就可以作为工具。

对于数据库集成，表架构和经批准的数据字典非常适合作为资源。`run_readonly_query` 功能更适合建模为工具，因为它接受查询或结构化筛选条件，对其进行验证，在实时系统中执行，并返回结果。独立的写入工具绝不应隐藏在同一个含义模糊的接口之后。

项目管理集成遵循相同模式。资源可以提供冲刺看板的工作流定义或问题标签分类。工具可以创建工单、更新其状态或分配负责人。这些信息可帮助智能体提出明智的请求；工具则执行所请求的更改。

报告生成是另一个有用的边界案例。固定的季度报告模板可以作为资源。`generate_quarterly_report` 操作属于工具，因为它接受时间范围、选择实时数据、应用业务逻辑并创建输出。如果生成的报告后来成为其他智能体应查看的稳定工件，则可将其作为资源公开。

使用 Pi MCP 处理从技术到演示的工作流

Presentation Intelligence (Pi) 支持 MCP 工作流，面向需要将技术工作转化为清晰利益相关者沟通内容的团队。Pi MCP 并非代码编辑器、源代码控制、数据库或其他 MCP 服务器的替代品。它解决交付流程中的一个独特环节：将经批准的技术上下文转化为结构化、适合业务使用的演示文稿。

1. 业务逻辑先于幻灯片样式

在 Claude Code 等 AI 编程或智能体环境中，团队通常已经拥有制作优秀演示文稿所需的原始材料：技术简报、项目笔记、架构说明、发布摘要和从代码库中得出的发现。挑战在于将这些材料转化为适合受众的叙事，而不是一组彼此脱节的幻灯片。

借助 Pi MCP，智能体工作流可以将明确的简报或经批准的上下文传递给 Presentation Intelligence，以创建以逻辑为先的演示文稿结构。这对于工程路线图更新、高管项目评审、技术销售演示文稿、咨询报告和产品发布叙事非常有用，因为这些场景中故事线必须与底层实现一样可信。

2. 在现有工作流中保持生成过程可见

否则，创建演示文稿可能要求开发人员和产品团队离开工作环境，手动重新整理技术笔记，并反复检查独立的制作流程。Pi MCP 使团队能够在现有智能体工作流内启动演示文稿工作并跟踪生成进度。

当演示文稿依赖不断演变的项目上下文时，这种连续性尤为重要。团队可以优化简报、明确受众需求，并监控演示文稿工作流，而无需将沟通视为事后考虑。Pi 的多智能体 AI 方法支持从复杂输入过渡到专业结构和高端商业演示输出，同时团队仍可控制共享哪些上下文。

安全且令牌高效的 MCP 集成最佳实践

良好的 MCP 服务器开发始于范围明确、易于理解的能力。将资源限定为智能体真正需要的信息。庞大而未分类的知识倾倒会消耗令牌，却未必能改善决策。应优先使用具有明确 URI、清晰描述和可预测边界的较小资源。

对于工具，请使用精确的名称和明确的输入架构。`create_customer_ticket` 比 `manage_ticket` 传达的信息更多，而将标题、优先级和客户 ID 区分开的架构可减少歧义。返回结构化、可操作的结果，以便智能体无需反复调用同一工具即可确定发生了什么。

尽可能分离读取和写入操作。既检查又更改系统的工具会使权限审查更加困难。当某项操作具有重要影响时——例如删除记录、发送外部消息或触发生产部署——应应用最小权限访问，并在宿主体验中要求适当的用户确认。

最后，要为渐进式披露而设计。让智能体先发现能力，只获取相关资源，并且仅在需要操作时调用工具。这种方法可减少令牌浪费、限制敏感数据暴露，并使智能体的推理路径更易理解。

实用结论：将模型上下文作为资源，将操作作为工具

MCP 设计最可靠的规则很简单：将持久、只读的上下文作为资源公开，将可执行、参数化的工作作为工具公开。这一边界可改善安全审查，使智能体行为保持可解释性，并帮助团队管理上下文预算而不牺牲有用的访问能力。

对于复杂工作流，最强的设计通常会结合两者。资源提供智能体所需的事实和约束；工具提供经过谨慎治理的操作方式。Pi MCP 将同样的模式应用于技术沟通，帮助团队将经批准的项目上下文转化为结构化演示文稿，同时仍处于工作本已进行的 AI 环境中。