MCP 里除了 tools 还有 resources 和 prompts，大家都忽略了

上个月帮客户做 MCP 架构评审，翻了一圈他们现有的 11 个 server。

看完我问：”为什么全部都只有 tools？”客户 AI 平台负责人愣了一下：”还能有别的？”

这不是他一个人的问题。我顺手扫了 GitHub 上 Star 数前 50 的公开 MCP server，46 个只实现了 tools，只有 4 个碰了 resources，实现了 prompts 的 1 个都没有。

可 MCP 规范里明明写着三个并列原语：tools、resources、prompts。Anthropic 不是闲的蛋疼才设计三个东西。这篇我把被忽略的两块讲明白。

三个原语的设计意图

先把定位讲清楚：

• tools：Agent 可以”执行”的动作，有副作用，模型主动决定调用
• resources：只读数据，像文件一样被”浏览”或”附加到 context”，通常由用户/客户端主动选择
• prompts：服务器预制的 prompt 模板，用户触发（比如 Claude Desktop 里的 “/command”），注入到对话

关键差异在”谁决定用、有没有副作用”。tools 是模型自主决定的执行动作，resources 和 prompts 更多是用户侧或客户端编排的资源注入。

举个不那么抽象的例子。假设你做一个 Confluence MCP server：

• tools：create_page、update_page、search、add_comment
• resources：每个 wiki page 暴露为 confluence://space/PROD/runbook-on-call，用户可以在 Claude Desktop 的 attachment 面板里选一个塞进 context
• prompts：/oncall-incident，预制一个事故响应模板，自动把值班 runbook 作为 resource 附带、引导用户填事故描述

只做 tools 你只覆盖了这套协议 1/3 的能力。

为什么 90% 的人只实现 tools

我琢磨了一下原因：

第一，教程带偏。Anthropic 官方教程主推 tools，因为 tools 是和 LLM function calling 最像的、最容易理解。resources 和 prompts 讲得少。

第二，客户端支持不一。截止 2026 年 4 月，Claude Desktop 对 resources 和 prompts 支持已经挺好，但 Cursor、Continue 这些 MCP 客户端对 prompts 的 UI 触发方式还不统一，开发者做了也不一定在所有地方能用。

第三，思维惯性。工程师脑子里 MCP = “让 LLM 能调外部函数”，这直接把 resources 和 prompts 排除在外了。

第四，文档里 resources 和 tools 的边界不够清晰。很多人搞不清：”我这个功能应该做成 tool 还是 resource？”

resources：不是 tool 的简写，是”浏览”的入口

判断标准其实很简单：有没有副作用 + 数据量大小。

一个 tool 调用完了会改变世界状态（写数据库、发消息、扣余额）。一个 resource 只是读——它可以有千兆文件，LLM 不一定全读进去，客户端可以按需展示、用户按需选择附加。

举个对比：

• search_products(query) 是 tool：返回 10 个结果塞给 LLM
• products://catalog 是 resource：整个目录（可能 47MB），用户在 UI 里手动浏览，选具体某个产品”附加到对话”

resource 的正确用法是给 Agent 做浏览，不是做执行。

我见过一个反模式：有人把数据库表暴露成 resource，比如 db://users/12345。这表面看挺合理——数据是只读的嘛。但实际使用极其别扭，因为 LLM 根本不知道有哪些 user id 可以读。resource 不适合”按 key 查询”，适合”按层级浏览”。

正面例子：把公司 wiki 按空间和 page 树结构暴露成 resource，用户/模型可以 list 目录、选 page 读取。这才是 resource 的味道。

prompts：团队知识沉淀的秘密武器

prompts 是最被低估的一块。

它不是”给 LLM 的 prompt”——那个是 system prompt。MCP 的 prompts 是可参数化的模板，用户或客户端触发时填参数、服务器渲染成消息列表返回给 LLM。

看起来平平无奇是吧？但你把视角切到”团队知识”维度，这东西价值一下就出来了。

想象你们团队有一套”故障响应 SOP”：

1. 先查 Grafana 最近 30 分钟 error rate
2. 对照 runbook 判断是已知问题还是新问题
3. 如果是已知问题按 runbook 操作
4. 如果是新问题，拉值班群、按升级路径通知
5. 事后写 incident report 到 Confluence

以前这套 SOP 放在 Notion 某个角落，新人进来培训时看一遍、实战时忘一半。

把它包装成一个 MCP prompt：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

@mcp.prompt()
def incident_response(
    severity: str,  # "P0" | "P1" | "P2"
    symptom: str,
) -> list[Message]:
    runbook = fetch_runbook(symptom)  # 根据症状拉对应 runbook
    return [
        Message(role="user", content=f"""
我刚触发一个 {severity} 事故，症状是：{symptom}

请按公司标准事故响应流程帮我：
1. 分析症状可能对应的根因（参考下方 runbook）
2. 给出下一步行动的优先级清单
3. 提醒我 {severity} 级别必须做的通知动作

相关 runbook：
{runbook}

公司 severity 标准：
- P0：全量用户影响，立刻拉 war room
- P1：部分用户影响，1h 内响应
- P2：功能降级，工作时间内响应
        """)
    ]

用户在 Claude Desktop 里打 /incident-response P0 "API 500 飙到 23%"，server 侧把 runbook 拉出来、按公司标准拼装 prompt、返回给 LLM。新人什么都不用记，流程内化在工具里。

一个真实案例：runbook 变 prompts

2026 年 1 月给一个中型 SaaS 客户做了类似改造。

客户情况：DevOps 团队 17 人，值班 rotation，每次新人上手要读 5 本 runbook（Kubernetes 集群、数据库、CDN、消息队列、监控），平均14 天才能独立值班。错误率高、老人累。

我做的事：

1. 把 5 本 runbook 拆成 38 个场景化 prompts，覆盖 “pod 频繁 OOM”、”redis 延迟突增”、”CDN 命中率下降” 等具体症状
2. 每个 prompt 参数化关键变量（集群、服务、时间范围），server 侧拼装上下文
3. 接入 Grafana MCP 和 Kubernetes MCP，prompt 渲染时自动附加实时指标
4. 在 Claude Desktop 里配好，新人打 /oncall- 自动补全

上线后的数据：新人独立值班时间从 14 天降到 3 天，老人值班加班时长平均每周少 4.2 小时，事故首次响应中位数从 8.3 分钟降到 2.1 分钟。

客户 DevOps 负责人给我发消息：”这玩意儿比 Runbook Wiki 强 10 倍，至少新人真的会用。”

说白了，写在 wiki 的东西没人看，做成”按一个 / 就触发的工作流”就有人用了。这就是 prompts 的价值。

什么时候用哪个？一个实用决策表

一些实现细节的坑

• resource URI 规范：用你自己 server 的 scheme（confluence://、jira://），别用 http://——客户端可能拦截
• prompts 返回消息列表：不是单个字符串，是完整的 messages 数组，可以包含 user/assistant 多轮
• capability 声明：server 构造时要显式开 capabilities.resources 和 capabilities.prompts，不然客户端根本不来问
• list 要快：resources/list 和 prompts/list 会在客户端 UI 渲染时频繁调用，别在里面跑慢查询

想把知识沉淀做得更系统，Skills 深度解析 和 自定义 Skill 实战 两篇从另一个角度讲了类似的思路——把团队最佳实践编码成可复用单元。MCP prompts 和 Skills 其实是同一个哲学的两个切面。