🧠 图解记忆： MCP 是可复用能力协议，不是万能接口；抽象收益小于成本时就别用。
💡 答案要点
面试官想考察什么：
这道题的本质不是考你知道多少，而是考你是否"明白自己不知道什么"。能说清楚一个技术的边界，比能背书它的优点更能体现工程成熟度。
应该避免使用MCP的场景：
| 场景 | 说明 | 为什么MCP不合适 | 更好的选择 |
|---|---|---|---|
| 简单的点对点集成 | 单个服务调用单个API | 引入MCP层增加复杂度，收益为零 | 直接HTTP/gRPC |
| 一次性脚本 | 跑一次就扔的工具脚本 | 写MCP Server的开销远超写个curl | Python脚本 / 直接API |
| 强一致性事务 | 需要ACID的事务 | MCP的工具调用是"即发即忘"，没有事务语义 | 数据库事务 / 消息队列 |
| 高频低延迟交易 | 毫秒级响应要求 | stdio传输有进程启动开销，SSE有网络开销 | 直接SDK |
| 数据量极大的流处理 | TB级数据管道 | MCP的请求-响应模型不适合流式场景 | Kafka / Flink |
| 团队缺乏维护能力 | 没有DevOps/SRE支持 | MCP Server需要持续运维（版本、安全、更新） | 托管API服务 |
MCP适合的场景 vs 不适合的场景对比：
✅ 适合 MCP 的场景：
- 多客户端需要共享同一套工具能力（Cursor + Claude Code + 自定义App）
- 工具需要被多个不同类型的Agent调用
- 需要标准化的安全审计和权限控制
- 工具生态正在扩展，需要"热插拔"式管理
❌ 不适合 MCP 的场景：
- 内部微服务之间的同步调用（直接RPC更简单）
- 对延迟极其敏感的交易系统（MCP的开销不可接受）
- 一次性数据迁移/ETL脚本
- 只需要调用一个固定API的场景（不需要抽象层）面试话术（反套路）：
"我用过MCP，也踩过MCP的坑——有一次我们把一个简单的PDF转Markdown脚本包装成MCP Server，结果发现它的启动延迟比直接执行脚本还高10倍，团队维护成本也上去了。后来我们把这种一次性工具改回Python脚本，MCP只留给真正需要跨客户端共享、并且需要统一安全治理的工具。这个教训让我理解到：MCP的本质是'可复用的能力抽象'，不是'把什么都扔上去的万能接口'。"
面试加分项：
- 能举出自己实际项目中"用了MCP但后来发现不合适"的真实案例
- 能说出stdio vs SSE两种传输层在延迟上的具体差异
- 理解MCP是"USB-C"，但USB-C不适用所有设备
📚 参考：MCP 官方 FAQ（适用边界）