我们什么时候不需要MCP

Mon, 07 Sep 2026 00:00:00 +0000

问题

经常看到招聘 JD 上写着 MCP，似乎每个人都要会 MCP 才能做 agent 开发
又有人说 MCP 太重了，没什么人用 MCP
我们又会看到很多教程说，使用 MCP 统一接口很好用

我们平时看到的教程都是介绍 MCP 是什么，为什么要用 MCP。说了很多，其实大家还是不能直观地理解 MCP 的取舍。我今天就反过来说说什么时候不需要 MCP，来帮助大家更直观地感受 MCP。

MCP是什么

MCP（Model Context Protocol，模型上下文协议） 是 Anthropic 发起的一个开放协议，用来让 AI 应用（比如 Claude Code、Claude Desktop、OpenClaw 这些 agent）用统一的方式去发现和调用外部工具、读取外部资源

这是字面上的概念。实际上你可以把 MCP 看作是暴露给 agent 的一种资源。在 MCP 出现之前，如果你想让一个 AI 应用连上 Google Drive、GitHub、Slack 这些服务，每个 AI 应用都得为每一个外部服务单独写一套集成代码。 MCP 相当于给这个连接关系定义了一个"标准插座"。

不用MCP用什么

如果不用 MCP，我们还有很多别的东西可以选择。最重要的是两种： function calling： 2023 年 OpenAI 推出了 function calling 的能力。其实很简单，就是你先把一段函数签名传给 LLM。

{
 "name": "get_weather",
 "description": "查询某个城市当前的天气",
 "input_schema": {
 ...
 "properties": {"city": {"type": "string"}},
 }
}

LLM 知道有一个 tool 之后，如果 LLM 在执行过程中觉得需要调用这个外部工具，那么执行结果的 content 内会多出一个 tool_use 对象，并且 stop_reason 也会写 tool_use。就像：

{
 "content": [
 {
 "type": "tool_use",
 "name": "get_weather",
 "input": {"city": "new york"}
 }
 ],
 "stop_reason": "tool_use"
}

然后你就自己写代码去实现这个函数调用。

if response.stop_reason == "tool_use":
 tool_use = response.content[-1]
 // ... 调用查天气的函数

当然实际工作中没这么土，你可以用 LangChain 之类的框架。

CLI： 其实也是一种 function call，只不过你就只暴露一种 tool，而且直接告诉 LLM 这就是个 bash，你想执行什么命令就自己写命令。好处就是你不需要告诉 LLM bash 能干啥，要怎么用。因为 LLM 在阅读了大量资料后，它本来就知道怎么写 bash 命令。

但是使用 CLI 有一定风险，权限控制不好做。

模型视角感受

首先你必须知道一件事情：模型根本不知道你调用的是 MCP 还是 function calling。比如，当你注册查询天气这个工具的时候，如果使用 MCP 注册，那么模型看到的 tools 是这样的：

{
 "name": "get_weather",
 "description": "Get the current weather for a specified city",
 "input_schema": {
 "type": "object",
 "properties": {
 "city": {"type": "string"}
 }
 }
}

如果你用 function calling，模型看到的 tools 是这样的：

{
 "name": "get_weather",
 "description": "Get the current weather for a specified city",
 "input_schema": {
 "type": "object",
 "properties": {
 "city": {"type": "string"}
 }
 }
}

我们现在来玩一个游戏，你能看出这两个 JSON 的区别吗？答案是它们没有区别。所以不需要纠结用 MCP 跟 function calling 会对模型造成什么影响。对模型来说，根本就没有区别。

MCP的缺点

那么 MCP 既然这么好，为什么不都用 MCP 呢？因为 MCP 有缺点：

上下文开销大： 一旦连接上一个 MCP server，这个 server 暴露的所有工具的完整 schema（名字、参数、描述）都会被提前塞进模型的上下文窗口，不管这次对话用不用得上。

消耗服务器资源： MCP Server 是一个持续存在、需要一直跑着的东西。你启动的 MCP Server 多了，服务器的 CPU、内存都会被消耗。

运维负担： MCP server 既然是一个独立进程，你需要自己负责它崩溃后重启、多个 server 间的启动顺序，以及内部状态的持续维护。

MCP的优点

MCP 听起来很糟糕啊。那为什么那么多公司还是继续使用 MCP 呢？因为它虽然有很多缺点，但是它最大的优点就是统一了项目资源的集成接口。统一接口这件事情本身就有 2 个好处：

调用代码简洁： 这东西不做软件的人感觉不出它的好处。做软件的人听到统一接口都知道它好。你原来几千行的屎山代码，可能突然就变成十几行了。接口一多，bug 就埋藏得多、埋藏得深，维护起来就没完没了。

接入第三方资源简单： 所有第三方资源都做成了 MCP，这下接入资源不用再花费很多精力去做定制化了。这件事情其实也没什么技术含量，就跟统一货币、度量衡一样。关键是得有人去做这件事情。

结论

如果你的需求是以下其中一种：

你想用第三方做的工具
你在用你们团队多平台公用的工具
你想做多角色权限区分

那么你可以考虑使用 MCP，否则的话，使用其他轻量化方法，比如 function calling 就够了。

关于作者

我是代码Plato。

我相信，人类的创造力才是 AI Coding 的真实之树，而代码与模型不过是投射在洞穴墙上的影子。

微博：@代码Plato 主页：https://weibo.com/u/1041257881

Function Calling on Code Plato