关键词：MCP、Model Context Protocol、Tool、Resource、Prompt、Python、FastMCP、AI Agent、Claude Desktop、Cursor

前面的几篇文章，我们已经完成了：

• 什么是MCP

• 第一个MCP Server开发

• Cursor接入MCP

• Claude Desktop接入MCP

很多同学已经可以开发自己的MCP工具了。

但是新的问题又来了：

为什么AI能够自动知道什么时候调用Tool？

Resource到底是什么？

Prompt为什么也是MCP协议的一部分？

其实，这三个能力正是MCP协议最核心的设计思想。

今天，我们直接站在协议源码的角度，一次讲透MCP最重要的三个概念。

一、MCP协议到底提供了什么？

很多人认为：

MCP就是：

Tool调用协议。

实际上并不是。

官方协议主要定义了三类能力：

MCP ┌──────────────┐ │ Tool │ │ Resource │ │ Prompt │ └──────────────┘

它们分别解决不同的问题。

可以理解成：

Tool 负责做事情 ↓ Resource 负责提供资料 ↓ Prompt 负责组织工作方式

三者共同组成了完整的AI工具生态。

二、Tool：让AI真正拥有执行能力

Tool可以理解成：

AI可以调用的函数。

例如：

Python里面：

def weather(city): return "晴天"

加上：

@app.tool()

以后。

它就变成：

AI Tool

协议里面。

它实际上长这样：

{ "name": "weather", "description": "查询城市天气", "inputSchema": { "type": "object", "properties": { "city": { "type": "string" } } } }

注意几个重点：

Tool Name Description Input Schema

AI真正看的。

其实不是Python代码。

而是：

这一段描述。

为什么Description特别重要？

例如：

工具：

@app.tool() def abc(a):

AI根本不知道：

abc

什么意思。

但是：

@app.tool() def query_weather(city): """ 查询指定城市天气 """

AI马上知道：

什么时候应该调用。

所以。

好的Tool描述。

往往比代码更重要。

实践建议：Tool名称使用动词+对象（如query_weather、create_order），Description明确说明用途、适用场景和返回结果，可以显著提高模型正确调用工具的概率。

三、Tool为什么能够自动调用？

很多人误以为：

AI自己决定。

实际上。

流程如下：

用户： 北京今天多少度？ ↓ LLM分析 ↓ 发现： Weather Tool Description： 查询天气 ↓ 生成调用： weather("北京") ↓ MCP Server执行 ↓ 返回JSON ↓ AI整理回答

所以：

真正起作用的是：

Tool Metadata

不是Python代码。

四、Resource：AI为什么能够读取文件？

很多人第一次看到：

Resource。

都会疑惑。

为什么Tool不能直接读文件？

答案是：

可以。

但是：

Tool负责：

执行动作

而：

Resource负责：

提供内容

例如：

项目里面：

README.md design.pdf config.yaml schema.sql api.md

这些：

不是函数。

而是：

资源。

MCP里面：

可以注册：

Project Resource

以后。

AI能够：

阅读整个项目说明。

例如：

用户：

这个项目是干什么的？

AI：

↓ 读取README ↓ 总结内容 ↓ 回答用户

而不是：

调用Tool。

五、Resource的源码设计

Resource通常包含：

{ "uri":"file://README.md", "name":"README", "mimeType":"text/markdown" }

主要包含：

URI Name MIME Type

例如：

image/png text/plain application/pdf text/markdown

AI就知道：

如何解析。

六、Tool与Resource最大的区别

很多新人最容易混淆。

举一个例子。

假设：

企业知识库。

Tool：

search_document()

负责：

搜索。

而：

Resource：

员工手册.pdf

负责：

提供内容。

所以：

Tool：

会执行

Resource：

不会执行

只提供：

数据。

下面是一个简单对比：

七、Prompt为什么也是协议的一部分？

很多人第一次看到：

Prompt。

都会觉得：

不就是提示词吗？

其实。

不是。

MCP里的Prompt。

更像：

工作模板。

例如：

企业里面：

每天都需要：

生成日报 生成周报 Code Review SQL优化 接口文档 会议纪要

以前。

每个人：

复制Prompt。

现在：

直接：

注册。

例如：

Review Code

以后。

AI：

直接调用。

无需复制。

八、Prompt源码结构

协议里面：

一个Prompt。

通常类似：

{ "name":"review_code", "description":"代码审查", "arguments":[ { "name":"language" } ] }

例如：

用户：

帮我Review下面Python代码。

AI：

↓ 发现： review_code ↓ 填充参数 ↓ 执行Prompt ↓ 得到结果

整个过程：

自动完成。

理解方式：Prompt并不是替代Tool，而是帮助模型组织任务。一个Prompt可以引导AI在合适的时候调用多个Tool，再将结果整合输出。

九、为什么MCP设计成三种能力？

假设：

开发：

企业ERP。

以前。

所有东西：

都是Tool。

越来越多。

越来越乱。

而现在：

可以拆分：

ERP MCP ├── Tool │ 查询订单 │ 创建订单 │ 修改库存 │ ├── Resource │ ERP说明书 │ 数据字典 │ API文档 │ └── Prompt 周报模板 SQL分析模板 财务分析模板

职责一下清晰了。

这就是：

MCP最大的设计思想：

能力（Tool）、知识（Resource）和流程（Prompt）相互解耦。

十、企业开发中如何合理使用三种能力？

很多团队在设计MCP Server时，都会面临一个问题：

一个功能，到底应该设计成Tool、Resource还是Prompt？

可以参考下面的原则：

适合设计为Tool

• 查询订单

• 创建工单

• 调用ERP接口

• 查询数据库

• 发送邮件

• 上传文件

特点：需要执行操作或调用外部系统。

适合设计为Resource

• 项目README

• 数据库Schema

• 产品说明书

• API接口文档

• 企业制度

• 知识库文档

特点：主要提供内容供AI阅读和引用。

适合设计为Prompt

• Code Review模板

• 周报生成模板

• SQL优化模板

• 测试用例生成模板

• 产品需求分析模板

特点：提供标准化的工作流程或提示模板。

十一、三者协同工作的完整案例

假设开发一个企业AI助手。

用户输入：

分析本月销售情况，并生成管理层汇报。

后台可能经历这样的流程：

用户提问 ↓ Prompt "销售分析报告" ↓ Tool query_sales() ↓ Tool query_customer() ↓ Resource 销售指标说明.md ↓ AI整理分析 ↓ 输出完整汇报

整个过程中：

• Prompt负责定义分析框架和输出格式。

• Tool负责获取实时业务数据。

• Resource提供业务规则、指标定义等背景知识。

三者各司其职，共同完成一次复杂任务。

总结

MCP并不是一个简单的"工具调用协议"，而是一套围绕AI Agent设计的标准化能力体系。

它通过三个核心能力，将AI与业务系统有效连接：

这种设计带来的最大优势在于：

• 职责清晰：执行、知识和流程彼此独立，易于维护。

• 复用能力强：同一个Prompt可以调用多个Tool，同一个Resource也能服务多个Prompt。

• 更适合企业级AI Agent：便于构建复杂工作流，支持团队协作和持续扩展。

当你真正理解了Tool、Resource和Prompt的定位，就会发现：MCP不仅是一套协议，更是一种面向AI时代的软件架构思想。

本文知识点回顾

✅ Tool的协议结构与自动发现机制
✅ Resource的设计理念与应用场景
✅ Prompt的作用与复用方式
✅ Tool、Resource、Prompt三者区别
✅ 企业级MCP Server设计思路
✅ AI Agent完整工具调用流程