为什么需要 MCP：从工具接入到互操作

上一章说了 MCP"是什么"，本章讲它"为什么"诞生：AI 应用想用外部工具与数据时，传统做法为什么疼，MCP 又凭什么换来互操作。理解痛点，才能读懂后面每一章的取舍。

演进中的三大痛点

• 每款应用各写一套插件：Claude、各 IDE、各家智能体都要接搜索、文件、数据库，同一能力要按每种应用的前端规范各实现一遍，重复劳动巨大。
• 每个服务商各出各的 API：工具提供方暴露 REST、WebSocket、SDK 各不相同，AI 应用要逐个适配、逐个维护。
• 能力被锁死在单一应用里：为 A 应用写的集成无法迁移到 B 应用，换工具链等于重写一遍。

N×M 适配困境

把问题抽象成矩阵：N 个 AI 应用 × M 个服务，两两适配需要维护 N×M 个集成：

方案	集成数量	新增一个服务要写
两两定制	N×M	N 套适配
统一协议（MCP）	N+M	仅 1 套服务器

接入方与服务方都只面向同一个协议编程，"互操作"才成为可能。 MCP 相当于把中间那层适配抽成公共层：接入方写一次客户端、提供方写一次服务器，剩下的组合交给协议完成。

MCP 带来的标准化收益

• 一次实现、处处可用：服务器写好后，Claude Desktop、IDE、自研应用只要支持 MCP 都能直接连。
• 授权与安全语境统一：工具调用由宿主统一向用户呈现与授权，模型不能绕过用户确认乱动系统。
• 生态复用：官方与社区维护了大量现成服务器（文件系统、数据库、浏览器等），拿到即用，详见后续"服务器目录"章节。
• 可观测与治理：所有外部调用都收敛到统一的协议入口，便于日志、审计与限流。

三个接入一次打通

MCP 用三原语回答"模型需要什么"：

• tools（工具）：模型自主发起动作，例如下单、发消息。
• resources（资源）：给模型注入可读上下文，例如文档、日志。
• prompts（提示词）：引导工作流的模板，例如"审查这段代码"。 第 4 章将逐一展开。

与其他方案的差异

• Function calling：各家模型的私有约定，跟着模型 API 走，不跨应用。
• 直接调 HTTP API：与具体服务绑定，且模型无法在对话中自主选择调用。
• MCP：开放、与应用和模型解耦，是"接入层"的标准；上层由各宿主自由发挥。

什么时候该上 MCP

• 内部工具多、希望多个 AI 前端共用一套能力；
• 自己就是工具提供方，想让更多智能体生态接入；
• 想统一管理模型对外的动作与授权边界。 反之，一次性脚本、无多端复用需求时不必引入。

小结

MCP 的动机可概括为：把 N×M 的重复适配压缩成一次实现，换来工具/数据/工作流跨应用互操作。本章的痛点清单也是后续章节反复回扣的设计依据——协议为什么做协商、为什么把授权交给宿主，都能从这里找到答案。下一章看协议内部结构——宿主、客户端与服务器如何分工。