一次讲清 MCP 三大 PrimitivesTools、Resources、Prompts 如何协作MCP 从入门到工程实践系列第 2 篇共 9 篇。上一篇MCP 架构与 JSON-RPC 2.0。MCP 文档经常使用一个不太容易直接翻译的词Primitive。这里的 Primitive 可以理解为协议定义的基础能力类别它规定 Client 和 Server 可以通过什么标准方式交换信息或执行动作。MCP Server 最重要的三个 Primitive 是ToolsResourcesPrompts。很多初学者会把它们简单理解成Tool API Resource 文件 Prompt 一段提示词这种理解不够准确。真正区分它们的关键是它们在交互中承担什么职责谁默认决定使用它使用什么协议操作返回的到底是能力、数据还是消息模板。一、先看整体对比Primitive核心作用默认控制者典型协议操作Tool执行动作、查询或计算Model 建议Host 最终授权tools/list、tools/callResource提供只读上下文数据Application 选择和读取resources/list、resources/templates/list、resources/readPrompt提供可复用消息模板和工作流入口User 显式选择prompts/list、prompts/get“谁控制”描述的是默认交互模型不是绝对权限边界。真正执行前Host 仍然要负责权限参数校验用户确认安全策略结果处理。二、Tool让模型提出动作请求Tool 是具有名称、描述和 Schema 的可执行能力。例如旅行 Server 暴露一个航班搜索 Tool{name:searchFlights,description:Search for available flights,inputSchema:{type:object,properties:{origin:{type:string,description:Departure city},destination:{type:string,description:Arrival city},date:{type:string,format:date,description:Travel date}},required:[origin,destination,date]}}1.tools/list发现能力Client 调用tools/list得到 Server 暴露的 Tool Definitions。每个 Definition 通常包括name执行时使用的精确名称title适合 UI 展示的名称description告诉模型和用户什么时候使用inputSchema输入参数的 JSON Schema可选outputSchema结构化输出约定。2.tools/call执行能力模型根据 Tool Definition 生成一次具体调用{name:searchFlights,arguments:{origin:NYC,destination:Barcelona,date:2026-09-15}}Host 校验后再由 MCP Client 发送tools/call。3. Tool Schema 不是模型生成的必须区分Server / SDK 定义 Tool Schema ↓ Host 把 Schema 提供给模型 ↓ 模型生成本次 Name Arguments ↓ Host 校验、授权、构造 MCP Request模型通常不创造 Tool Definition也不负责构造完整 JSON-RPC 外壳。4. Model-controlled 不等于模型拥有权限“Tool 是 Model-controlled”主要表示模型可以根据用户问题主动建议调用。安全控制链仍然是模型建议 ↓ Host 检查可用性和参数 ↓ 权限策略 ↓ 必要时用户 Approval ↓ 执行 Tool ↓ Activity Log具有写入、副作用或外部影响的 Tool更应该保留清晰的授权边界。三、Resource由 Application 管理的上下文数据Resource 表示 AI Application 可以读取并作为 Context 使用的数据。常见来源文件数据库记录或 SchemaAPI Response知识库文档日历代码仓库内容。每个 Resource 使用 URI 标识并可以声明 MIME Type。例如file:///project/README.md calendar://events/2026 db://schema/orders travel://history/barcelona-20251. 为什么 API 也可以是 Resource 来源API 是交互接口Resource 是通过 MCP 暴露给 Application 的上下文数据。两者不在同一层。第三方 HTTP API ↓ Server 发请求 API Response ↓ Server 转换或包装 MCP Resource ↓ resources/read AI Application所以“API 属于 Resource”更准确的理解是MCP Server 可以把 API 返回的数据包装成 Resource而不是说 HTTP Endpoint 本身等于一份上下文。2.resources/list列出固定资源resources/list返回 Direct Resource Descriptor。{resources:[{uri:file:///project/README.md,name:README,description:Project overview,mimeType:text/markdown}]}它相当于资源目录不等于把所有内容都读出来。3.resources/read读取内容Application 选择 URI 后再调用{method:resources/read,params:{uri:file:///project/README.md}}这种“先发现、再读取”的设计带来两个好处不必一次下载全部内容Application 可以先搜索、筛选和预览。4.resources/templates/list发现动态 URI有些资源组合无法提前穷举。例如weather://forecast/{city}/{date}城市和日期的组合几乎无限Server 不可能在resources/list中列出每一项。它可以通过resources/templates/list返回{uriTemplate:weather://forecast/{city}/{date},name:weather-forecast,title:Weather Forecast,description:Get weather forecast for any city and date,mimeType:application/json}Application 填入参数cityBarcelona date2026-09-15构造weather://forecast/Barcelona/2026-09-15然后再调用resources/read。Resource Template 的作用是描述合法 URI 怎样构造不是直接返回所有数据。5. Parameter Completion动态参数还可以支持 Completion输入Par提示 Paris、Park City输入JFK提示 JFK - John F. Kennedy International输入 Query ID 前缀提示可用记录。Completion 帮用户发现合法参数值但不替代resources/read。6. Resource UpdateClient 可以监听具体 Resource{method:subscriptions/listen,params:{resourceSubscriptions:[file:///project/requirements.md]}}内容变化后Server 发送notifications/resources/updated。Client 通常将旧内容标记为 stale再重新resources/read。四、Application-driven 到底是什么意思Resource 默认由 Application 驱动。Application 可以决定让用户手动选文件通过文件树或列表浏览使用关键词搜索使用 Embedding 选相关片段根据当前会话自动推荐读取全部小型资源只把部分内容送入模型。MCP 不规定 Resource 必须怎样展示也不强迫 Application 把所有内容都交给模型。这也是 Resource 与 Tool 的重要区别Tool模型通常可以主动建议调用 ResourceApplication 通常先决定读取和注入什么大数据量 Resource 的检索会在本系列下一篇详细展开。五、Prompt可复用的消息模板与工作流入口Prompt 不是 Host 内部随便写的一段 System Prompt而是 MCP Server 可以公开发现的一种 Primitive。它适合固化领域工作流展示一组 Tool 的推荐用法引用 Resource提供 Few-shot 示例统一输出结构把领域专家经验做成参数化模板。1.prompts/list发现 Prompt Descriptor{name:plan-vacation,title:Plan a vacation,description:Guide through vacation planning process,arguments:[{name:destination,type:string,required:true},{name:duration,type:number,description:days},{name:budget,type:number,required:false}]}prompts/list返回的是可发现目录不是要求 UI 把每一项全部铺出来。2.prompts/get展开模板用户选择 Prompt 并填写参数后Client 调用{method:prompts/get,params:{name:plan-vacation,arguments:{destination:Barcelona,duration:7,budget:3000}}}Server 返回展开后的 Messages。Host 再把这些 Messages 加入模型交互。Prompt 本身不直接执行 Tool。六、Prompt 为什么需要用户显式触发Server Concepts 页面给 Prompt 的默认交互模型是 User-controlledClient prompts/list ↓ Client 通过 UI、命令或搜索提供入口 ↓ 用户明确选择 Prompt ↓ 填写 Arguments ↓ Client prompts/get ↓ 把展开后的 Messages 交给模型常见 UI 可以是Slash CommandCommand Palette按钮表单Context Menu搜索面板推荐卡片。协议不规定必须使用哪一种。Prompt 很多时是否全部显示不需要。Client 可以根本不实现 MCP Prompt UI只显示常用 Prompt按 Server 或领域分类根据 Context 推荐在命令面板中搜索使用 Parameter Completion把少数 Prompt 映射成固定按钮。因此 Server 同时有 Tool、Resource 和 Prompt不代表 Host 一定会在主界面分成三个完整列表展示。为什么在 Codex 等应用里看不到 MCP Prompt可能原因包括当前 Host 没有公开 Prompt UI已连接 Server 没有提供 Prompt产品主要突出 ToolPrompt 被放在命令面板或其他入口Host 根本没有实现这一可选能力。看不到 UI 不能证明内部一定使用也不能证明一定没有使用。判断某个具体 Server 是否提供 Prompt应查看 Capability 或prompts/list而不是凭感觉判断整个生态。只输入queryId12345Client 怎么知道用哪个 Prompt它不会自动知道。必须先建立 Prompt Name 的映射用户选择“分析慢查询” ↓ UI 映射到 investigate-slow-query ↓ 用户填写 queryId12345 ↓ Client prompts/get( nameinvestigate-slow-query, arguments{queryId: 12345} )只有参数而没有 Prompt Name 或明确入口Client 无法知道应该调用哪个模板。七、Prompt 的真正价值假设数据库 MCP Server 暴露十几个 Tool读取慢查询获取执行计划读取索引检查锁等待获取表统计信息。Server 作者还可以提供investigate-slow-query把领域经验固化为先要求 Query ID读取指标和执行计划只调用只读诊断 Tool不自动执行高风险优化按 Root Cause、Evidence、Recommendation 输出。它的价值不是“模型不会写提示词”而是Server 作者可以把正确使用工具和资源的方法做成可发现、可参数化、可维护的工作流。八、三个 Primitive 如何协作以多 Server 旅行规划为例Travel Server ├─ searchFlights ├─ bookHotel └─ travel preference Resources Weather Server ├─ checkWeather └─ forecast Resources Calendar / Email Server ├─ calendar Resources ├─ createCalendarEvent └─ sendEmail完整流程第一步用户选择 Prompt{prompt:plan-vacation,arguments:{destination:Barcelona,departure_date:2026-09-15,return_date:2026-09-22,budget:3000,travelers:2}}第二步Application 选择 Resources当前日历欧洲旅行偏好过去的西班牙行程证件信息。第三步模型使用 ToolssearchFlights()checkWeather()bookHotel()createCalendarEvent()sendEmail()。第四步Host 管理权限和确认搜索天气可以自动允许真正预订酒店或发送邮件则可能要求 Approval。最终Prompt 规定工作流 Resource 提供上下文 Tool 执行查询和动作 Host 负责安全、路由和呈现三个 Primitive 不是互斥产品而是同一工作流中的不同角色。九、常见误区误区 1Tool 就是第三方 APITool 是 MCP 暴露的能力接口其内部可以调用 API、数据库或本地程序。误区 2Resource 只能是文件Resource 可以来自文件、API、数据库或任何上下文来源。误区 3resources/list会返回所有文件内容它主要返回 Descriptor真正内容通过resources/read获取。误区 4Resource Template 会穷举所有资源它描述动态 URI 规则避免穷举。误区 5模型会自动调用 MCP PromptPrompt 默认由用户显式触发它不同于 Model-controlled Tool。误区 6Prompt 必须在主界面全部显示协议只提供发现能力UI 和筛选策略由 Host 决定。误区 7Prompt 展开后会自动执行工作流prompts/get返回 Messages真正的 Tool 执行仍由 Host 和模型完成。总结可以用三句话记住 MCP 三大 PrimitiveTool 可以执行什么 Resource 可以读取什么 Prompt 推荐怎样组织这次任务更完整地说Tool 是 Schema-defined Action模型可以建议调用Resource 是 Application-managed Context通过 URI 发现和读取Prompt 是 User-controlled Template需要显式选择和参数化Host 始终负责权限、校验、路由和 UI三者可以跨多个 MCP Server 组合成完整工作流。下一篇将专门处理一个更现实的问题当 Resource 数量很大时是否必须提前建向量数据库Search Tool、Embedding、Top-K 和resources/read到底如何协作如果本文帮你分清了 Tools、Resources 和 Prompts欢迎点赞、收藏。后续还会继续更新完整 MCP Server 与 Client 实战。参考资料https://modelcontextprotocol.io/docs/2026-07-28/learn/server-conceptshttps://modelcontextprotocol.io/docs/2026-07-28/learn/architecturehttps://modelcontextprotocol.io/docs/2026-07-28/learn/client-concepts 一次讲清 MCP 三大 Primitives：Tools、Resources、Prompts 如何协作
一次讲清 MCP 三大 PrimitivesTools、Resources、Prompts 如何协作MCP 从入门到工程实践系列第 2 篇共 9 篇。上一篇MCP 架构与 JSON-RPC 2.0。MCP 文档经常使用一个不太容易直接翻译的词Primitive。这里的 Primitive 可以理解为协议定义的基础能力类别它规定 Client 和 Server 可以通过什么标准方式交换信息或执行动作。MCP Server 最重要的三个 Primitive 是ToolsResourcesPrompts。很多初学者会把它们简单理解成Tool API Resource 文件 Prompt 一段提示词这种理解不够准确。真正区分它们的关键是它们在交互中承担什么职责谁默认决定使用它使用什么协议操作返回的到底是能力、数据还是消息模板。一、先看整体对比Primitive核心作用默认控制者典型协议操作Tool执行动作、查询或计算Model 建议Host 最终授权tools/list、tools/callResource提供只读上下文数据Application 选择和读取resources/list、resources/templates/list、resources/readPrompt提供可复用消息模板和工作流入口User 显式选择prompts/list、prompts/get“谁控制”描述的是默认交互模型不是绝对权限边界。真正执行前Host 仍然要负责权限参数校验用户确认安全策略结果处理。二、Tool让模型提出动作请求Tool 是具有名称、描述和 Schema 的可执行能力。例如旅行 Server 暴露一个航班搜索 Tool{name:searchFlights,description:Search for available flights,inputSchema:{type:object,properties:{origin:{type:string,description:Departure city},destination:{type:string,description:Arrival city},date:{type:string,format:date,description:Travel date}},required:[origin,destination,date]}}1.tools/list发现能力Client 调用tools/list得到 Server 暴露的 Tool Definitions。每个 Definition 通常包括name执行时使用的精确名称title适合 UI 展示的名称description告诉模型和用户什么时候使用inputSchema输入参数的 JSON Schema可选outputSchema结构化输出约定。2.tools/call执行能力模型根据 Tool Definition 生成一次具体调用{name:searchFlights,arguments:{origin:NYC,destination:Barcelona,date:2026-09-15}}Host 校验后再由 MCP Client 发送tools/call。3. Tool Schema 不是模型生成的必须区分Server / SDK 定义 Tool Schema ↓ Host 把 Schema 提供给模型 ↓ 模型生成本次 Name Arguments ↓ Host 校验、授权、构造 MCP Request模型通常不创造 Tool Definition也不负责构造完整 JSON-RPC 外壳。4. Model-controlled 不等于模型拥有权限“Tool 是 Model-controlled”主要表示模型可以根据用户问题主动建议调用。安全控制链仍然是模型建议 ↓ Host 检查可用性和参数 ↓ 权限策略 ↓ 必要时用户 Approval ↓ 执行 Tool ↓ Activity Log具有写入、副作用或外部影响的 Tool更应该保留清晰的授权边界。三、Resource由 Application 管理的上下文数据Resource 表示 AI Application 可以读取并作为 Context 使用的数据。常见来源文件数据库记录或 SchemaAPI Response知识库文档日历代码仓库内容。每个 Resource 使用 URI 标识并可以声明 MIME Type。例如file:///project/README.md calendar://events/2026 db://schema/orders travel://history/barcelona-20251. 为什么 API 也可以是 Resource 来源API 是交互接口Resource 是通过 MCP 暴露给 Application 的上下文数据。两者不在同一层。第三方 HTTP API ↓ Server 发请求 API Response ↓ Server 转换或包装 MCP Resource ↓ resources/read AI Application所以“API 属于 Resource”更准确的理解是MCP Server 可以把 API 返回的数据包装成 Resource而不是说 HTTP Endpoint 本身等于一份上下文。2.resources/list列出固定资源resources/list返回 Direct Resource Descriptor。{resources:[{uri:file:///project/README.md,name:README,description:Project overview,mimeType:text/markdown}]}它相当于资源目录不等于把所有内容都读出来。3.resources/read读取内容Application 选择 URI 后再调用{method:resources/read,params:{uri:file:///project/README.md}}这种“先发现、再读取”的设计带来两个好处不必一次下载全部内容Application 可以先搜索、筛选和预览。4.resources/templates/list发现动态 URI有些资源组合无法提前穷举。例如weather://forecast/{city}/{date}城市和日期的组合几乎无限Server 不可能在resources/list中列出每一项。它可以通过resources/templates/list返回{uriTemplate:weather://forecast/{city}/{date},name:weather-forecast,title:Weather Forecast,description:Get weather forecast for any city and date,mimeType:application/json}Application 填入参数cityBarcelona date2026-09-15构造weather://forecast/Barcelona/2026-09-15然后再调用resources/read。Resource Template 的作用是描述合法 URI 怎样构造不是直接返回所有数据。5. Parameter Completion动态参数还可以支持 Completion输入Par提示 Paris、Park City输入JFK提示 JFK - John F. Kennedy International输入 Query ID 前缀提示可用记录。Completion 帮用户发现合法参数值但不替代resources/read。6. Resource UpdateClient 可以监听具体 Resource{method:subscriptions/listen,params:{resourceSubscriptions:[file:///project/requirements.md]}}内容变化后Server 发送notifications/resources/updated。Client 通常将旧内容标记为 stale再重新resources/read。四、Application-driven 到底是什么意思Resource 默认由 Application 驱动。Application 可以决定让用户手动选文件通过文件树或列表浏览使用关键词搜索使用 Embedding 选相关片段根据当前会话自动推荐读取全部小型资源只把部分内容送入模型。MCP 不规定 Resource 必须怎样展示也不强迫 Application 把所有内容都交给模型。这也是 Resource 与 Tool 的重要区别Tool模型通常可以主动建议调用 ResourceApplication 通常先决定读取和注入什么大数据量 Resource 的检索会在本系列下一篇详细展开。五、Prompt可复用的消息模板与工作流入口Prompt 不是 Host 内部随便写的一段 System Prompt而是 MCP Server 可以公开发现的一种 Primitive。它适合固化领域工作流展示一组 Tool 的推荐用法引用 Resource提供 Few-shot 示例统一输出结构把领域专家经验做成参数化模板。1.prompts/list发现 Prompt Descriptor{name:plan-vacation,title:Plan a vacation,description:Guide through vacation planning process,arguments:[{name:destination,type:string,required:true},{name:duration,type:number,description:days},{name:budget,type:number,required:false}]}prompts/list返回的是可发现目录不是要求 UI 把每一项全部铺出来。2.prompts/get展开模板用户选择 Prompt 并填写参数后Client 调用{method:prompts/get,params:{name:plan-vacation,arguments:{destination:Barcelona,duration:7,budget:3000}}}Server 返回展开后的 Messages。Host 再把这些 Messages 加入模型交互。Prompt 本身不直接执行 Tool。六、Prompt 为什么需要用户显式触发Server Concepts 页面给 Prompt 的默认交互模型是 User-controlledClient prompts/list ↓ Client 通过 UI、命令或搜索提供入口 ↓ 用户明确选择 Prompt ↓ 填写 Arguments ↓ Client prompts/get ↓ 把展开后的 Messages 交给模型常见 UI 可以是Slash CommandCommand Palette按钮表单Context Menu搜索面板推荐卡片。协议不规定必须使用哪一种。Prompt 很多时是否全部显示不需要。Client 可以根本不实现 MCP Prompt UI只显示常用 Prompt按 Server 或领域分类根据 Context 推荐在命令面板中搜索使用 Parameter Completion把少数 Prompt 映射成固定按钮。因此 Server 同时有 Tool、Resource 和 Prompt不代表 Host 一定会在主界面分成三个完整列表展示。为什么在 Codex 等应用里看不到 MCP Prompt可能原因包括当前 Host 没有公开 Prompt UI已连接 Server 没有提供 Prompt产品主要突出 ToolPrompt 被放在命令面板或其他入口Host 根本没有实现这一可选能力。看不到 UI 不能证明内部一定使用也不能证明一定没有使用。判断某个具体 Server 是否提供 Prompt应查看 Capability 或prompts/list而不是凭感觉判断整个生态。只输入queryId12345Client 怎么知道用哪个 Prompt它不会自动知道。必须先建立 Prompt Name 的映射用户选择“分析慢查询” ↓ UI 映射到 investigate-slow-query ↓ 用户填写 queryId12345 ↓ Client prompts/get( nameinvestigate-slow-query, arguments{queryId: 12345} )只有参数而没有 Prompt Name 或明确入口Client 无法知道应该调用哪个模板。七、Prompt 的真正价值假设数据库 MCP Server 暴露十几个 Tool读取慢查询获取执行计划读取索引检查锁等待获取表统计信息。Server 作者还可以提供investigate-slow-query把领域经验固化为先要求 Query ID读取指标和执行计划只调用只读诊断 Tool不自动执行高风险优化按 Root Cause、Evidence、Recommendation 输出。它的价值不是“模型不会写提示词”而是Server 作者可以把正确使用工具和资源的方法做成可发现、可参数化、可维护的工作流。八、三个 Primitive 如何协作以多 Server 旅行规划为例Travel Server ├─ searchFlights ├─ bookHotel └─ travel preference Resources Weather Server ├─ checkWeather └─ forecast Resources Calendar / Email Server ├─ calendar Resources ├─ createCalendarEvent └─ sendEmail完整流程第一步用户选择 Prompt{prompt:plan-vacation,arguments:{destination:Barcelona,departure_date:2026-09-15,return_date:2026-09-22,budget:3000,travelers:2}}第二步Application 选择 Resources当前日历欧洲旅行偏好过去的西班牙行程证件信息。第三步模型使用 ToolssearchFlights()checkWeather()bookHotel()createCalendarEvent()sendEmail()。第四步Host 管理权限和确认搜索天气可以自动允许真正预订酒店或发送邮件则可能要求 Approval。最终Prompt 规定工作流 Resource 提供上下文 Tool 执行查询和动作 Host 负责安全、路由和呈现三个 Primitive 不是互斥产品而是同一工作流中的不同角色。九、常见误区误区 1Tool 就是第三方 APITool 是 MCP 暴露的能力接口其内部可以调用 API、数据库或本地程序。误区 2Resource 只能是文件Resource 可以来自文件、API、数据库或任何上下文来源。误区 3resources/list会返回所有文件内容它主要返回 Descriptor真正内容通过resources/read获取。误区 4Resource Template 会穷举所有资源它描述动态 URI 规则避免穷举。误区 5模型会自动调用 MCP PromptPrompt 默认由用户显式触发它不同于 Model-controlled Tool。误区 6Prompt 必须在主界面全部显示协议只提供发现能力UI 和筛选策略由 Host 决定。误区 7Prompt 展开后会自动执行工作流prompts/get返回 Messages真正的 Tool 执行仍由 Host 和模型完成。总结可以用三句话记住 MCP 三大 PrimitiveTool 可以执行什么 Resource 可以读取什么 Prompt 推荐怎样组织这次任务更完整地说Tool 是 Schema-defined Action模型可以建议调用Resource 是 Application-managed Context通过 URI 发现和读取Prompt 是 User-controlled Template需要显式选择和参数化Host 始终负责权限、校验、路由和 UI三者可以跨多个 MCP Server 组合成完整工作流。下一篇将专门处理一个更现实的问题当 Resource 数量很大时是否必须提前建向量数据库Search Tool、Embedding、Top-K 和resources/read到底如何协作如果本文帮你分清了 Tools、Resources 和 Prompts欢迎点赞、收藏。后续还会继续更新完整 MCP Server 与 Client 实战。参考资料https://modelcontextprotocol.io/docs/2026-07-28/learn/server-conceptshttps://modelcontextprotocol.io/docs/2026-07-28/learn/architecturehttps://modelcontextprotocol.io/docs/2026-07-28/learn/client-concepts