Tools、Resources 和 Prompts

Tools, Resources and Prompts

Tools、Prompts 和 Resources 构成了 MCP 框架的三项核心能力。所谓能力（capability），本质上就是 Server 所开放出来的功能或特性。

• Tools：AI（Host/Client）可以调用的可执行操作或函数（通常会产生副作用，或涉及外部 API 调用）。
• Resources：AI（Host/Client）可以查询信息的只读数据源（不产生副作用，仅用于获取信息）。
• Prompts：Server 可以提供的预定义提示词模板或工作流。

Tools

Tools 就如同字面意思：代表 AI 模型「做某件事」的函数。这类操作通常会产生某种效果，或者需要超出 AI 自身能力的计算。需要注意的是，Tool 通常是由 AI 模型自主决定触发的——也就是说，当 LLM（通过 Host）判断自己需要某项功能时，就会决定调用相应的 Tool。假设我们有一个简单的天气查询 Tool，在 MCP Server 的代码里，它可能是这样的：

这个通过 @mcp.tool() 注册的 Python 函数，可以由 AI 经 MCP 调用。当 AI 调用 tools/call，并传入名称 "get_weather" 和参数 {"location": "San Francisco"} 时，Server 会执行 get_weather("San Francisco")，并返回字典形式的结果。Client 会拿到这个 JSON 结果，并把它提供给 AI。注意这里 Tool 返回的是结构化数据（温度、天气状况），AI 随后就可以使用这些信息，或者把它「说」出来（生成一段回复）。由于 Tool 可能会执行文件 I/O 或网络调用之类的操作，MCP 的实现通常会要求用户对 Tool 调用进行授权。

举例来说，Claude 的 Client 第一次遇到这种情况时，可能会弹出提示：「AI 想要使用 'get_weather' 这个 Tool，是否允许？」，以防止滥用。这确保了人类始终掌控着这些强大操作的最终决定权。Tools 类似于传统 function calling 中的「函数」，但在 MCP 下，它们被用在一个更灵活、更动态的语境里：由模型决定调用，但执行环节则需要经过开发者/治理策略的批准。

Resources

Resources 为 AI 模型提供只读数据。它们更像是数据库或知识库，AI 可以查询获取信息，但不能修改。和 Tools 不同，Resources 通常不涉及繁重的计算或副作用，因为它们大多只是信息查询。另一个关键区别在于，Resources 通常是在 Host 应用的控制下被访问的（而不是模型自发地去访问）。在实践中，这可能意味着由 Host 来判断何时需要为模型获取某段上下文。比如，如果用户说「用公司手册来回答我的问题」，Host 就可能会调用某个 Resource，取出手册中相关的章节，再喂给模型。Resources 可以是本地文件的内容、知识库或文档中的片段、某次数据库查询的（只读）结果，也可以是配置信息之类的静态数据——本质上，只要是 AI 可能需要作为上下文了解的东西都算。一个 AI 研究助手，可以拥有像「ArXiv 论文数据库」这样的 Resource，在被问到时检索出摘要或参考文献。一个简单的 Resource 可以是一个用来读取文件的函数：

这里我们用了一个装饰器 @mcp.resource("file://{path}")，它大致表示一种 Resource URI 的模板。AI（或者说 Host）可以带着类似 file://home/user/notes.txt 这样的 URI，向 Server 请求 resources.get，Server 则会调用 read_file("/home/user/notes.txt") 并返回文本内容。请注意，Resources 通常是通过某种标识符（比如 URI 或名称）来定位的，而不是像自由形式的函数那样调用。它们也往往是由应用来控制的，也就是说由应用决定何时去获取它们（以避免模型随意读取一切）。从安全角度看，由于 Resources 是只读的，风险相对较低，但仍然需要考虑隐私和权限问题（AI 不应该读取它本不该读取的文件）。Host 可以限制 AI 能够访问哪些 Resource URI，Server 也可能对某些数据的访问加以限制。总的来说，Resources 让 AI 获得知识，却不会把「修改一切」的权限交出去。它们相当于 MCP 版本的「在需要时提供参考资料」，就像是一套通过协议集成、更智能的按需检索系统。

Prompts

在 MCP 的语境下，Prompts 是一个比较特别的概念：它们是预定义的提示词模板或对话流程，可以被注入进来，用于引导 AI 的行为。本质上，Prompt 这项能力提供的是一套现成的指令，或者一段示例对话，能帮助在特定任务上引导模型。但为什么要把 prompt 单独做成一种能力呢？可以想想那些反复出现的模式，比如一个用来设定系统角色的 prompt，把角色设定为「你

是一名代码审查员」，然后把用户的代码插入进去供其分析。与其把这些硬编码在 Host 应用里，不如由 MCP Server 来提供它们。Prompts 也可以代表多轮工作流。举例来说，一个 prompt 可能定义了如何与用户进行一步步的诊断式访谈。通过 MCP 把这些暴露出来后，任何 Client 都可以按需检索并使用这些精心设计的 prompt。就控制权而言，Prompts 通常是由用户或开发者来把控的。用户可能会从界面上选择某个 prompt/模板（比如「总结这篇文档」模板），然后由 Host 从 Server 那里把它取回来。模型不会像使用 Tool 那样自发地决定使用 prompt；相反，prompt 是在模型开始生成之前，先把「舞台」搭建好。从这个意义上说，prompt 通常是在一次交互刚开始时，或者用户选择某个特定「模式」时才被取用的。假设我们有一个用于代码审查的 prompt 模板，MCP Server 里可能会这样写：

这个 prompt 函数返回的是一组消息对象的列表（采用 OpenAI 的格式），用来搭建代码审查的场景。当 Host 调用这个 prompt 时，会拿到这些消息，并可以把实际要审查的代码插入到 user 内容当中。

接着，Host 会在模型给出自己的回答之前，把这些消息提供给模型。本质上，Server 在这里帮忙把对话的结构搭建了起来。虽然我们个人目前还没见到太多这类能力的实际应用场景，但 prompt 能力常见的用例包括「头脑风暴指南」「一步步解题的模板」，或者特定领域的系统角色设定等。把它们放在 Server 上，就可以在不改动 Client 应用的情况下更新或改进它们，而不同的 Server 也可以提供各自专门的 prompt。这里有一点值得注意：作为一种能力，prompt 模糊了「数据」和「指令」之间的界限。它们代表的是 AI 可以使用的最佳实践或预设策略。从某种意义上说，MCP 的 prompt 有点像 ChatGPT 插件建议如何组织一次查询的方式，只不过在这里，这种方式是标准化的，并且可以通过协议被发现。