MCP三要素详解：Tools、Resources与Prompts如何分工

一个常被忽略的设计难题

当AI应用通过MCP（Model Context Protocol）服务器连接外部系统时，开发者经常面临一个看似简单却容易混淆的问题：一项功能到底应该实现为工具（Tool）、资源（Resource），还是提示（Prompt）？

以一个典型场景为例——数据库查询、数据库schema、分析指南三者共享同一个MCP服务器，用于把AI应用接入外部数据系统。乍看之下它们都和「数据库」相关，但在MCP的架构里，它们承担着截然不同的角色。

这里有一条贯穿始终的判断原则：Tools执行动作，Resources提供可读的上下文，Prompts是可复用的消息模板。 把每一项功能明确归类为「做事」「上下文」或「可复用指导」，职责边界自然清晰。

MCP（Model Context Protocol）是由 Anthropic 于 2024 年底提出的开放协议，旨在为 AI 应用提供一种标准化的方式，将大语言模型与外部数据源、工具及服务连接起来。在此之前，每个 AI 应用往往需要为每种外部集成单独开发适配层，导致大量重复工作。MCP 通过统一的客户端-服务器架构解决这一问题：MCP 服务器负责暴露能力（工具、资源、提示），MCP 客户端（通常内嵌在 AI 应用或 Agent 框架中）负责调用这些能力。正是因为协议将三类能力合并在同一个服务器中对外提供，开发者才容易混淆它们各自的适用场景——理解三者分工，是正确设计 MCP 服务器的前提。

Tools：触发实际逻辑的执行者

数据库查询应当被实现为一个 Tool。原因在于它的参数会触发数据库逻辑——即便这段逻辑只是读取记录，而非写入或修改。

这一点常常让人误解：很多人认为「只读」操作应该归为资源。但MCP的分类标准不在于读还是写，而在于是否需要根据输入参数执行某段逻辑。查询需要接收条件、拼接或执行语句、返回结果，这一整套过程属于「做事」，因此它是工具。

换句话说，判断一个功能是否为Tool，关键看它是否「因调用而产生行为」。只要有参数驱动的动作发生，无论结果是读取还是变更，它都属于工具的范畴。

Resources：无需运行即可获取的上下文

数据库的schema则是典型的 Resource。它是应用可以通过地址（address）直接访问的上下文，不需要运行任何查询就能获取。

Resource的本质是「静态可读的内容」。schema描述了数据的结构，它本身不执行计算、不接收参数，应用只要知道它的地址就能把它读出来作为背景知识。这类上下文帮助AI理解数据的组织方式，从而更准确地构造后续的查询。

资源与工具的分界因此变得明确：如果一项内容只需被「读取」而不触发任何逻辑执行，它就应该是资源。

Prompts：可复用的消息模板

分析指南（analysis guide）属于 Prompt。它是一种可复用的消息模板，提供的是「可重复使用的指导」。

Prompt既不执行动作，也不是被动的上下文数据，而是一套结构化、可被反复调用的引导性文本。它告诉模型如何进行分析、按什么框架组织思路。把常用的分析方法封装成Prompt，可以在不同场景下复用，避免每次手动重写指令。

这正是Prompt价值所在：将经验性的「怎么做」沉淀为模板，让团队与应用共享一致的指导逻辑。

在 MCP 协议中，Prompt 并非单纯的字符串常量，而是可以携带参数、由服务器动态渲染的结构化消息序列。客户端可以通过 prompts/list 接口发现服务器暴露的所有 Prompt，再通过 prompts/get 并传入参数来获取最终渲染好的消息列表。这意味着同一个分析指南模板可以根据不同的业务场景（如"按季度分析"或"按地区分析"）注入不同参数，生成差异化的引导文本，而无需在客户端硬编码多套指令。这种设计使 Prompt 兼具「模板复用」与「动态定制」两种能力，在团队协作或多 Agent 场景中尤为有用。

一条规则厘清三者边界

把这套分类逻辑浓缩成一句话：

• Tool（工具） = 做事，参数触发逻辑执行（如数据库查询）
• Resource（资源） = 上下文，可按地址读取、无需运行（如schema）
• Prompt（提示） = 可复用指导，结构化消息模板（如分析指南）

在设计MCP服务器时，面对任何一项功能，只需追问：它是在做事、提供上下文，还是给出可复用的指导？依照这个三分法归类，各组件的职责就不会相互越界，系统的可维护性与清晰度也随之提升。

对于正在构建Agentic AI系统的开发者而言，理解Tools、Resources、Prompts的分工不只是概念区分，更是保证AI应用与外部系统集成时架构整洁的基础。