在 MCP（Model Context Protocol）里，Tools和Resources分别代表可执行能力与可读上下文两种截然不同的接口：前者让 LLM 在用户批准后调用函数、产生副作用；后者则把结构化或原始数据安全地暴露给模型阅读、但本身不执行任何动作。理解这条分界线并按照"谁来控制、是否有副作用、该走哪条端点"来设计接口，是把 MCP 用出生产价值的关键。
一、本质区别
| 维度 | Tools | Resources |
|---|---|---|
| 控制权 | 模型可控（model-controlled）——LLM 可在推理中决定何时调用 | 应用可控（application-controlled）——由客户端或用户挑选给模型 |
| 作用 | 执行操作、产生（或可能产生）副作用 | 提供只读数据作为上下文 |
| 调用流 | 通过 tools/list 发现 → tools/call 执行 | 通过 resources/list 发现 → resources/read 获取内容 |
| 规范承诺 | 需附 JSON Schema 参数、可用 readOnly / destructive / idempotent 等注解标记副作用 | 需标 URI、MIME 类型，可选 URI 模板、增量订阅 |
| 典型场景 | 创建 Jira 工单、发送邮件、对数据库写入 | 代码库文件、API GET 结果、日志、截图、向量检索结果 |
副作用 vs. 只读
- Tools 被视为"任意代码执行"，可能改写外部系统，必须经过显式用户同意
- Resources 原则上无副作用，只读取数据；若要让模型自动使用，需要先升级为 Tool 或让客户端自动选择资源
发现与调用端点
- 工具通过 tools/list 公布，再用 tools/call 执行并返回结果
- 资源通过 resources/list 或 URI 模板公开，用 resources/read 拉取内容，支持实时订阅变更
设计哲学
- 最小授权原则：Tools 暴露的功能越精细、越易审核；大颗粒"万能工具"容易失控
- 数据就绪原则：Resources 应按模型可消化的粒度切块，并随资源变动实时推送或缓存
二、应用开发者落地指南
什么时候用 Tool？
需要行动或计算
需跨系统交互
需要模型自主决策
当需要让 LLM 执行操作、产生副作用，或者需要模型自主决策何时调用某个功能时，应该使用 Tool。
最佳实践
- 函数化 + JSON Schema：为每个 Tool 写清楚 name、description、inputSchema，并在注解里标明 readOnlyHint / destructiveHint / idempotentHint 等，以便客户端 UI 做风险分级
- 原子化组合：把复杂事务拆成小 Tool（查库存→下单→发通知），方便 LLM 链式调用并回滚
- 加入进度回报与错误包装：长任务应 streaming 回报进度；所有异常用 isError 字段返回，避免协议级崩溃
- 权限网关：在 Tool 层做鉴权、速率限制、审计日志，对高危操作再叠加多因子确认
什么时候用 Resource？
纯数据上下文
大体量或频繁变更
用户选择的材料
当需要提供只读数据作为上下文，或者需要让用户选择提供给模型的材料时，应该使用 Resource。
最佳实践
- URI 命名规范：file:// 本地、postgres:// 数据库、screen:// 截图……便于过滤、缓存和权限校验
- 分片与语义标签：对长文档做分段、给每段加 description，提高检索与向量匹配精度
- 动态模板：用 RFC 6570 URI 模板暴露可参数化资源（如 s3://bucket/{user}/{date}.csv），客户端按需填充
- 冷热分层缓存：静态资源走 CDN，本地文件走索引快取；notifications/resources/list_changed 事件触发失效重载
工具＋资源组合范式
先读后写
模型读取资源（用户配置）→ 分析 → 决定是否调用 Tool 更新系统
搜索Tool + 精读Resource
用 web_search Tool 找候选文章，再把命中的 URL 作为 Resource 供 LLM 摘要
Agent Graph 协同
在未来多智能体拓扑下，Resource 节点可被不同 Agent 共享，Tool 节点只暴露给有权限的 Agent 域
代码/框架起步
- 官方 Python/TS SDK（FastMCP、model-context-protocol） 提供 server 与 client 模板，数行代码可注册 Tool 或 Resource
- LangGraph / Google ADK 已内置 MCP 客户端，可直接把现有代理流程接入 Tools 与 Resources 生态
- 第三方示例服务器：在 GitHub 搜 "awesome-mcp-servers" 观摩行业最佳实践
三、常见误区与安全提示
| 误区 | 风险 | 建议 |
|---|---|---|
| 把全部 REST 端点都做成 Tool | 调用过载、UI 审批噪声 | 把纯 GET 查询改成 Resource；仅对写操作做 Tool |
| 在 Tool 里返回 100 MB 文本 | 模型上下文炸毁、成本飙升 | Tool 结果倾向返回简洁 ID or URI，再让模型通过 Resource 拉大文件 |
| 资源未做权限切分 | 泄露敏感数据 | Resource 列表按用户会话实时过滤，必要时加脱敏层 |
| 忽视客户端 UI 批准 | 用户不知情即写入生产 | 强制"先展示调用意图，再执行" 的双击确认模式 |
结语
把 Tools 和 Resources 视为"行动 API"与"知识快照"两条并行的高速公路：前者驱动模型改变世界，后者让模型看清世界。只要在权限、粒度、流量三方面做好设计，你就能让 MCP 服务器即插即用，既保证用户安全，又把 LLM 的决策链路推向高度自动化与可审计的专业级水平。