1.3 你需要 MCP 吗？——适用场景与替代方案
小周理解了 MCP 解决的问题和历史背景，但他需要做一个判断：自己的项目真的需要 MCP 吗？有没有更简单的方案？
MCP 适用的场景
MCP 在以下场景中真正发挥价值：
多工具共享同一能力
Claude Code、Cursor、ChatGPT 都需要访问你的数据库——实现一次 MCP Server，所有工具都能用
企业内部工具集成
公司有内部 API、数据库、文件系统——用 MCP Server 封装后，任何 AI 工具都能安全访问
工具动态发现
AI 需要运行时发现可用工具，而不是硬编码——MCP 的 `tools/list` 支持动态发现
远程 SaaS 服务
需要 AI 访问 Slack、GitHub、Notion 等远程服务——MCP 的 Streamable HTTP + OAuth 支持安全远程连接
不需要 MCP 的场景
MCP 不是万能药。以下场景用更简单的方案就够了：
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 单次 API 调用 | Function Calling | 只需调用一个 API，不需要完整的协议层 |
| 只用一款 AI 工具 | 工具原生集成 | Claude Code 内置文件操作，不需要 MCP |
| 简单的脚本任务 | 直接写 Python/Shell | 不需要 AI 参与，自动化脚本更直接 |
| 已有 OpenAPI 规范的 API | Function Calling + API | LLM 原生支持 REST API 调用 |
| 只在本地用一两个工具 | 手动配置 | 为一两个工具实现 MCP Server 的投入不值得 |
决策树
小周用这个决策树来判断：
你的 AI 工具需要访问外部系统吗？
不需要 → 不需要 MCP
需要 → 只用一款 AI 工具？
是 → 用该工具的原生集成方式
否 → 外部系统多吗（≥3）？
否 → 手动逐个集成可能更简单
是 → 需要运行时动态发现工具吗？
否 → 静态配置 Function Calling 可能够用
是 → 需要 MCP！tools/list 正好解决
MCP vs 替代方案速查
| 维度 | MCP | Function Calling | OpenAPI | 直接集成 |
|---|---|---|---|---|
| 工具发现 | 动态 | 静态 | 静态 | 静态 |
| 跨工具兼容 | 任何支持 MCP 的工具 | 绑定特定 LLM | 需适配 | 绑定特定工具 |
| 双向通信 | 支持 | 不支持 | 不支持 | 取决于实现 |
| 授权 | 内置 OAuth 2.1 | API Key | 需外部实现 | 手动实现 |
| 开发成本 | 中（需实现 Server） | 低（定义 JSON Schema） | 低（已有规范） | 高（每个工具单独适配） |
| 适合规模 | 大中型项目 | 小型项目 | API 集成 | 一次性需求 |
常见误区
「我用了 Claude Code，所以一定要用 MCP」——错误。Claude Code 内置了大量工具（文件读写、Git、Bash 等），并且可通过 .claude/settings.json 配置额外 MCP Server。大部分开发任务用内置工具就够了，只有当你需要连接 Claude Code 原生不支持的外部系统（如内部数据库、企业 API）时，才需要自己开发 MCP Server。
小周的决定
小周评估了自己的情况：
- 团队用 3 款 AI 工具（Claude Code、Cursor、ChatGPT）
- 需要访问 4 个外部系统（GitHub、PostgreSQL、Slack、内部 API）
- 需要运行时动态发现工具
- 希望新增工具时不需要修改 AI 工具的配置
结论：MCP 是正确的选择。 4 个 MCP Server + 3 个内置 MCP Client = 7 个标准接口，比 12 个定制集成（3×4）好得多。
本节核心要点
- MCP 适合多工具共享同一能力、企业内部集成、动态工具发现、远程服务连接
- 不适合单次调用、只用一款工具、简单脚本任务
- 用决策树判断是否需要 MCP，而不是盲目跟风
- MCP vs Function Calling vs OpenAPI 不是非此即彼，可以组合使用
思考题：根据决策树，你当前的项目是否需要 MCP？如果需要，哪些外部系统最值得优先封装为 MCP Server？
参考思路
按决策树走一遍：(1) AI 工具需要访问外部系统吗？→ (2) 用几款 AI 工具？→ (3) 外部系统多吗？→ (4) 需要动态发现吗？如果到达"需要 MCP"，优先封装最常用、被最多工具访问的系统（通常是数据库和代码仓库）。