MCP （一）是什么？一文讲清 AI 如何连接现实世界

一、为什么需要 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

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

text 复制代码

LLM → MCP Client → MCP Server → Tool

流程非常直观：

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

六、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 一样标准

九、总结

最后用三句话收住：

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

👉 一句话总结：

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

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

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

如果你只是"会用"，你很快会遇到瓶颈；

但如果你理解了原理，你就可以自己设计系统。