一、为什么需要 MCP？

我最近在做 AI Agent 或者基于大模型（LLM）的应用，我遇到一个很现实的问题：

模型很聪明，但它“什么都做不了”。

比如：

• 它不能直接访问数据库
• 不能调用你本地的代码
• 不能操作第三方 API
• 甚至连读取一个文件都需要你额外封装

于是，大多数开发者会选择一种方式：Function Calling（函数调用）

但问题来了

Function Calling 虽然能解决“调用工具”的问题，但它有明显缺陷：

• 每个项目都要自己定义函数格式
• 不同工具之间完全不统一
• 扩展一个新能力，需要改一堆代码
• 很难复用已有能力

再往前一点，你可能还用过类似 ChatGPT Plugins 的插件体系：

• 需要特定平台支持
• 接入复杂
• 生态割裂

👉 本质问题其实只有一个：

AI 没有一个统一的方式去“使用外部能力”

---

二、MCP 是什么？

MCP（Model Context Protocol），可以简单理解为：

一个让 AI 标准化调用外部工具的协议

它不是一个框架，也不是一个工具库，而是：

一套“约定”

就像：

• HTTP 让浏览器可以访问服务器
• REST API 让服务之间可以通信

👉 MCP 的作用是：

让 AI 可以“用同一种方式”连接任何工具

---

三、用一句话讲清 MCP

如果你只记住一句话，那就是：

MCP = AI 世界的“接口标准层”

它解决的不是“能力”，而是：

• 能力怎么接入
• 能力怎么被发现
• 能力怎么被调用

---

四、MCP 的核心角色

MCP 的设计其实很简单，只包含三个核心角色：

1. Client（客户端）

• 通常就是 LLM（大模型）这一侧
• 负责发起请求

你可以理解为：

“我想做一件事，有谁能帮我？”

---

2. Server（服务端）

• 提供能力的一方
• 对外暴露工具

比如：

• 一个天气查询服务
• 一个数据库查询接口
• 一个文件读取工具

---

3. Tool（工具）

• 真正执行任务的能力单元

比如：

• get_weather(city)
• query_db(sql)
• read_file(path)

---

五、一张图看懂 MCP

整个调用关系可以简化为：

LLM → MCP Client → MCP Server → Tool

流程非常直观：

1. LLM 想完成一个任务
2. Client 询问有哪些工具可用
3. Server 返回工具列表
4. LLM 选择一个 Tool
5. 发起调用并拿到结果

---

六、MCP vs Function Calling vs Plugin

很多人会问：

MCP 和 Function Calling 到底有什么区别？

直接看对比：

维度	MCP	Function Calling	Plugin
标准化	高	低	中
扩展性	强	弱	中
解耦	强	弱	中
复用性	高	低	中

核心差异一句话：

• Function Calling：你自己约定规则
• Plugin：平台帮你约定规则
• MCP：行业级统一规则

👉 所以：

MCP 不是更高级的工具，而是更底层的“连接方式”

---

七、MCP 能解决什么问题？

从实际开发角度看，MCP 解决了三类核心问题：

1. 工具接入混乱

以前：

• 每个工具一套接口
• 每个项目一套封装

现在：

所有工具统一用 MCP 接入

---

2. Agent 扩展困难

以前：

• 增加一个能力 = 改代码

现在：

增加一个 MCP Server 即可

---

3. 能力无法复用

以前：

• 一个工具只能在一个项目用

现在：

一个 MCP Server，可以被多个 Agent 使用

---

八、一个更现实的理解

如果你做过后端开发，可以这样类比：

• 数据库 → 提供数据
• API → 提供能力
• MCP → 提供“能力的统一入口”

👉 换句话说：

MCP 做的事情，本质是把“工具调用”这件事，变成像调用 API 一样标准

---

九、总结

最后用三句话收住：

1. AI 本身不会做事，它只是决策者
2. 真正做事的是外部工具（Tool）
3. MCP 让这些工具可以被标准化调用

👉 一句话总结：

MCP 是 AI 连接现实世界能力的“接口标准层”

---

下一篇我会深入一个核心问题：

👉 一次 MCP 工具调用到底发生了什么？（原理深度解析）

如果你只是“会用”，你很快会遇到瓶颈；
但如果你理解了原理，你就可以自己设计系统。

---