一句话定义：MCP（Model Context Protocol，AI 词典：模型上下文协议">模型上下文协议）的三个原语是 Tools（工具）、Resources（资源）和 Prompts（提示模板），它们是服务器向外暴露的三类标准接口，分别回答“能做什么”“能看什么”“该怎么问”。
打个比方。把 MCP 服务器想成开在你公司楼下的一家外包工作室：墙上挂着档案柜（Resources），里面是报价单、产品手册、客户记录，只读，看完就走，不会改变任何东西；你也可以让它动手干活（Tools），下单、发邮件、改状态；前台还摆着一叠预先印好的表单（Prompts），是工作室写好的“标准问法”，你填两个空格就能用。
这三者的关键差别不在形式，而在控制权归属：
| 原语 | 谁决定使用 | 典型形态 | 有无副作用 |
|---|---|---|---|
| Tools 工具 | 模型（模型自行判断何时调用） | 带参数的函数式动作 | 有，会改变外部状态 |
| Resources 资源 | 宿主应用（应用决定把哪些放进上下文） | 按 URI 寻址的只读数据 | 无 |
| Prompts 提示模板 | 用户（用户主动挑选） | 带参数的预写指令 | 无 |
最常见的误解，是把 MCP 当成“插件协议”，觉得它不过是 function calling（函数调用）的搬运工。可函数调用只覆盖了“工具”这一层。真正的设计意图藏在另外两个原语里：Resources 让“上下文从哪来”变成可寻址、可枚举的东西，而不是靠人肉复制粘贴；Prompts 把“该怎么问”从个人随手写的提示词，变成可复用、可版本管理的团队资产。（客户端一侧另有 roots、sampling 等能力，不在这三个服务器原语之列。）
对从业者的意义：如果只把 MCP 服务器做成一堆工具，你会浪费掉大半设计空间。只读数据密集的场景——文档库、日志、知识库——用 Resources 暴露，往往比包一层“读取文件”的工具更贴合语义、也更可控。同理，把高频任务写成 Prompts，比在文档里教用户“请这样问”要靠谱得多。
对普通职场人的意义：以后你在 AI 客户端里看到“选择某个资料源”“插入某个模板”这类入口，背后就是这两个原语在起作用。工具负责动手，资源和模板负责让 AI 说对话——三者合起来，才叫上下文协议。
具体字段定义与最新规范，以官方页面为准。