先说个类比。
这几年所有设备都换成了 USB-C，接口终于统一了。但你把移动硬盘插上去，它不会自动帮你备份。
接口标准只保证「插得上」，不保证「插上之后的事」。
MCP 就是 AI 工具界的 USB-C。它解决的问题是互操作性，不是别的。所以当面试官问「MCP 有什么缺点」时，答案都在它「没管」的那些地方。
一、先排雷：不要答「MCP 不支持流式」
有面试官问的是「MCP 的缺点与流式结果」。
很多人第一反应会顺着答「MCP 不支持流式，只能一次性返回」——这是错的。
翻遍中英文来源，没有任何来源把「流式」列为 MCP 的缺点。相反，流式和双向连接是它的设计卖点（相对于一次性请求-响应）。
和流式相关的问题是另一回事，原话来自 Anthropic 官方工程博客：
每个中间结果都必须穿过模型上下文。
它带来三个后果：
- 多工具工作流里，完整的调用记录可能从模型里流过两次
- 一场 2 小时的销售会议可能凭空多出 50,000 token；更大的文档直接超出上下文窗口
- 模型在工具调用之间复制数据时更容易出错
所以正确的说法是：不是「流式」错了，是「流式的结果穿过模型」错了。这两句只差几个字，但一句是错的，一句是满分。
二、实际的缺点，按被考频率排
1. 上下文 / Token 成本（最常考）
MCP Server 通过 tools/list 把所有工具定义（名称、描述、参数 Schema）注入系统提示，不管你这次用不用得上。
| 数据 | 数值 |
|---|---|
| 单个工具的粗略占用量 | 约 1,000 token |
| 20 个 Server / 290 个工具 | 73,323 token，占 200k 上下文的 36.7% |
| 光一个 GitHub MCP Server | 55,000 token（93 个工具定义） |
| 模型开始退化的区间 | 150k – 180k token |
单工具约 1,000 token 这个数字，出自 GitHub 官方讨论 #2812 里的一句原话：
一个人类两句话能描述的工具，占 ~1,000 token。
还没等用户说出第一句话，上下文已经被吃掉三分之一。
而且 prompt caching 不能完全解决：工具只要有增删改，整个前缀缓存就失效。
~1,000 和 73,323 这两个数别相乘：前者是 GitHub 讨论里对单个工具的粗略说法，后者才是实测总量。被问「290 个工具不就 29 万 token」时，要能说清哪个是估算。
2. 安全
- 早期没有统一认证规范，后来加上了，但仍是建议式、非强制
- 本地 stdio 传输意味着可以运行任意代码
- 攻击面包括：混淆代理、提示注入、工具投毒、Rug Pull
- 公开数据：近 7,000 个暴露公网的 MCP Server，约一半没有授权控制
- 中间流过的敏感数据，全部进入 provider 的上下文
3. 有状态架构难扩展 + 延迟
MCP 基于持久 session，这带来两个后果：
- 难 serverless 部署，也难做负载均衡——有状态的东西天生难横向扩
- 比直接 Tool Calling 多出一层开销：协议解析 + Server 寻址 + IPC
4. 工程复杂性与可靠性（这条最容易答出深度）
MCP 只定义三件事：工具长什么样、调用怎么发、结果怎么返回。
它不定义失败重试、幂等、熔断。
一句话概括：
MCP 只管格式正确，不管值正确。模型完全可能幻觉出一个工具根本没返回过的结果。
调试也难：一个故障可能横跨模型推理 / 协议传输 / 网络 / 下游服务四个边界。再加上版本碎片化，不同 Server 支持的协议版本还不一样。
这一条正好接上 P1 八股：「工具调用失败的分层处理」「三态熔断器」要你自己写，正因为 MCP 不提供。
5. 其他
| 常见说法 | 纠正 |
|---|---|
| 「MCP 能替代 RAG」 | 不能。它是动作协议，不具备深度索引和语义重排能力 |
| 「MCP 会管工具风险」 | 不会。读数据、删数据、订机票在协议里没有风险分级 |
| 「MCP 会控制成本」 | 不会。没有最大返回长度限制 |
三、满分回答的四层结构
- 先给结论：MCP 标准化了互操作性，但没替你解决安全、可靠性、成本和扩展性
- 讲最硬的证据：Token 开销——
tools/list全量注入、单工具约 1,000 token、20 Server / 290 工具 = 73,323 token，占 36.7% - 讲可靠性边界：不定义重试 / 幂等 / 熔断，只管格式正确、不管值正确
- 给解法和取舍：
- resource links：服务端把大结果写盘，只回一个资源 URL
- code execution：Anthropic 报告 token 从 150,000 降到 2,000
- 网关层过滤
tools/list，限制模型可见的工具数
第 4 层是分水岭。只讲缺点叫复读，给出取舍才叫工程判断。
四、也要准备反方：「MCP 已死，CLI 称王」
行业里确实有这场争论，有一部分大厂转向 CLI。能讲出这个争议，说明你在跟进行业，而不是背了两年前的博客。
我的看法（当观点讲，别当结论）：CLI 是给人、给 shell 用的，MCP 是给任意 AI 客户端用的。但先把争论讲清楚，比急着站队重要。
五、我的优势：我写过 MCP Server
我写过一个发布到 npm 的 MCP Server（拆解在这里），这让我能讲一个别人讲不出的取舍：工具描述写多详细。
- 写太细 → 每个工具吃掉更多 token，而 token 开销是这个协议最硬的缺点（上面第 1 条）
- 写太粗 → 模型不知道该在什么时候调它，选错甚至漏调
这不是理论权衡，是我改过好几版才定下来的长度。这类「我具体怎么取舍的」比背结论有说服力得多。
六、面试官会追问什么
问：MCP 的缺点里，你觉得最严重的是哪个？
答：Token 成本，因为它是默认发生的——不用你做错什么，工具一注册就吃上下文。安全是概率问题，成本是确定性问题。
问：MCP 和 Function Calling 差不多，为什么不直接用？
答：能力上差不多，差别在标准化和发现机制。Function Calling 要你自己把工具定义塞进请求；MCP 是工具挂在 Server 上，任何客户端接上就能通过
tools/list发现。代价是多一层协议开销，以及「所有工具定义无条件注入」。
问：既然有这么多缺点，你还用 MCP 吗？
答：用，但按场景。工具少、要跨客户端复用时它很值；工具多、上下文紧张时，就得靠网关过滤或资源链接压回来。能用 prompt caching 缓解，但工具一增删改缓存就失效。
七、一句话版本
MCP 的缺点不是「不支持流式」——流式是它的卖点；它的缺点在没管的那些事：把全部工具定义顺手塞进上下文、把重试幂等熔断全丢给你，而它只保证格式正确。
八、自测
- 为什么不能答「MCP 不支持流式」？正确的说法应该是什么？
- 20 个 Server / 290 个工具会占用多少 token？占 200k 上下文的百分之多少？
- 为什么说「prompt caching 不能完全解决」工具定义的成本问题？
- 用自己的话说清「只管格式正确，不管值正确」是什么意思。
- 面对 Token 开销，文中给了哪三种解法？