今年 AI 圈最能“蹦跶”的概念，MCP 必须榜上有名。它火得街边烧烤摊老板都能跟你聊两句，营销号更是连夜三倍速开工，把 MCP 吹得跟仙人下凡似的。

但问题来了：

MCP 到底是啥？

你随便抓 10 个人问一嘴，能听到 8 种不同版本，还有 2 个人会激情演讲半小时，但讲完你依然不知道 MCP 到底是个啥。

为什么这么乱呢？主要是营销号把大家的脑子搅得跟过期黄泥一样，再加上 MCP 和 LLM、Agent、Function Calling 这些名字靠得太近，容易让人一不小心串戏。

今天，我们就用最朴素的方式，把 MCP 给你讲“明白明白”的那种。

目标：看完你能拍大腿说一句 ——

“哦，嗐，就这玩意儿啊。”

一、先从 Function Calling 开始：LLM 说话厉害，不会干活

大语言模型（LLM）有什么本事？

说白了：嘴皮子飞快，动手能力约等于 0。

例如：

你问 “今天北京气温是多少？”

它可以一本正经地瞎编。

因为它不能自己去查数据。

于是 OpenAI 给了它一根拐杖 —— Function Calling。

Function Calling 干啥？

简单讲：

1. 你提供一批工具（API、函数等）

2. LLM 不直接调用工具，它只是“写一条 JSON 指令”

3. 你的应用读懂后，自己真的去调用工具

4. 调完把结果塞回给 LLM

5. LLM 再给你答案

整个过程长这样：

用户问题 + 工具列表  
→ LLM 输出调用指令（JSON）  
→ 应用照指令调用真实工具  
→ 把结果再给 LLM  
→ LLM 输出答案  
→ 你看到结果

看着简单，但随着你的应用越来越复杂，问题就来了：

• 换 LLM 服务商？代码你得改

• 工具结构变了？代码你得改

• 新增工具？代码你得改

• 另一个项目想复用你的工具？重复造轮子，不改不行

你看，开发者每天不是在改代码，就是在去改代码的路上。

二、为什么需要 MCP：因为大家都不想写重复代码

当工具都绑死在应用代码里时，你就必须维护：

• LLM 怎么知道工具长啥样？

• 工具调用结果如何格式化？

• 新增工具怎么接？

• 别人写的工具怎么接？

于是有一天你心里突然闪现一个小灯泡：

“我为什么不把‘工具管理’这一坨玩意儿整个搬出去，搞成一个独立服务？”

这个服务负责：

• 列出我有哪些工具（API）

• 每个工具怎么用

• 我应用只负责告诉 LLM：“兄弟，工具在这儿，你自己挑。”

你恭喜自己，这个想法就是 MCP 的源头思想：

把“工具这一套”从 APP 里解耦出去，让工具开发跟应用开发拜拜。

注意！

MCP 和 LLM 没“直接关系”，它俩之间隔着你的应用（叫 host）。

MCP 不属于模型，也不属于 Agent，它就是：

“一个规范工具怎么暴露、怎么调用的协议。”

三、MCP 本质是什么？一句话：统一工具接口，让大家别乱写

MCP 的全称：Model Context Protocol。

这名取得跟玄学似的，让人以为：

• 和模型关系巨大

• 与上下文关系密切

• 高到不行的协议

结果你了解后会发现：

它就是一个用来“标准化工具调用”的协议。

不涉及魔法，不涉及灵性，不涉及炼丹。

它应该叫啥？

如果让我重新命名：

TCP：Tool Calling Protocol（工具调用协议）

是不是一秒钟就懂了？

（就是怕和真 TCP 打架，所以没敢这么叫。）

为什么 Anthropic 硬要叫 MCP？

因为工具的输入输出确实会进入模型的“上下文（context）”，他们就顺手蹭了个名字。

嗯……反正概念营销都这样。

四、所以 MCP 实际上长什么样？

MCP 做了一套标准封装，让所有人写出来的工具都能：

• 长得一样

• 用起来一样

• 被任何 MCP 客户端（你的应用）访问

技术栈大概是这样：

应用层：FastMCP（像 FastAPI 的亲戚）  
协议层：JSON-RPC 2.0  
传输层：stdio / SSE / HTTP  
网络层：asyncio + aiohttp

翻译成人话：

它就是：给 API 套了一套统一规格，让别人接你的工具不用写 adapter。

这玩意儿能火，是因为：

• 工具终于可以复用了

• Agent 应用不用再写奇怪的胶水代码

• AI 工具生态更容易形成

但营销号说的那些“LLM 获得双手双脚、MCP 将改写历史”就……

图都画得跟科幻电影一样。

五、MCP 怎么工作？这是它真正的流程

流程其实很朴素：

1、工具提供者 → 写 MCP Server

用 @mcp.tool 装饰器写几个工具函数，

它可以是：

• 本地脚本

• 远程 API

• 命令行

• 随便啥

MCP 框架会自动帮你变成“可被调用的 MCP Server”。

2、AI 应用 → 作为 MCP Client 连接 Server

应用连上 MCP Server，问：

“你有哪些工具？”

Server 给你返回一份“工具清单”。

3、AI 应用 → 把工具信息转成 LLM 的 function calling

整个过程像这样：

用户：

“查下北京天气，再告诉我该穿啥。”

流程：

1. 应用把用户问题 + 工具描述交给 LLM

2. LLM 说：“我需要调用天气工具”

3. 应用调用 MCP 天气工具 → 得到温度

4. LLM 说：“好，我再调用穿衣建议工具”

5. 应用执行并把结果喂回 LLM

6. LLM 输出最终答案

结果你看到：

“北京今天零下 10 度，建议你穿貂。”

注意：

MCP 只负责“工具和应用之间”这一段。

LLM 和应用之间的“多轮互动” MCP 负责不了。

这部分工作要：

• 应用自己写逻辑

• 或者用 Agent 框架来“代劳”

六、总结一句话：MCP 不是神，只是一个很有用的工具标准

看完你应该能明白：

• MCP ≠ LLM

• MCP ≠ Agent

• MCP 也不让模型自动干活

• MCP 只是一个**“统一外部工具接口的协议”**

它做的是：

让所有工具像插头一样标准化，大家互相能插上，不用天天焊电线。

这对 AI 应用开发者来说确实是个利好。