MCP 到底是个什么鬼？

[pmpmp]

盘点今年最火的 AI 概念，MCP 必须算是一个，这家伙来势汹汹，各路营销号更是加班加点推波助澜，可是，静下心来想一想，我们真的知道 MCP 是个什么东西么？很多人可能并不是很清楚，只有一个模糊的印象：这玩意好像是让 LLM/Agent 拥有调用外部工具能力的一种...东西吧...

不信你去问问周围的人，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 代码里,所以:

1. 换 LLM 供应商了?可能要改代码吧？虽然多数 LLM 供应商都支持 openai 的标准,但是也有不一样的,比如 Google 的 Gemini 用 "Function Declaration",Anthropic 用 "Tool use"
2. 工具逻辑/参数变了?你得改代码吧?因为你得维护传给 LLM 的工具参数嘛(名字+工具描述+参数)
3. 想加新工具?你还得改代码并重新部署吧?
4. 其他项目想复用你的工具,你做过的所有事情,他也得来一遍吧?

二、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 服务，上面有几种接口：

• listing 服务接口：负责维护所有支持的工具的 API 的描述
• 具体的工具接口：负责调用各种外部的 API 、函数、命令行等等，再弄一个标准的返回结构

一切都非常的丝滑,你的 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 它是怎么工作的呢?大致上,分成这么几个步骤:

1. MCP-Server ，就是工具提供者，使用 mcp 的标准，借助 mcp 框架写一个 server ，server 这个名字我也想吐槽一下，总给人感觉它是一种需要启动起来的“远程服务”，其实它可以是一个远程的服务，也可以是一个本地的代码（当然也会被 mcp 框架偷偷的“启动起来”）
2. APP ，也就是工具的调用者，使用 mcp 的标准，用 MCP-Client 先连接上 mcp server ，询问它有哪些具体的工具可以使用，mcp server 就会返回一个清单
3. APP ，将工具信息按需乖乖的处理成 LLM 的 function calling 等参数，加上 Message ，开始和 LLM 进行对话，对话的流程是这样的：

用户发出：帮我查一下北京天气，然后推荐适合的穿衣搭配
    ↓
第 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 的应用还有很多问题业界也都在探索解决，典型的比如：

• 工具路由：如何把“对的工具”在“对的时间”给到“对的 LLM”？
• 调试和可观测：工具调用特别多的时候，如何排查问题？是工具的问题还是 LLM 的问题？
• 生态碎片化：表面上好像有了很多的 mcp 服务，但是谁为质量负责呢？ mcp 的生态能否形成利益的正循环？

MCP 才刚刚开始，MCP 确实是为 AI 的世界定义了“USB 协议”，让工具的即插即用成为了可能。但协议之上，“电脑主板厂商”（ AI 应用/Agent 编程框架）的适配度够么？ USB 的“外设”（各种 MCP Server ）足够丰富、健壮、易用么？生态会持续的形成良性循环么？考验才刚刚开始，至少，从目前看来，有一说一，一般。

以上，全文。

[chenluo0429]

可以看一下 MCP 的具体介绍和实现规范，除了 tools 以外，还有 resources 和 prompts 的，这也是为什么叫做 MCP 而不是 Tool 什么的原因。只是 mcp server 实现这些东西的比较少见而已

https://modelcontextprotocol.io/docs/learn/server-concepts

[bigant071]

学会了，谢谢 pp 老师

[zsc8917zsc]

感觉 OP ，非常有用

[coefu]

mcp 有一说一，确实一般。

[pmpmp]

@chenluo0429 MCP 在设计上是希望解耦 LLM 的所有依赖的，比如 resource 本质上是为了解耦上下文、prompt 是为了解耦输入，tool 是为了解耦工具调用，但是说实话，我个人感觉 resource 、prompt 这两个的设计有点远了，等工程复杂到一定程度，且，那时候 MCP 还活着的话，兴许会有用，现在，感觉是鸡肋的多数，实践上也很少听到用这个的

[canteon]

我觉得这个不能偷懒

[clemente]

ppt 工程师的兴奋点, 实际是鸡肋的东西

[clemente]

还有 rag , 随着模型本身的能力突破 rag 这种丑陋的胶水层 会被淘汰

[irrigate2554]

@chenluo0429 Resources 和 Prompts 隐含到 Tools 内了，比如 Resources 其实就是不会改东西的只读 Tools ，Prompts 就是教大模型怎么使用这个 Tools 的文档。

[avonhermit]

我有个问题，比如 copilot/cursor 对代码进行了修改，那“修改代码”的这个行为是通过 MCP 实现的吗？

[zisen]

github copilot 对话框旁边有个 mcp 按钮，但是我从来没用过，感觉日常开发只需要对话就够了。
MCP 想要发展起来，还是需要一个强而有力的推动者，用 mcp 搞出来一个无法替代又不能不用的东西，就好比 iPhone air 推动 esim 的发展，类似的还有 ipv6 这种技术

[pmpmp]

@avonhermit 这个不知道，修改代码/编辑文档这种事情大概率肯定是一个 Agent ，不过把 Agent 包到一个 MCP 里面去作为一个远程服务也有可能，毕竟可以不依赖本地软件升级，热更新 Agent 什么的也更方便

[sherlockwoo]

感谢 OP ，也是理清了一些思路

[RotkPPP]

我确实也有点想不明白，还望求解。

MCP 的生态位是不是不可替代的，我在开发 agent 的时候，或者是使用 agent 的时候，不论是单 agent 还是 multi agent ，也在思考是不是真的有用。但实践和日常使用中，我真正用到 mcp 的很少，而且当 mcp 相关内容一多，对上下文也是一种挤压。所以很多人都说，做 mcp 的人比用的人的还多。

所以有些地方想的不太明白。什么时候用 mcp 是不可替代的，或者是效果更好。mcp 对 agent 或者是 llm 的使用效果的上限到底在哪。

[jybox]

@RotkPPP 当你是 Agent 开发者的时候，MCP 自然没什么吸引力，MCP 是给没有开发能力、不想写代码的情况用的

[jsq2627]

@clemente 认同。

而且随着模型能力提升，最终能留下来的搞 agentic AI 的厂商只有模型厂自己。claude code 、openai codex 大杀四方逐渐在证明这一点。

[pmpmp]

@RotkPPP 有用还是有用的，只不过有一个很大的问题：太麻烦了。
如果是简单的应用，其实完全没必要 MCP ，属于过度设计了，会引入很多不必要的复杂性；如果是复杂的应用，另当别论，不用 MCP 也得想其他办法。

其实不一定要纠结是不是 MCP ，只要能让 LLM 丝滑的使用工具（一个函数、一个对象、一个远程服务），都可以，毕竟让 LLM 原生的使用工具总比我们自己写控制逻辑要方便多了（当然也有风险，都是两面性的），这就是最大的好处，当然过程中慢慢肯定会涉及到工具过滤、结果校验等等一堆工程上的事情，这是必不可少的，小的时候一般不必纠结。

chak 这几天会做一个更新，让 mcp 这事变成一个可选项，而不是必选项，一个函数、一个 object ，都可以传给 llm 让它调用，不必那么复杂的搞一个 server ，太麻烦了，大家帮忙关注下，帮我点个 star 啊，哈哈哈哈，感谢感谢🙏

https://github.com/zhixiangxue/chak-ai

[youyouzi]

叽里呱啦说一大堆：

ai 就是手，mcp 就是不同的工具；

手拿起扳手，就可以拧螺丝

手拿起筷子，就能吃饭

你不能不通过扳手拧螺丝，也不能不用筷子吃火锅；

[hhhhkkk]

@avonhermit mcp 更多的是“协议”，是理论。 只要修改文件的实际执行器集成了这个协议，符合 C/S 架构，那就可以理解为是 MCP 。 按照我理解的 mcp 大抵是这个意思。

[kneo]

你这 90%内容都是 AI 写的吧。

[j8sec]

Master control program.
主控程序。

[Jabin]

太赞了👍

[renmu]

如果用户问了"帮我查一下北京天气，然后推荐适合的穿衣搭配"，但 server 支持查天气不支持查搭配，这时候会出现幻觉吗？

如果一个函数需要五个参数，但是只读到两个参数会怎么处理

[kinist]

认真阅读，好好学习了下。

[pmpmp]

@renmu 不会，LLM 会要求调用查天气的，然后 app 调用后作为 prompt 再给 LLM 推理；如果 LLM 给出的 toolcall 的参数不全，就看工具本身返回什么了，一般挂了的话 app 要自己处理，然后再给 LLM 的； APP 在这个过程中的作用很关键，是一个桥接，LLM 不会直接 call MCP server 的

[SayHelloHi]

有个问题 请教一下

比如问 AI：今天苹果的股票，使用股票 k 线图显示

AI 如何使用 K 线组件

它咋知道 K 线组件要的数据类型

[pmpmp]

@SayHelloHi 千万别把这事想复杂了，你应该定义一个工具比如就叫 drawk ，就一个参数，stock_code ，llm 知道传 APPL ，剩下的怎么拿数据、怎么画图都是这个工具内部的逻辑

[FFM]

股票查询这种直接调 pip 包 yfinance 就行了。其实 codex 本身就是个最大的 mcp ，因为他直接在一个 linux 里面，你用 linux 能做的他都能做。

[liyafe1997]

@SayHelloHi
「 AI 如何使用 K 线组件，它咋知道 K 线组件要的数据类型」
很简单，这可以是 System prompt 的一部分。

ChatGPT 不只是一个模型，而是 GPT5 模型 + 一套强大的 Agent/MCP
在 ChatGPT 上对话能做的事情和功能比直接用 API 调 GPT5 模型要多得多。API 调的就只是 LLM 模型本身而已。

[yplam]

@SayHelloHi 如果是实现可交互的 K 线图组件而非静态图片，可以看看 Google 家的 A2A 、A2UI ，大概是客户端描述本地 UI 组件需要的响应数据结构，服务端按格式返回，然后本地 UI 渲染

[Lockroach]

mcp 似乎逐渐被 a 社抛弃了。另外使用 mcp 会导致 mcp 工具和用户竞争 model context 的情况。加载一个 github mcp 就有 90 多个 mcp schema 加载了。了解一下原理还行。