第一次写 MCP server 的人，十有八九会把所有能力都注册成 Tool。读文档是 Tool，查配置是 Tool，连「帮我按公司格式写周报」也做成一个 Tool。跑起来没问题，过两个月回头看，权限审计时谁也说不清哪个 Tool 会改数据、哪个只是读。
Trustscrin CloudLab 有一期不到四分钟的视频专讲这件事，标题是 MCP Tools vs Resources vs Prompts。视频给的分界只有一句，Tools 做事，Resources 供上下文，Prompts 定工作流。Tools 面向真实动作，例子是查库、开单、重启服务、发消息，应该窄、可审、意图清楚。Resources 在模型回答之前提供只读上下文。Prompts 封装可以反复使用的流程。视频还提醒，初学者常把三者混在一起，做成一个「admin everything」式的巨型能力球，爆炸半径大，也难以信任。下文对视频的转述以它的字幕为准，没有引用任何测评分数。
这篇只讨论一个对象，就是 MCP 协议里这三种原语各自该装什么。判断依据是意图，最后落到能用、限场景、不能用三档。
图注 左侧为三原语按意图的能用档，右侧为限场景与不能用的错放样本。
四个判断维度
有没有真实副作用。 调用之后外部世界会不会变，比如写库、发消息、开工单、重启进程。有副作用的能力只能是 Tool，并且要能单独审批、单独记录。
是不是只需要只读上下文。 模型回答前需要看一份产品文档、一段配置、一张表的当前快照，这类内容不改变任何东西，应该做成 Resource，由客户端决定何时加载进上下文。
是不是可复用的工作流模板。 事故复盘、代码评审、周报整理这类流程，每次步骤相同、输入不同，适合做成 Prompt，由用户主动挑选触发。
错放的代价有多大。 同一个能力放错原语，后果差别很大。只读文档做成 Tool，代价是权限面变宽、审计噪声变多。写库做成 Resource，代价是客户端在加载上下文时就可能触发写入，这几乎没法审计。巨型能力球的代价最大，一个授权就放开了所有动作。
三档终裁
能用。 能力的意图和原语一致，并且粒度够窄。带参数的实时查询，比如按订单号查状态，视频把查库归在 Tools 里，我也按能用处理，前提是它只读、参数受限、调用有记录。开工单做成 Tool，产品文档做成 Resource，事故复盘流程做成 Prompt，都在这一档。Resource 也有粒度问题，把整个知识库做成一个 Resource，客户端一次加载几十万字，上下文立刻被挤满。按文档或按主题切成多个 Resource，让客户端按需挑选，才算真正的能用。Tool 的粒度标准是一次调用只做一种动作，参数只描述对象，不描述动作类型。
限场景。 意图没错，原语却放偏了，修改声明就能回到能用档。典型例子是把只读的员工手册做成一个声明会修改状态的 Tool，权限过大，审批系统会把它当成高危动作拦下，徒增人工。另一个例子是把某次会话里的一段闲聊模板注册成全局 Prompt，所有用户都能在列表里看到它，既无复用价值，也干扰了真正的工作流。
不能用。 错放之后无法靠改声明补救，必须拆分或重做。写数据库的能力做成 Resource 属于这一档，客户端读取上下文就会触发写入。巨型 admin 工具同样不能用，它把查询、修改、删除、重启塞进一个入口，参数里一个字段决定做什么，审批只能整体放行或整体拒绝。
实验，给一份能力划分表打分
我准备了一份模拟的 MCP server 能力划分表，共八项能力，每项先标声明的原语和权限宽窄，再用三个零一字段记录副作用、只读与流程复用的情况。脚本先按四个维度推出期望原语，再和声明对比，输出三档终裁。文件在 _w/mcp-primitives-verdict/，结果写进 verdict.csv。
text
query_orders tool 能用 带参实时查询属动作，窄且可审
create_ticket tool 能用 意图与原语一致
product_docs resource 能用 意图与原语一致
incident_review prompt 能用 意图与原语一致
write_db_row resource 不能用 Resource 带副作用，读即写
read_handbook tool 限场景 只读需求却声明副作用，权限过大
chitchat_once prompt 限场景 原语错放，需改声明
admin_everything tool 不能用 巨型能力球，爆炸半径大须拆分八项里四项能用，两项限场景，两项不能用。种进去的四个错放全部被拦住，没有一项被误判成能用。这张表本身是我编的模拟数据，用来演示判定逻辑，不代表任何真实 server 的统计。
巨型能力球怎么拆
admin_everything 是视频重点警告的形状，单独说说拆法。先按副作用把动作分开，只读的查询拆出来，能做成 Resource 的做成 Resource，需要参数的做成窄 Tool。有副作用的动作按影响范围再拆，改单条记录、批量修改、删除、重启各成一个 Tool，每个都有自己的审批档位。原先藏在参数里的「模式」字段一律取消，一个 Tool 只做一件事。
拆完以后 Tool 数量会变多，这是正常代价。数量多带来的选择困难，可以靠清楚的命名和描述缓解，比让模型面对一个万能入口安全得多。
Prompts 最容易被低估
三种原语里，Prompts 用得最少。很多团队把流程直接写进 Tool 的描述，或者让用户自己在对话里贴一大段指令。这样做的问题是流程散落在各处，改一次要找好几个地方。视频把 Prompts 定位成可复用流程，我理解它的价值在于把步骤和输入分开，流程由 server 维护，用户只需要填本次的事故编号或代码分支。
Prompt 和 Tool 的边界也要守。Prompt 只负责组织模型该怎么做，真正的动作仍然交给 Tool。如果一个 Prompt 的内容里写着「直接删除过期记录」，而对应的删除 Tool 没有单独审批，等于借流程模板绕开了权限。验收时要检查每个 Prompt 会引导模型调用哪些 Tool，那些 Tool 的审批档位是否和流程的风险匹配。
评审会上怎么用这套终裁
新 server 上线前的设计评审，可以把能力划分表直接投在屏幕上，逐行过三档。限场景的条目当场改声明，不能用的条目记下负责人和拆分期限。已经上线的 server，每个季度拿实际调用日志回填一次表格，看有没有 Tool 长期只被用来读，有没有 Resource 的读取频率异常高。前者可以降级成 Resource，后者要查是否有客户端在反复拉取大块内容，拖慢了响应。
验收清单
- 每个 Tool 写明副作用，没有副作用的能力逐个确认是否应改成 Resource。
- 每个 Resource 确认读取不会触发任何写入或外部调用。
- 每个 Prompt 确认至少会被复用两次以上，一次性内容不进全局列表。
- 不存在用参数切换动作类型的 Tool。
- 有副作用的 Tool 各自对应一个审批档位，审批表和 Tool 名一一对应。
五条全过记为能用，有一条限场景就修改声明后复验，出现写库 Resource 或巨型能力球直接打回重做。
这份终裁的边界
视频只有不到四分钟，讲的是意图层面的分界，没有涉及具体客户端如何加载 Resource、Prompt 在不同客户端里如何呈现。这些行为由客户端实现决定，上线前要在你实际使用的客户端里各验一次。本文的三档判定也只覆盖原语选择，鉴权、限流、日志保留这些安全措施不能因为原语选对了就省掉。
带参数的只读查询放 Tool 还是放 Resource，视频的例子倾向 Tool，社区做法也不统一。我的判断是参数由模型临时决定的放 Tool，内容相对固定、由客户端预先加载的放 Resource。团队里定一条规则写进设计文档，比每次争论更省事。
小结
MCP 三原语的分界按意图来。会改变外部世界的做 Tool，回答前要看的只读材料做 Resource，反复使用的流程做 Prompt。错放分两种程度，改声明能修好的算限场景，读即写和巨型能力球直接不能用。拿一份能力划分表跑一遍判定，把结果写进评审记录，server 的权限面就能看得清楚。