关于 MCP 的几个理解误区

      MCP（模型上下文协议）是一种帮助大模型在对话中获取更多上下文信息的协议。它的目标是让大模型能更准确地回答用户的问题。不过，关于 MCP，存在一些常见的误区。下面我们来一一澄清，简单易懂地解释这些问题。

误区 1：MCP 协议需要大模型支持

误解：

很多人以为 MCP 协议只有特定的大模型才能用，必须由大模型本身支持。

真相：

其实不是这样的。MCP 协议的核心是在应用层（比如你的程序或系统）上工作，它指导应用层如何给大模型补充上下文信息。
在 MCP 之前，已经有其他方法给大模型提供上下文，比如：

• 记忆存储：把之前的对话记录下来，和新问题一起发给大模型。
• RAG：先从知识库或网上找相关信息，作为上下文给大模型。
• Function Calling：给大模型一堆工具，让它挑一个用，工具的结果再作为上下文。

MCP 就像一个“助手”，在提问前把这些上下文准备好，交给大模型。大模型本身不需要知道 MCP 是什么，哪怕是老模型（比如 GPT-2），只要应用层按 MCP 的方式提供上下文，它就能用得上。

结论：

MCP 协议不需要大模型支持，任何大模型都能通过它获得上下文补充。

误区 2：只有支持 Function Calling 的模型才支持 MCP 协议

误解：

有人认为只有那些能用 Function Calling（工具调用）的大模型才能用 MCP。

真相：

先聊聊什么是 Function Calling：

• 它是一种交互方式。应用层给大模型提供一些工具，大模型根据问题挑一个（Pick Tool），返回工具名和参数，然后应用层调用工具（Call Tool），把结果给大模型回答。
• 这里有三个角色：应用、大模型、资源方（提供工具的）。

MCP 协议是对 Function Calling 的升级版。它多了“客户端”和“服务器”两个角色，把工具调用标准化。简单来说：

• 应用（主机）通过客户端找服务器要资源。
• 服务器对接资源方，返回结果给应用。
• 应用把结果作为上下文给大模型。

MCP 和 Function Calling 都靠大模型的“挑工具”能力。支持 Function Calling 的模型在这方面更强，能更准确地挑工具。但不支持 Function Calling 的模型也可以用“提示词工程”（写特别的指令）来挑工具，只是效果可能差点。

结论：

不支持 Function Calling 的模型也能用 MCP 协议补充上下文，只是效果可能不如支持的好。

误区 3：大模型原生支持 MCP 协议

误解：

有人觉得某些大模型天生就支持 MCP，甚至不用应用层帮忙，就能自己用 MCP 调用工具。

真相：

这种想法不现实。所谓“原生支持”，意思是大模型在训练时就内置了 MCP 的规则和一大堆工具，能自己挑工具、调资源。但实际情况是：

• 网上的资源五花八门，MCP 服务器和工具多到数不清，大模型不可能全记住。
• 有些资源是私密的（比如需要登录），大模型没法在训练时学会你的账号密码。

实际上，某些厂商说“原生支持 MCP”，可能是指他们的大模型配了个框架（agent），这个框架支持 MCP，让应用层用起来更方便。但大模型本身并没有内置 MCP。

结论：

大模型原生支持 MCP 的说法不专业，现阶段不可能实现。

总结

• MCP 是在应用层实现的，帮助大模型获取上下文，不需要大模型支持。
• 不支持 Function Calling 的模型也能用 MCP，只是效果稍差。
• 大模型不可能“原生支持” MCP，资源和权限的限制决定了这一点。

希望这篇文章能帮你轻松理解 MCP 和它的误区！有问题欢迎交流哦～