当下，AI 领域最炙手可热的概念莫过于 MCP。随着全球开发者对 Agent 技术的热情空前高涨，MCP 一跃成为 AI 生态中的“底层标准”，也逐渐成为业内讨论的焦点之一。
最近我也开始尝试将业务中的一些能力通过 MCP Server 的方式暴露出来，供大模型调用。初步实践下来效果还不错，甚至让我一度动了“重构网关，把所有服务都暴露成 MCP”的念头。毕竟谁能拒绝一个“全能助理”在你业务上自由驰骋的画面呢？
不过很快我发现：你以为自己是在对接 API，实际可能是在和大模型谈恋爱 —— 你说的，它未必懂；它懂了，也未必照做。
所以在真正行动之前，我想结合自己的开发体验，聊聊 MCP 和 function call 到底有什么不同，大模型是如何知道 MCP Tool 是干什么的，以及目前 MCP 生态中存在的一些“不成熟”现象。
一些关于 MCP 的一些体验与思考
1、function call 与 MCP 的联系与区别
MCP 推出之后，不少人误以为它是对传统 function call 机制的一种替代。但实际上，function call 和 MCP 是两个不同层面的概念，它们并不是此消彼长的关系，而是彼此协作、紧密配合的。
Function Call 是大模型与外部工具或 API 交互的“能力本体”。它让模型能判断是否需要使用工具、该用哪个工具，并正确地调用 —— 也就是说，它解决的是“工具怎么调用”的问题。
MCP 更像是一个“工具生态的标准化容器”：它定义了如何管理工具、如何暴露服务、如何实现复用，提供的是一套统一的接口规范。它解决的是“工具如何被组织、共享和复用”的问题。
在底层，MCP 实际仍然依赖 function call 来完成工具调用。可以这么理解：function call 是能力，MCP 是协议与生态。一个不支持 function call 的模型，是无法使用 MCP 的；反过来，有了 function call，不一定就具备了 MCP 的工具管理能力。
所以与其说 MCP 是“取代”了 function call，不如说它是在 function call 之上，搭建了一个更通用、可复用的交互标准。它把原本“手工打 API 工具包”的工作，变成了标准化集成开发的方式。类比来说，function call 是插座接口，而 MCP 是整套电力布线和电器管理系统。插座能用，不代表电网有序；MCP 想运转，也得靠插座供电。
2、MCP Host 到底是如何将工具告诉模型的？
在 MCP 协议中，MCP Host（例如 Claude Desktop）扮演着一个关键角色：它既要通过 MCP Client 从 MCP Server 获取 Tool 的定义，又要将这些工具“介绍”给大模型使用；而在大模型发出调用指令时，它还需要负责请求对应的 MCP Server 执行实际调用。
但问题来了 —— Host 是如何把这些工具的“使用说明书”交给大模型的？ 遗憾的是，MCP 协议本身并没有对此做出明确规定。
实际上，根据当前各平台的实现，常见有两种方式：
✅ 方式一：通过 Tools 参数传递（主流、结构化）
目前主流的大模型 API（如 OpenAI ChatGPT、Anthropic Claude、阿里 Qwen 等）都支持一个专门的 tools 参数。MCP Host 会将从 MCP Server 获取到的 Tool 描述，转换成各模型 API 所要求的格式（例如 OpenAI 的 JSON Schema、Claude 的 function signature 等），然后通过该参数传递给模型。
这种方式的优势在于：
- 结构清晰，格式规范
- 控制粒度高，易于调试
- 更符合模型设计初衷，调用更稳定
简单来说，这是目前最通用、最可靠的方式。
⚠️ 方式二：通过 Prompt 注入（非主流、风险高）
在一些特殊场景下，工具描述也可能被直接拼接进 Prompt 中传递给模型 —— 比如社区用户抓包分析 cline 请求时就发现，某些工具定义是以纯文本形式“注入”到 prompt 中的。
出现这种做法的常见原因有：
- 当前模型 API 不支持独立的 tools 参数（如某些早期模型或自研大模型）
- 想补充一些额外的上下文信息（如示例用法、调用期望等）
但这种方式存在明显的安全隐患，比如可能被恶意构造的 prompt 破坏调用逻辑，触发所谓的“Prompt 注入攻击”。同时它也增加了 prompt 长度成本，并降低了调用结果的稳定性。
因此可以看出，虽然 MCP 协议没有强制 Host 采用哪种传递方式，但在实际落地中，结构化工具参数 + 明确工具 schema 的方式，已成为主流 Host 的标准实现路径。
3、通过 Tools 参数和 Prompt 注入两种方式的本质区别与联系
不管是通过 tools 参数，还是通过 prompt 注入，从模型底层的角度看，最终的处理方式其实殊途同归 —— 都会被转换成一串文本输入给大模型。因为，大语言模型的本质就是一个“根据输入文本预测输出文本 ”的神经网络系统：
- 输入：被分词器（tokenizer）编码后的文本序列
- 处理：通过 Transformer 架构做序列建模和 token 预测
- 输出：下一个 token 的概率分布，并选择高概率 token 输出
所以，无论我们给它的是结构化的 tools 参数，还是拼接好的 prompt 字符串，它最终都要“读成文本”来理解工具内容。tools 参数的优势更多体现在接口设计上：它是为了让开发者方便组织和提交工具信息，结构更清晰、机器更容易处理。实际上，很多模型厂商（如 OpenAI 和 Anthropic）内部会把 tools 参数转换成紧凑的内部表示，再嵌入到模型输入中，并可能在训练阶段对工具格式做过针对性优化。
因此从 推理成本 来看，二者并无本质差别，甚至结构化方式还有可能更节省 token。
但无论使用哪种方式，对 MCP Tool 开发者而言，最重要的事情始终是：写好工具的描述。
一个好的工具描述，应该清晰传达工具的用途、输入输出参数、使用场景等关键信息。模型需要依赖这些内容来判断是否使用工具、使用哪个工具、传什么参数。
正如 Anthropic 在一篇关于开发多智能体系统的研究中所强调的：糟糕的工具描述不仅会让模型产生误解，甚至可能导致整****个智能体行为方向跑偏。
同样，对 Agent 开发者来说也有一个容易忽视的陷阱：工具越多，未必越好。
因为每个 Tool 的描述都会被编码进模型的输入序列，工具越多，输入文本就越长，而 Transformer 架构的注意力机制是“有长度限制”的 —— 当输入超出模型的关注范围时，它可能根本没读到后面的 Tool 定义，或者只记住了开头几个，导致工具调用能力下降、理解失误频发。
所以，合理控制 MCP Tool 的数量、长度与精度，是提升智能体效果的关键一环。
4、大厂为什么给 Tools 描述“白嫖”额度？
在使用大模型 API 的过程中，有个细节常常被开发者忽略 —— 当我们通过 tools 参数传递 MCP Server 的工具描述时，这些内容有时并不会计入 token 费用，或者只按****照更低的费率计算。
那么问题来了：大模型处理这些内容明明也是“读文本”，为什么这部分****不怎么收费？
其实这里面的考量，既有技术实现上的差异，也有平台方精心设计过的商业策略：
✅ 1. 布局生态：推动标准化工具体系
各大模型厂商（如 OpenAI、Anthropic）都在构建以自身为中心的“Agent 工具生态”。
为了吸引开发者使用官方标准（比如 tools 参数、MCP 协议），而不是自定义 prompt hacking 方式，自然会在计费策略上给予倾斜。
这种鼓励政策可以促使更多开发者以“平台认同的方式”构建能力，从而让整个工具生态更加统一、规范、可控。
✅ 2. 降低门槛：提升工具功能的使用率
工具功能是大模型从“聊天机器人”向“智能体”演进的关键一环。
如果每试一个工具就要为冗长的描述付出高昂 token 成本，那么开发者的使用意愿无疑会大打折扣。
因此，不计费或低费率，是为了让开发者更自由地实验工具组合、试错设计、快速迭代。
尤其是 MCP 模式下，一个服务往往会包含多个工具，如果每个都计费，很容易劝退开发者。
✅ 3. 实际成本低：标准化数据处理更高效
从模型运行层面看，tools 描述往往采用统一结构，在模型的底层输入处理中可以使用优化后的编码方式，比自由文本 prompt 更易压缩、更快处理。
换句话说：即使模型看起来在“读工具说明书”，其实它的“阅读成本”远低于处理你随手写的 prompt。
对平台来说，这部分的边际成本并不高，完全可以承担。
✅ 4. 数据价值大：反向用于模型优化
最后还有一点经常被忽略：这些工具描述本身也是训练数据的宝库。
平台可以通过观察开发者如何组织 tool、模型如何理解 tool、调用是否成功等信息，持续优化其模型行为与工具系统。
在这个角度看，平台甚至愿意“贴钱买数据”。
看似慷慨的计费政策，背后其实是一次精密的生态运营与****商业博弈。 越来越多 MCP Server 被挂载上线，不仅丰富了模型能力，也推动了 Agent 生态的标准化与专业化。
5、MCP 还不成熟，但未来可期
🛠 后端开发者的“鸡肋时刻”
MCP 的起源可以追溯到 Anthropic 的 Claude Desktop，它最初只是为了让桌面 AI 能调用本地文件、应用等功能而设计的接口协议。从客户端视角看，它无疑极大扩展了智能体的可操作边界 —— 真正让“AI 动手”成为可能。
但问题来了：对后端开发者来说，这协议属实有点反人类。
当前 MCP 协议广泛采用双通道通信机制，即同时维护一个 双向请求通道 和一个 SSE（Server-Sent Events）长链****接。服务端需要：
-
创建一个临时 SSE 通道；
-
接收模型发来的工具调用请求；
-
将执行结果通过 SSE 通道返回；
-
再手动关闭链接。
整个流程既不优雅也不高效，更别提在复杂业务下的部署、连接数控制和稳定性维护了。
好消息是：新版本的 MCP 协议正在尝试引入无状态调用支持，未来可能对一次性请求/响应类的服务更加友好。但现阶段，MCP Client 仍然让不少后端开发者“直呼上头”。
🧩 工具生态：热闹是热闹，就是不太能用
自从 Claude 率先开放 MCP 工具接入后，整个 AI 圈就像打开了潘多拉的盒子：短短几个月内，已有上千个 MCP 工具接入平台，一度形成 “谁还没个工具挂在 Claude 上？” 的热潮。
但热闹归热闹，真正有用的却寥寥无几。
根据我的观察，目前 MCP 工具中：
- 有效可复用的不足 20%；
- 大量工具功能重复、描述模糊、质量参差；
- 缺乏系统性的评分体系，Agent 无法判断哪个更好用。
这直接导致一个尴尬局面：
Agent 面前横着一堆工具 —— 重名的、近义的、毫无描述差异的，谁也不认识谁，只能挨个试。
模型懵，token 飞，开发者心在滴血。
某种程度上讲，当前 Agent 的性能差异往往并不来自大模型本身，而是是否用了靠谱的 MCP 工具集。比如被广泛讨论的 Manus，就通过精心构建和定制化打磨 MCP 工具，大幅提升了 Agent 的任务完成率。
📌 结语：我们还在山脚下，但至少看清了方向
MCP 协议作为模型与工具之间的桥梁，确实带来了范式的改变 —— 从“让模型看世界”到“让模型操作世界”。
尽管它现在还不够成熟，后端机制有待简化，生态仍需清洗和筛选，但它所代表的方向是清晰的：一个可调用、可协作、可复用的 AI 能力生态系统。
如果你也在开发 MCP Server，欢迎一起来交流踩坑经验 ——
顺便说说你写过最 离谱、但最终却最 有效 的工具描述，那些模型“懂了也不一定照做”的瞬间。
