第一次认真看 MCP（Model Context Protocol）的时候，我的第一反应是：又来一个协议？ REST 不够用吗？给模型写个 API 适配层不就行了吗？
带着这个怀疑去研究了很久，现在算是想通了它到底在解决什么问题。这篇笔记记的就是这个"从质疑到理解"的过程。
先看问题：N×M 集成地狱
假设你有 3 个大模型平台（OpenAI、Claude、国产模型），想让它们各自接入 4 个工具（搜索、数据库、文件系统、代码执行）。
没有标准协议的话，你要写 3 × 4 = 12 个适配层。每加一个模型，要写 4 个新适配；每加一个工具，要写 3 个新适配。
模型有 N 个，工具有 M 个，集成工作量就是 N×M。这个乘法在模型和工具都快速膨胀的今天，是不可持续的。
这和早年 USB 接口出现之前的情况一模一样——打印机是并口、鼠标是串口、键盘是 PS/2、相机是 IEEE 1394。每个设备一种接口，每台电脑一堆线。USB 出来之后，所有设备统一接一种口。
MCP 想做的事就是这个：给"模型连接外部世界"定一个统一的口。Anthropic 的官方比喻是"AI 的 USB-C 接口"，我觉得很准确。
架构：比我预想的简单
我原本以为 MCP 会很复杂——毕竟要处理各种模型和工具的异构性。看完规范后发现它其实只有三层：
- Host：跑模型的那一方——比如 Claude Desktop、一个 IDE、或者你自己写的 Agent 应用
- Client：Host 内部的连接器，负责和 Server 通信。一个 Host 可以有多个 Client，每个 Client 对应一个 Server
- Server：提供能力的那一方——比如一个暴露数据库查询的 Server、一个暴露 GitHub 操作的 Server
关系是：Host 通过多个 Client 连接多个 Server。每个 Server 独立运行，向 Host 声明"我能提供什么能力"。
这个设计最妙的地方在于解耦——Server 的开发者不需要关心模型是谁、Host 是什么，只需要按 MCP 规范暴露能力。Host 的开发者不需要为每个工具写适配层，只需要支持 MCP 协议本身。
N×M 变成了 N+M。每个模型只需要实现一次 MCP Client，每个工具只需要实现一次 MCP Server。
三种能力原语
MCP 定义了三种"能力"——Server 可以选择性地暴露其中一种或多种：
Tools（工具）——模型可以调用的函数。比如"查询数据库""发送邮件""执行代码"。这是最常用的类型，对应 Function Calling 里的"函数"。
Resources（资源）——模型可以读取的数据。比如一个文件的内容、一个数据库的 schema、一份文档。和 Tools 的区别是：Resources 是"读"，Tools 是"做"。Resources 让模型能看到上下文相关的信息，但不产生副作用。
Prompts（提示模板）——预定义的提示词模板。Server 可以提供一些"现成的问法"，用户在 Host 里可以快速调用。这个用得比较少，但思路有意思——把 prompt 也作为一种可分发的资源。
我在实践中最常用的是 Tools。Resources 偶尔用于"让模型看看数据库结构再写查询"这种场景。Prompts 目前几乎没用过，感觉更像是面向终端用户（而不是面向开发者）的功能。
和传统 API 的本质区别
看架构的时候我一直在想：这不就是把 REST API 包了一层 JSON-RPC 吗？和直接给模型一个 OpenAPI 规范让它调用有什么区别？
想了很久，我觉得区别在三个地方：
1. 面向对象不同。REST API 面向的是开发者——假设调用方懂 HTTP、懂鉴权、懂错误处理。MCP 面向的是模型——Server 要用模型能理解的方式描述自己（每个工具的 name、description、参数 schema 都是为模型的工具选择服务的）。这个差别看起来微妙，但设计出来的系统完全不一样。
2. 状态管理不同。REST 是无状态的——每次请求独立。MCP 是有会话的——Client 和 Server 之间保持连接，Server 可以维护状态、推送通知。这让一些需要上下文的工具（比如"先连接数据库，再执行多条查询，最后断开"）更自然。
3. 发现机制不同。REST API 需要开发者先读文档、手动配置。MCP Server 启动后会主动告诉 Host"我有什么能力"，Host 把这些能力注入模型的工具列表，模型自动就能用。零配置接入。
但说实话，这些区别在技术层面都不是革命性的。MCP 的真正价值是标准化带来的生态效应——一旦大部分模型平台都支持 MCP（目前 OpenAI 和 Anthropic 都支持了），大部分工具都提供 MCP Server（目前 GitHub、Slack、数据库等都有官方或社区实现），"即插即用"就成立了。
协议本身不复杂。复杂的是让所有人达成共识。MCP 做的最难的事不是技术，是让行业跟它走。
实践中的一些感受
用了一段时间 MCP 之后，几个真实感受：
好处是真实的。之前给 Agent 加一个新数据源，要写适配层、测连通性、处理错误。现在找一个现成的 MCP Server，配置一下就能用。开发体验确实提升了一个量级。
但工具选择准确率下降了。之前手写适配层时，我会精心设计工具列表——只有几个工具、每个描述都很精确。MCP 接入后，工具列表一下子膨胀（一个 GitHub Server 就暴露几十个工具），模型选错的概率明显上升。
这让我意识到一个之前忽略的问题：MCP 解决的是"接入"问题，不是"选择"问题。工具多了之后，怎么帮模型找到对的那个，是另一个层面的事（Skill 系统就是干这个的，后面单独写一篇）。
安全是个大问题。MCP 让接入工具变得太容易了——找一个社区的 MCP Server 装上就能用。但这些 Server 的代码质量、安全边界，谁来保证？一个恶意的 Server 完全可以在响应里注入指令（prompt injection），让模型做不该做的事。目前我对 MCP Server 的态度是：只用官方的或知名社区维护的，不装来路不明的。
还没想明白的问题
1. MCP 会成为最终标准吗？
目前看趋势是好的——OpenAI 也宣布兼容了。但历史上"统一协议"的竞争往往不止一个玩家（想想 CORBA vs COM、SOAP vs REST）。Google 和其他厂商会不会推自己的协议？我不知道。但目前 MCP 的生态位确实最稳。
2. Server 会不会成为新的"中间件怪物"？
每个 MCP Server 都是一个独立进程，都要维护、监控、更新。当你的 Agent 接了 20 个 Server，运维负担不小。未来会不会出现"MCP Server 网关"——用一个网关统一管理所有 Server 的鉴权、路由、监控？我觉得大概率会。
3. Resources 和 Prompts 到底该怎么用？
Tools 的用法已经很清楚了，但 Resources 和 Prompts 的最佳实践我还比较模糊。看过一些案例，但没形成自己的判断。这块还要继续实践。
小结
MCP 解决的核心问题是：把"模型连接工具"从 N×M 的定制开发，变成 N+M 的标准化对接。
技术上它不复杂——一个 JSON-RPC 协议加三种能力原语。它的价值在于时机和共识——在模型平台和工具生态同时爆发的节点上，大家都需要一个统一标准，MCP 先站住了。
对于做企业内部 Agent 的团队，我的建议是：新项目直接用 MCP 做 tool 层，别再手写适配层。但要对 Server 的来源保持谨慎——安全边界永远比接入便利更重要。