MCP vs 传统API：连接成本从N²降到N+1

当AI助手从1个增加到4个，传统API的集成工作量会从1条连接膨胀到12条；而MCP（模型上下文协议）把这一数字压到8条。这背后是一次连接范式的根本转变。

传统API集成的N²困境

直接工具调用（Direct tool calling）的起步确实简单：一个助手对接一个API，写一段适配代码即可。但问题随着助手数量线性增长而指数级爆发。

据YouTube技术频道的分析，假设你先接入了Cursor，就需要为它写一个定制适配器；再加入ChatGPT，重复的胶水代码文件开始堆积。

更棘手的是双向膨胀。每新增一个服务（比如GitHub、Slack），就要为每个助手各写一套对接逻辑。四助手加四服务，连接数达到12条。

而每一次服务端的schema变更，都会击穿其中一条连接，导致对应的助手失效。

这种模式把团队拖入“维护地狱”：代码重复、故障点分散、迭代速度被拖慢。连接数呈N²增长，而维护精力是有限的。

MCP的翻转：服务自描述，工具自动发现

模型上下文协议（Model Context Protocol，MCP）改变了信息流向。不再由每个助手去硬编码服务接口，而是让服务自己描述它提供哪些工具。

任何AI通过标准JSON-RPC向MCP服务器发起查询，就能即时发现可用工具，无需预先编写适配器。这意味着工具的描述与调用协议解耦，服务端升级schema时，助手端可以通过发现机制自动适应，而不是直接崩溃。

“写一次，连接所有AI模型”是这一架构的核心承诺。适配工作从每个助手各写一份，收敛为服务端统一暴露一份。

JSON-RPC 是一种轻量级的远程过程调用协议，使用 JSON 作为数据格式。它定义了请求、响应和通知三种消息类型，请求中必须包含 jsonrpc 版本号、method 名称和可选的 params，响应则包含 result 或 error。与 REST 不同，JSON-RPC 不依赖 HTTP 动词和 URL 路径来表达语义，所有操作都通过统一的端点和方法名区分，因此非常适合工具发现这种“先查询能力、再调用具体方法”的场景。在 MCP 中，客户端通过 tools/list 方法获取工具清单，再通过 tools/call 执行具体工具，整个交互过程天然支持动态扩展，无需为每个新工具重新设计接口路径。

工具发现（Tool Discovery）机制是 MCP 区别于传统硬编码集成的关键。在传统模式下，助手必须预先知道每个 API 的端点、参数和返回结构；而在 MCP 中，服务端在启动时注册自己提供的工具列表，包括工具名称、描述、输入参数的 JSON Schema 等元数据。客户端连接后首先调用发现接口拉取这份清单，再根据用户意图动态选择工具并构造参数。这种“先发现、后调用”的流程使得新增工具或修改参数结构时，只要服务端更新元数据，所有已连接的助手都能自动感知，而不需要重新发布适配代码。工具发现也因此成为 MCP 实现“写一次，连接所有 AI 模型”承诺的技术基石。

3+3 取代 9：连接成本的数学变化

视频中用了一个直观的对比：三个AI助手接三个服务，传统方式需要九条连接（3×3），而MCP方式只需六条（3+3）——每个助手连一次协议，每个服务暴露一次协议。

连接数从N×M降为N+M，这是MCP最直接的工程价值。当助手和服务数量继续增加时，差距会进一步拉大：四助手四服务是16对8，十助手十服务是100对20。

这种收敛不仅减少了代码量，还降低了schema变更的爆炸半径。变更发生在服务端，所有通过协议连接的助手统一受益，而不是逐个修复。

星型拓扑与网状拓扑的对比是理解 MCP 工程价值的关键。传统直接调用形成的是网状（mesh）拓扑：每个助手与每个服务之间都有一条独立连接，任意两个节点之间都可能存在一条边，连接数按 N×M 增长，故障排查需要逐条路径检查。MCP 则把结构改为星型（star）拓扑：所有助手连接到协议层，所有服务也连接到协议层，协议层充当中心枢纽。星型拓扑将连接数压缩为 N+M，同时把兼容性逻辑集中到一处，任何服务端变更只需在中心节点适配一次。代价是协议层本身成为关键路径，需要保证其稳定性和版本兼容性，这也是 MCP 在落地时需要考虑的运维问题。

工程视角：MCP解决了什么，没解决什么

MCP真正解决的是“集成拓扑”问题：把点对点的网状连接改造成星型结构，让协议层承担兼容性。

但视频素材未涉及的是，MCP并不自动处理工具语义的差异、权限边界或调用结果的可靠性——这些仍需要在服务端和助手端分别设计。

从落地角度看，MCP更适合工具生态频繁变动、多助手并存的环境。如果只有一个助手对接一个稳定API，直接调用的简单性仍有优势。

对于正在被胶水代码淹没的团队，MCP提供了一条从维护地狱抽身的路径：把N²的连接债，换成N+M的协议约定。

Schema 变更的爆炸半径指的是当服务端接口定义发生变化时，受影响的范围有多大。在传统点对点集成中，一个服务的 schema 变更会直接击穿所有依赖它的助手连接，爆炸半径等于该服务的所有下游助手数量；如果变更涉及多个服务，影响面会进一步叠加。MCP 将 schema 描述集中到服务端的工具元数据中，变更只发生在服务端一处，所有通过协议连接的助手通过重新发现机制自动获取新定义，爆炸半径收敛为“服务端自身加协议层”。但需要注意，爆炸半径缩小不等于零风险：如果变更涉及工具语义或参数含义的调整，助手端仍可能需要修改调用逻辑，因此版本管理和向后兼容策略依然必要。