为什么传统 RESTful API 对 AI 显得别扭？
REST 协议是为确定性的客户端程序设计的：客户端明确知道要在何时发起什么 URL 请求并获得什么状态码。
然而在 AI 驱动的场景中：
- 大模型需要严格的自描述上下文（Self-describing Context）：每个工具的入参含义与前置约束必须能够作为 Schema 一并传输给模型；
- 需要双向通知与即时中断；
- MCP 把资源（Resources）与能力（Tools）天然融合，避免了传统 API 中需要无数次来回往返获取接口定义的繁琐开销。
两者不是替代关系
一个常见误解是“上了 MCP 就要把 REST 换掉”。实际上二者处在不同层：REST 面向的是“已经知道要调用什么”的确定性客户端，MCP 面向的是“需要自己判断该调用什么”的大模型。底层业务系统大多仍以 REST 或 gRPC 暴露能力，MCP 更像是包在外面、给模型看的一层自描述适配壳。理解这层关系，可以先看 MCP 核心抽象剖析：Tools、Resources 与 Prompts 的设计哲学与协同，它讲清了 MCP 用哪几类抽象去承接“能力”和“上下文”。
逐维度对比
| 维度 | 传统 RESTful API | MCP |
|---|---|---|
| 设计对象 | 确定性程序 | 需要自描述上下文的大模型 |
| 调用决策 | 由写死的代码决定 | 由模型依据 Schema 推断 |
| 接口发现 | 靠人工文档，反复往返 | 工具与资源随连接自动暴露 |
| 通信方向 | 请求—响应为主 | 支持双向通知与中断 |
| 状态语义 | 无状态、靠状态码 | 有会话生命周期与状态机 |
| 典型错误处理 | 靠调用方分支逻辑 | 可把错误回灌给模型重试 |
“错误回灌重试”这一行值得展开：REST 返回 4xx 时，客户端逻辑通常是硬编码分支；而 MCP 场景下，参数校验失败可以把结构化的错误原因原样交回模型，让它修正参数再试。这一差异的底层机制，与 深度拆解 Model Context Protocol 规范：JSON-RPC 2.0 传输与全生命周期状态机 描述的请求生命周期直接相关。
什么时候仍该用 REST
并非所有场景都要往 MCP 迁。以下情况坚持用 REST 更合理：调用方是固定程序、不需要模型自行决策；对延迟极度敏感、容不下一轮模型推理；能力边界稳定、没有“让模型自由组合工具”的需求。反过来说，当你要把一堆分散的内部接口，交给一个会自主规划的 Agent 去按需调用时，MCP 的自描述与融合优势才真正兑现。选型前不妨先把“协议层”和“能力封装层”的区别想清楚，再决定某项能力用哪种方式暴露。
从现有 REST 平滑迁移
对已有大量接口的团队，重写成本高，更现实的路径是自动生成适配层：先从 OpenAPI/Swagger 规范批量转出 MCP 工具定义，再针对模型易错的入参补充自然语言约束与示例。这类转换工具能把“接口秒变工具”的启动成本压到很低，具体流程可参考站内 OpenAPI 与 Swagger 规范自动转 MCP Server：让现有接口秒变 AI 工具。迁移后要用真实任务验证一件事：模型能否只看 Schema 就选对工具、填对参数——这才是衡量适配层质量的标准，而不是接口搬运了多少个。
常见问题速查
| 现象/疑问 | 原因/背景 | 处理/建议 |
|---|---|---|
| 接了 MCP 反而更慢 | 每步都多一层模型推理 | 高频固定调用保留 REST 直连 |
| 模型选错工具 | 工具描述过于含糊 | 补前置条件、示例与命名规范 |
| 已有接口不知怎么暴露 | 缺自描述壳 | 用 OpenAPI 自动转 MCP 打底 |
| 长任务无法中断 | 沿用同步请求—响应 | 走 MCP 双向通知与取消 |
| 不确定要不要全量迁移 | 误以为二者互斥 | 只给需要模型自主调用的能力上 MCP |
小结
MCP 与 REST 的取舍，用一句话判据收口：调用决策是人写死的，就用 REST；调用决策要交给模型临场判断，就给能力套上 MCP。不要把“支持 AI”误解成“把所有接口都改造成 MCP”——真正需要自描述、双向通知与工具/资源融合的，只是那些要暴露给自主 Agent 的部分。先把这一小撮高价值能力迁好、并用真实任务验证模型能选对工具，比铺全量适配层更有意义。