不信你去问问周围的人，1000 个人的心中可能至少有 800 个 MCP 的版本... 而且，多数可能都是似是而非的、模糊的，甚至是错误的。
之所以这么混乱，是因为乌七八糟的营销号看多了，哦不，是因为没理顺 MCP 和这几个东西之间的关系：LLM 、Agent （含各种 agent 框架）、Function calling
如果你非常清晰，这篇文章其实就不需要看了，否则，看完这篇文章你大概率会神清气爽：哦，就这啊！
要理解 MCP,我们要问自己一些非常朴素的问题:为什么会有 MCP?它是在什么背景下出现的?没有有它会怎么样?有了它又怎么样?怎么用呢?用了之后有什么好处?
一、从 Function Calling 说起
别急,我们从 function calling 开始说起
大语言模型（ LLM ）本身只能“耍嘴皮子”——生成文本，无法直接“动手”调用外部的工具解决一些实际问题（比如一些实时数据查询、数学计算等），所以 openai 在发布 gpt-4-turbo 时推出了 Function Calling 的能力，注意，它不是真的 call 了什么 function ，而是让模型可以生成结构化的调用指令（ JSON ），什么意思呢，大致是这样的一个过程：
用户提问+工具列表 → LLM 返回工具调用指令（如需） → 应用根据 LLM 的指令实际调用工具 → 结果再传给 LLM → LLM 返回最终答案 → 用户看到结果
这个流程里面没有 MCP 啥事，也还没有出现什么 MCP 。
你说，这不是很简单么，我的应用程序就按照这个流程写代码就行了，也没多少行代码啊。
当然,简单的应用不会有什么问题,就这么玩很丝滑,但是一旦你的应用变的复杂了,工具变得多了,问题就慢慢来了,由于工具逻辑写在你的 App 代码里,所以:
[ol]
[/ol]
二、MCP 的思想
总而言之,只要工具维护在你的应用程序里面,和 LLM 交互的这一整套来来回回的流程都得你自己维护。很自然的,你就会想办法把工具的这套东西独立出来,一个朴素而基本的思想是这样的:
为什么不搞一个独立的服务，就类似于一个 api 的服务，我应用程序通过这个 api 服务来 list 工具，然后我只要把这些传给 LLM 就行了，执行的时候，我也 call api 来真正调用工具。
恭喜你，其实这就是 mcp 思想的本质：某种服务 ↔ AI 应用 ↔ LLM 。你看，其实就是解耦，平淡无奇。
注意，到这里你应该已经发现了：“某种服务”和 LLM 并没有直接的关系，说白了，MCP 和 LLM 其实没有任何的直接关系，MCP 不是直接为 LLM 服务的，LLM 也对 MCP 没有任何的感知，桥接这两者的实际上是你的应用程序（ MCP 的文档里面的 HOST 指的就是应用程序，比如 Claude 这样的 app ，或者你自己开发的 agentic APP ）
接下来，你可能就真的这么做了，搞了一个 http 服务，上面有几种接口：
一切都非常的丝滑,你的 APP 终于不需要耦合工具了,舒服,直到有一天...你发现隔壁老王也搞了一个类似的工具集,你一看，他的工具也不错啊,你也想接进来用,于是你的 APP 代码开始出现坏味道了,又开始写了一堆的 adapter 代码,久而久之,这和原来在 APP 内维护工具的做法有什么区别呢?没有任何区别啊,你又走回了老路...
这时候,你就开始想了:谁要是能把 adapter 这个事情给统一了该多好,让工具的开发者都在同一个框架下开发并维护工具,这样接口都是统一的,不就不需要写那么多适配器代码了么?
三、MCP 的本质
恭喜你,这就是 MCP 干的事情。
MCP 这个名字起的真的是一言难尽： Model Context Protocol，乍一看，模型上下文协议，你肯定会想，跟模型有关系、还跟上下文有关系，还是个协议，结果你看了半天，它是个搞工具调用的，你就自我怀疑了：他跟模型好像没有产生直接关系啊？它跟上下文也没有产生直接关系啊？顶多算是个间接关系、远房亲戚吧？不不不，这么厉害的东西不会这么简单的，是不是我理解错了？
其实你理解的一点都没错，事实就是：MCP 这名字起的确实是华而不实、牵强附会、硬蹭热点、假装高级，一股制造概念的营销骚气。要我看啊，给它改一个名字，你就秒懂了，叫它 TCP （ Tool Calling Protocol ，工具调用协议），你看，多精准。
其实可以站在 Anthropic 角度解释下它的起名逻辑：由于工具调用及其结果会被纳入到 LLM Model 的对话上下文（ Context ）中，从而影响后续的对话，而且确实它是一种应用层的用于交换数据的协议（ Protocol ），所以，叫它 MCP ，有什么毛病嘛？！呵~呵~🙂，你开心就好~
本质上 MCP 就是定义了一个远程工具调用的“应用层协议”，是一个应用层的通讯标准/约定，所以你看他的技术栈就明白了：
应用层: FastMCP 装饰器 (@mcp.tool, @mcp.resource)
↓
协议层: JSON-RPC 2.0 消息格式
↓
传输层: stdio/sse/streamable-http (三选一)
↓
网络层: asyncio + aiohttp/标准 IO
你看，他其实就是在应用层做了一些封装和创新，以达到：让任何人写出来的 Tool-Service （就是 MCP server ）能够被其他人的 Tool-Client （就是 MCP client ）调用，而调用方无需写很多乱七八糟的胶水代码。就这么朴实无华。你他看它官方编程框架里面的名字是不是都无比眼熟，fastMCP ，是不是感觉到 fastAPI 那股子熟悉感？我猜官方 FastMCP 可能也是借鉴了 FastAPI 的设计理念和实现方式吧（我印象中 fastapi 的 fastMCP 是先出来的），本质就是给 API 套了一层马甲（约定了输入输出等微创新，当然 mcp 也支持本地 stdio 啦），仅此而已。
结果很多营销号连基本原理都没搞清楚，就被 Anthropic 带着节奏跑，山呼海啸：震惊，LLM 长出手脚来了，可以干活了，Agent 市场要翻天覆地了！ MCP 王炸！
图画的一个比一个抽象,解释的一个比一个魔幻...
当然了,这一波炒作下来也不是什么坏事,确实有很多 API 被"标准化"了,给 LLM 应用开发者带来了不少的便利。
四、MCP 是如何工作的?
MCP 它是怎么工作的呢?大致上,分成这么几个步骤:
[ol]
[/ol]
用户发出：帮我查一下北京天气，然后推荐适合的穿衣搭配
↓
第 1 轮：APP 将 Message + function calling 参数发送给 LLM
↓
第 2 轮：LLM 返回天气查询工具调用的指令
↓
第 3 轮：APP 使用 mcp-client 调用天气查询，返回温度数据，再把这个数据发送给 LLM
↓
第 4 轮：LLM 分析温度后，返回穿衣推荐工具调用的指令
↓
第 5 轮：APP 使用 mcp-client 调用穿衣推荐工具，再把这个数据发送给 LLM
↓
第 6 轮：LLM 返回最终答案
↓
用户收到：今天的气温是零下 10 度，建议你穿貂
你看，MCP 它只把事情做了一半，剩下的另一半还得应用开发者自己做，什么意思呢，在这个流程里面
MCP-Server ↔ AI 应用（ MCP-Client ） ↔ LLM
AI 应用(MCP-Client)和 LLM 的交互的过程并不是 MCP 能覆盖到的,AI 应用和 LLM 实际上要经过多轮的来来回回交互才能获得最终的结果,这个事情还是得应用开发者自己维护,好在,一些 agent 框架也在这里做了不少工作,帮助开发者简化了这个流程,让开发者感觉到一种错觉:LLM 和 MCP-Server 之间是互联互通的。这是好事,毕竟,应用的开发者应该专注于应用逻辑的开发,而不是跟底层的这些通讯机制死磕。
好啦,这就是 MCP 真实的原本的样子,希望看完这篇文章,可以让你对 MCP 祛魅,也理顺 MCP 和 LLM 、Agent （含各种 agent 框架）、Function calling 之间的关系。
五、如何使用 MCP?
理解了 MCP 的本质后,你可能会想,有没有一个现成的框架能让我快速上手,避免重复造轮子呢?有一部分的 LLM 应用的编程框架已经集成了。
这里我为自己开发的 Chak 项目做个推广哈，我开发了一个极简风格的 LLM chat sdk —— Chak
🚀 *GitHub: https://github.com/zhixiangxue/chak-ai*
它是一个极简的多模型 LLM 客户端，内置了上下文管理和工具调用，极简，开箱即用。
使用 Chak ，你无需关心 mcp 各种花里胡啥的实现和概念，你只需要 2 步就能让你的 llm 拥有调用工具的能力，一切都是透明的：
from chak import Conversation
from chak.mcp import Server
# 从 MCP 服务器加载工具（可以筛选工具）
tools = await Server(url="...").tools()
# 把工具和 LLM 关联起来，剩下的，你就专注于收发消息就行了
conv = Conversation("openai/gpt-4o", tools=tools)
response = await conv.asend("What's the weather in San Francisco?")
这里我写了很多的例子，注释很详细，动手运行一遍，保证你秒懂： https://github.com/zhixiangxue/chak-ai/tree/main/examples
当然，如果你有兴趣可以看下源码，看看 chak 是如何利用 mcp 调用工具&协调 LLM 工作的。欢迎提 issue ，欢迎交流，更欢迎贡献~
六、最后
MCP 的应用还有很多问题业界也都在探索解决，典型的比如：
MCP 才刚刚开始，MCP 确实是为 AI 的世界定义了“USB 协议”，让工具的即插即用成为了可能。但协议之上，“电脑主板厂商”（ AI 应用/Agent 编程框架）的适配度够么？ USB 的“外设”（各种 MCP Server ）足够丰富、健壮、易用么？生态会持续的形成良性循环么？考验才刚刚开始，至少，从目前看来，有一说一，一般。
以上，全文。
