8.1 MCP 要解决什么问题
一句话结论：MCP 解决的不是"技术难题"，而是组合爆炸——M 个 AI 应用 × N 个工具，如果各自适配就是 M×N 份工作；有了统一协议，变成 M+N。
读这篇之前
需要先读 4.1（Function Calling）、4.5（工具爆炸）。这一篇是第 8 章的地基。
一、先看没有 MCP 时的世界
假设你有 5 个 AI 应用（Claude Code、某个 IDE 插件、自研 Agent、客服机器人、数据分析助手），和 6 个数据源（GitHub、数据库、Slack、文件系统、Jira、Confluence）。
没有统一协议时：
每个 AI 应用都要为每个数据源写一套对接代码
= 5 × 6 = 30 份适配代码
而且每份代码都要处理：认证、参数格式、错误处理、分页、限流……
有了统一协议后：
每个数据源实现一次"服务端"（6 份）
每个 AI 应用实现一次"客户端"（5 份）
= 5 + 6 = 11 份
这就是 M×N → M+N 的变化。问题一旦规模上去，这个差别是指数级的。
这个逻辑和 USB 标准、LSP（语言服务器协议）完全一样——标准化不是为了优雅，而是为了不让组合爆炸。
二、MCP 的准确定义
MCP（Model Context Protocol，模型上下文协议） 是一套规定"AI 如何调用外部工具/数据"的开放标准。
需要纠正两个常见说法：
| 常见说法 | 准确说法 |
|---|---|
| "MCP 是 Anthropic 的专有规范" | 由 Anthropic 提出，但是开放标准，非专有 [核验] |
| "MCP 只是工具调用协议" | 不止工具，还包括 resources（数据）和 prompts（模板）[核验] |
官方定位：MCP 由两层组成——Data layer（基于 JSON-RPC 2.0 的协议，含能力与版本发现、核心原语 tools/resources/prompts/notifications）与 Transport layer（通信通道与认证）。[核验：MCP 官方架构]
当前规范版本：2026-07-28。[核验：modelcontextprotocol.io]
三、三代"工具标准化"的演进
工具调用本身并不新（4.1 讲过三代）。MCP 的位置在哪？
| 阶段 | 形态 | 谁定义接口 | 问题 |
|---|---|---|---|
| 无标准 | 每个应用自己接每个工具 | 各自 | M×N 适配 |
| Function Calling | 模型厂商定义"怎么描述工具" | 模型厂商 | 解决了格式，但工具仍要各应用自己实现 |
| MCP | 开放标准定义"工具怎么提供服务" | 社区标准 | 工具实现一次，所有支持 MCP 的应用都能用 |
关键区别：
- Function Calling 标准化的是 "模型如何表达我要调工具"
- MCP 标准化的是 "工具如何被提供和使用"
打个比方：
- Function Calling 像"点菜的语言"（怎么告诉服务员）
- MCP 像"餐厅的标准"（厨房怎么接单、怎么上菜）
四、MCP 解决的三类实际问题
| 问题 | 没有 MCP | 有 MCP |
|---|---|---|
| 重复实现 | 每个应用各写一遍 GitHub 对接 | 一个 GitHub MCP Server，所有应用共用 |
| 能力发现 | 硬编码调用 | 客户端可查询服务端"你提供什么能力" |
| 版本漂移 | 各应用支持的版本不同，互不兼容 | 协议层做版本协商（8.4） |
第二条值得展开：能力发现（capability discovery） 是 MCP 的一个关键设计——客户端可以问服务端"你支持哪些工具、哪些资源、哪个协议版本"。这让"未知服务端"也能被正确使用。
五、一个必须澄清的误解：MCP 不是"更强的工具调用"
很多人以为"用了 MCP，工具就会更准"。不会。
| MCP 改变的 | MCP 没改变的 |
|---|---|
| 工具怎么被提供与发现 | 模型选工具的准确率（4.2 的描述质量决定） |
| 一次实现多处复用 | 参数校验（4.3 仍是你的责任） |
| 协议分层与版本协商 | 工具的副作用分级（4.5、第 14 章） |
| 传输方式的标准化 | 上下文占用（工具越多越占，2.2） |
换句话说：MCP 是"工程基础设施"，不是"能力增强"。它让接入更省事，但不让模型更聪明。
六、动手：把"没有 MCP"的痛具体化
抽象讲组合爆炸不如算一笔账。下面是一个真实的对接工作量估算，每一项都是独立要写的代码。
假设你要把「GitHub」能力接入 3 个 AI 应用（IDE 插件、CLI 工具、客服机器人）。
没有协议时，每个应用都要写这一套
| 工作项 | 说明 | 预估 |
|---|---|---|
| 鉴权 | OAuth 流程、token 存放、刷新 | 3 天 |
| 请求封装 | 拼 URL、设 header、处理超时 | 1 天 |
| 参数校验 | 每个接口的参数类型与必填 | 2 天 |
| 错误处理 | 限流、5xx、网络异常的重试 | 2 天 |
| 结果归一化 | 把 GitHub 的原始 JSON 转成模型能读的格式 | 2 天 |
| 分页 | GitHub 大量接口分页，要循环拉取 | 1 天 |
| 工具描述 | 给模型写的 description（4.2 的六要素） | 1 天 |
| 评测 | 该调/不该调的用例（4.5） | 2 天 |
约 14 人天 × 3 个应用 = 42 人天。
有协议时
| 工作项 | 谁做 |
|---|---|
| GitHub MCP Server | 做一次（社区通常已有现成实现） |
| 3 个应用的客户端 | 各接入一次（协议已封装好通信） |
总工作量从 42 人天降到约「1 次服务端 + 3 次薄接入」。
这个账的关键在哪
不在"总人天变少了"，而在边际成本：
| 场景 | 无协议 | 有协议 |
|---|---|---|
| 加第 4 个应用 | +14 人天 | +少量接入 |
| 加第 5 个工具源 | 每个应用都要改 | 各应用零改动 |
"加一个新工具不需要改所有应用"——这才是 M+N 的真正价值。
七、MCP 的三类真实使用场景
理解了价值，再看它实际被用在哪些地方。
场景一：本地开发工具
AI 应用 ←stdio→ 本地 MCP Server（读文件、跑命令、查数据库）
特征：同机运行、stdio 传输、无需认证、性能最好（8.2）。
典型：文件系统、Git、本地数据库。
场景二：团队共享的内部服务
多个 AI 应用 ←Streamable HTTP→ 公司内部的 MCP 网关
特征：多人共用、需要认证、需要审计（14.5）。
典型：内部知识库、工单系统、监控查询。
场景三：第三方 SaaS
AI 应用 ←HTTPS→ 厂商提供的 MCP Server
特征：跨组织、需要 OAuth、信任等级最低（8.6）。
典型：项目管理、通讯、CRM。
这三类的安全要求完全不同，所以第 8.6 篇的安全检查清单要按场景裁剪，不能一刀切。
八、一个常被问的问题：MCP 会不会取代 API
不会。 它们解决的是不同层次的问题：
| REST API | MCP | |
|---|---|---|
| 面向 | 程序（开发者写代码调用） | 模型（模型决定何时调用） |
| 接口描述 | 文档（人读） | schema + description（模型读，4.2） |
| 谁决定调用 | 代码逻辑 | 模型判断 |
| 能力发现 | 看文档 | server/discover（8.4） |
最实际的关系是：很多 MCP Server 内部就是调 REST API——它是 API 之上的"给模型用的适配层"。
所以：
MCP 不替代 API，它把 API 翻译成模型能理解、能选择的形式。
九、什么时候不该用 MCP
| 情况 | 更合适的做法 |
|---|---|
| 只有一个应用用，且工具是自研 | 直接写 Function Calling（4.1）更轻 |
| 工具逻辑极简（一次 HTTP 调用） | 直接给个工具函数 |
| 团队没有第二个 AI 应用 | MCP 的复用价值体现不出来 |
判据：MCP 的收益来自"复用"。 如果只有一个消费者，它相对直接写工具的收益接近于零，反而多了一层进程/网络通信（8.2 第五节）。
十、一个完整的落地路径：从零到团队可用
前面的账算清了"为什么值得"，这一节给"怎么做"。按五个阶段推进，每个阶段都有可验收的产出。
阶段一：先把能力做成工具（不碰 MCP）
| 动作 | 产出 |
|---|---|
| 把要暴露的能力写成函数 | 5-10 个函数，各有明确的输入输出 |
| 每个函数写 description（4.2 六要素） | 能被模型读懂的说明 |
| 用 Function Calling 直接接进一个应用 | 能跑通 |
为什么先不碰 MCP：如果工具本身设计得差（描述含糊、参数自由文本），换成 MCP 也只是把差设计标准化了。先验证工具质量，再谈协议。
阶段二：抽成独立进程
| 动作 | 产出 |
|---|---|
| 把工具逻辑从应用里拆出来 | 独立可执行程序 |
| 定义 stdio 收发 | 一个最小的 MCP Server |
| 应用侧接入 | 第一个 MCP Client |
验收标准：应用启动时能列出该 Server 的工具，并成功调用一次。
阶段三：补齐协议要素
| 动作 | 为什么 |
|---|---|
实现 server/discover |
客户端能发现能力（8.4） |
| 分明 tools / resources / prompts | 权限模型正确（8.3） |
业务错误用 isError |
模型能自我纠正（8.2） |
| 返回值归一化（去时间戳、固定排序） | 提高稳定性（2.4） |
验收标准：换一个不同的 MCP 客户端，也能正常使用（说明协议实现正确，而不是只对自己的客户端可用）。
阶段四：加安全与权限
| 动作 | 对应章节 |
|---|---|
| 参数枚举化、路径白名单 | 4.3、14.4 |
| 副作用分级（只读/写入/不可逆） | 4.5 |
| 不可逆动作审批 | 14.3 |
| 沙箱（如执行类工具） | 10.3 |
| 调用审计 | 14.5 |
验收标准：故意传一个越权参数，被拒绝且有可读的错误信息。
阶段五：团队化
| 动作 | 为什么 |
|---|---|
| 改 Streamable HTTP，加认证 | 多人共用（8.2） |
| 工具描述变更告警（指纹） | 防静默变更（8.6） |
| 使用统计：哪些工具被用、哪些从没用 | 治理（4.5） |
| 版本固定 | 防升级破坏 |
验收标准：两个不同应用团队能各自接入，且互不影响。
十一、一个反例：什么时候这套流程是浪费
上面的路径适合"能力要被复用的团队"。但有些情况完全不必：
| 情况 | 为什么不必 |
|---|---|
| 只有一个应用，短期项目 | M×N 的问题不存在（N=1） |
| 工具极少（2-3 个） | 直接写 Function Calling 更简单 |
| 团队只有你一个人 | 复用价值体现不出来 |
| 能力还在剧烈变化 | 协议层会成为负担 |
判据：问自己"有没有第二个消费者？" 没有，就先用最简单的方式。
这也是 1.4 复杂度阶梯在协议层的重复——复杂度必须被需求证明。
十二、MCP 与现有工具链的衔接
落地时你会遇到"已有的工具怎么办"。
| 现状 | 处理 |
|---|---|
| 已有一批 REST API | 写一层 MCP 适配（MCP Server 内部调 API），不改原有服务 |
| 已有一批内部工具函数 | 直接包装成 tools，逻辑不动 |
| 有 CLI 工具 | 用 stdio 起子进程调用，再包装 |
| 有其他 AI 应用的插件 | 不必重写，各自并存（它们是不同层的抽象） |
核心原则：MCP 是"适配层"，不是"重写理由"。 已有的实现尽量保留，只加一层协议包装。
十三、常见误区
误区七：MCP 是"给模型用的 API"，所以 API 可以淘汰。
两者是叠加关系，MCP Server 内部通常就在调 API。
误区八：接一个 MCP Server 就能立刻用得很好。
工具描述质量、参数校验、权限分级仍是你的责任（4.2、4.3、14.4）。
误区九：MCP Server 越多，Agent 越强。
工具爆炸问题依然存在（4.5），需要治理。
误区十：自己写 MCP Server 没意义。
如果你有独特的内部能力，包成 MCP Server 能被所有 AI 应用复用——这是公司内部做"AI 基础设施"的起点。
补充误区
误区一：MCP 是 Anthropic 专有的。
是开放标准，由 Anthropic 提出但非专有。[核验]
误区二：MCP 只关于工具。
还有 resources（上下文数据）与 prompts（交互模板）。[核验]
误区三：用了 MCP 工具调用就更准。
准确率取决于工具描述、schema、模型能力，与协议无关。
误区四：MCP 能替代 Function Calling。
不是替代关系。MCP 服务端最终仍以工具形式暴露给模型，底层仍然走 Function Calling。
误区五：MCP 只是"少写代码"。
它真正的价值是生态——工具一次实现，所有 MCP 客户端可用。
误区六：MCP 会让工具变少。
它会让"可接入的工具"变多，工具爆炸问题依然需要治理（4.5、9.4）。
十四、一个真实对比：三个应用 × 四个工具源
把抽象数字换成一个更贴近实际的结构。
| 场景 | 应用数 | 工具源数 | 无协议工作量 | 有协议工作量 |
|---|---|---|---|---|
| 早期 | 1 | 2 | 2 套对接 | 2 个 Server + 1 个 Client |
| 团队期 | 3 | 4 | 12 套对接 | 4 个 Server + 3 个 Client |
| 扩张期 | 5 | 8 | 40 套对接 | 8 个 Server + 5 个 Client |
注意中间一行：工作量从 12 降到 7；最后一行从 40 降到 13。
这就是为什么"早期觉得 MCP 没用、团队一大就觉得离不开"——它的收益随 N 增长，而 N=1 时收益为零。
但成本不是零
公平地说，引入 MCP 也有成本：
| 成本 | 说明 |
|---|---|
| 进程/网络开销 | 比函数调用慢（8.2 第五节） |
| 调试链路变长 | 跨进程，日志分散 |
| 协议实现成本 | 第一个 Server 要认真写 |
| 版本管理 | Server 与 Client 要协同升级 |
所以判断标准不是"有没有好处"，而是"好处是否超过这些成本"。
一个可用的判据：
收益 ≈ (应用数 × 工具源数) - (应用数 + 工具源数)
成本 ≈ 协议实现的固定成本 + 每次调用的额外延迟 × 调用量
若 收益 > 成本 → 值得
当应用数或工具源数 ≥ 3 时，收益通常已经明显大于成本。
十五、从这篇带走的三个判断
| # | 判断 | 用在哪 |
|---|---|---|
| 1 | MCP 解决组合爆炸，不提升模型能力 | 别指望它让工具选得更准 |
| 2 | 收益随 N 增长，N=1 时为零 | 单应用项目别上 MCP |
| 3 | 它是适配层，不替代 API | 已有实现保留，只加包装 |
这三条能覆盖绝大多数"MCP 该不该用"的决策。
十六、下一篇
MCP 的价值来自它的结构。它被明确分成两层——数据层和传输层。
这个分层不是学术洁癖，而是有实际好处的：换传输方式不影响协议语义。下一篇把这两层讲清楚。