最近 AI Agent 圈子，MCP（模型上下文协议）热度居高不下。

很多教程、开源项目都在鼓吹 MCP，仿佛只要用上 MCP，AI 智能体就能无缝打通一切外部系统。

既然大模型已经足够强大，完全可以直接去调用 REST API、执行 CLI 命令，那 MCP 这一层中间件，是不是多此一举？

开发者分成两大阵营，吵得不可开交。一方认为 MCP 是 AI 时代的 USB-C，是不可或缺的标准；另一方直言 MCP 只是多余包装，徒增开销与故障点，小项目完全没必要碰。

今天我们跳出 “无脑吹 MCP” 的舆论，结合社区真实辩论，搞懂 MCP 的真实价值、短板，以及到底什么场景才值得上 MCP。

01正方观点：MCP解决API原生解决不了的痛点

支持 MCP 的开发者认为：不要把 MCP 理解成 “套一层壳包装已有 API”。MCP 面向的调用者是大模型，而传统 REST API 的设计面向程序员编写的代码，二者设计出发点完全不一样。

1. 能力自动发现，不用硬编码大量接口信息

• 普通 REST API，AI 想要调用，就要把完整 OpenAPI 文档塞进提示词。接口一多，会疯狂吃掉 Token；大模型还要自己从几十上百个端点里，筛选需要的接口，很容易理解错参数，反复试错。
• MCP 服务端可以对外自我描述能力：有哪些工具、入参是什么、能干什么事。Agent 运行时动态拉取工具列表，不需要把全部接口文档全部塞进上下文。新增工具，所有连接这个 MCP 服务的 Agent 立刻就能感知，不用修改每一个 Agent 的提示词。

2. 统一鉴权，密钥不会泄露进大模型上下文

• 这是企业场景非常看重的一点。直接调用 API，往往要把 Token、密钥交给 Agent 环境，密钥存在上下文环境中，存在泄露风险。
• MCP 可以把鉴权逻辑放在服务端。Agent 客户端不需要持有原始密钥，密钥不会流入 LLM 的对话上下文中。同时可以做细粒度权限管控：只开放部分工具，禁止高危操作，所有调用统一日志审计。

3. 对AI友好的适配层，抹平原始API的各种坑

• 很多业务 API 返回格式、报错信息都是给人看的，并不适合大模型解析。分页逻辑、异常错误码、诡异入参，都会把 Agent 搞懵。
• MCP 服务端可以做一层适配：把底层杂乱 API 封装成面向 AI 的业务工具，做参数校验、异常转换、批量逻辑封装。底层 API 发生改动，只需要修改 MCP 服务，所有 Agent 不需要改动。

 4. 原生支持会话交互，支持人机确认弹窗

• 普通 HTTP-API 大多是无状态。MCP 协议原生支持会话，甚至支持中途向人类发起询问确认。比如高危操作弹框复核，这个能力裸 API 很难实现。

类比：MCP 更像是 面向 AI 的 BFF 后端适配层。后端 API 是底层数据库能力，MCP 是专门给大模型这个特殊 “前端” 准备的后端。

02反方观点：很多场景纯属过度工程

另一部分开发者提出尖锐质疑，代表观点甚至来自 Google 内部工程师：团队内部直接用 RPC、CLI，放弃了 MCP。他们的理由同样很现实。

1. 额外Token开销与性能损耗

• 连接多个 MCP 服务时，会把大量工具 Schema 加载进上下文，吃掉大量 Token，拉高延迟与成本。虽然现在有延迟加载优化，但增加了系统复杂度。
• 对于简单个人项目，直接写 Skill、让 Agent 执行 curl 或者 CLI 脚本，代码更少，少一层中间故障点。

 2. 很多MCP服务只是对REST API做一层薄包装

• 不少开发者写 MCP，没有做任何业务封装，只是简单透传底层 REST 接口。这种 MCP 毫无增益，徒多一层转发，故障点变多。
• 社区评论一针见血：如果你 MCP 里面每个工具一一对应 API 接口，那还不如直接调用 API。

3. 引入新的安全风险

• MCP 不是天然安全。如果 MCP 服务本身写得有漏洞，会带来新攻击面，比如工具投毒、恶意返回注入提示词。即便 MCP 有鉴权，安全防护依然要开发者自己实现，不是协议自带。

4. 简单项目维护成本得不偿失

• 个人 Demo、单一 Agent 调用少数接口的场景，搭建维护 MCP 服务属于额外工作量。直接写一套 Skill 或者简单 HTTP 工具，快速完成业务，迭代速度更快。

“MCP 不是万能。如果它不能帮你解决‘多个 Agent 共享工具’或‘安全合规’的问题，那它只是在给你增加故障点。”

03关键结论：MCP和API不是二选一，看业务规模

 优先考虑 MCP 的场景

• 多 Agent 复用同一套工具能力：

  多个智能体、多个客户端需要调用同一套业务能力，一次开发 MCP，全部 Agent 复用；

• 企业安全合规诉求：

  需要统一鉴权、调用审计、细粒度权限隔离，密钥不能暴露给 Agent 运行环境；

• 底层原始 API 对大模型不友好：

  接口复杂、分页混乱、报错不友好，需要封装业务语义，抹平底层差异；

• 需要会话能力、人工交互确认：

  工具调用中途要向用户弹窗确认操作；

• 生态互通需求：

  希望不同厂商 Agent（Claude、Cursor 等）直接接入你的能力，遵循统一标准。

可以直接裸调用 API/CLI，没必要上 MCP

• 个人 Demo、原型验证，仅单个 Agent 使用工具；
• 底层 API 本身足够简洁清晰，不需要做业务封装；
• 追求极致低延迟，不想增加中间层；
• 工具数量很少，改动频率极低。

一个很形象的比喻来自评论区：

“MCP 就像 USB-C 标准。你完全可以用电线直接焊接电路板实现通信，做小项目没问题。但如果你希望各种各样设备即插即用，就需要统一接口标准。标准本身不能解决所有问题，但解决互通问题。”

“MCP 不是万能药，不会只要接入就自动让你的 Agent 变聪明。”

它本质是一套 面向大模型的工具接入标准，优势是复用、安全、生态互通；但同时带来复杂度、Token 开销、运维成本。

很多人踩坑，根源不是 MCP 协议本身，而是 错误的使用方式：简单把 REST API 透传一遍，包装成 MCP 就完事，没有做面向 AI 的业务抽象。

不要跟风新技术，先问自己：

• 我是不是需要多个 Agent 共享这套能力？
• 有没有权限、审计的硬性要求？
• 底层 API 是否对大模型很不友好？

如果都不是，直接调用 API/CLI，反而更简单高效。

阅读原文：点击这里