你可能已经用 REST 把业务接口跑通了，现在想接 MCP 让模型用上这些能力，却不确定该重写一套还是加个壳：两边到底差在哪，什么时候该各用各的。这篇不铺概念，按设计目标、调用方式、状态与鉴权、工程落地四个角度做对照，给判断标准和可执行动作，具体数字与清单请到站内对应页面核对。
REST 你大概率已经很熟了：定路径、定方法、定参数，前端或别的服务照着文档调就行。问题出在接 MCP 的时候——你希望模型能自己挑能力、自己填参数，可 REST 那套接口描述是写给人看的，模型读不懂隐含语义。所以这不是谁替代谁，而是两层东西：REST 管资源，MCP 管「模型能做什么」。
这篇按设计目标、调用方式、状态鉴权、工程落地四个角度做对照，每节都给判断标准和能上手的动作。涉及具体模型、价格、基线数字的地方，一律让你去站内对应页面看当时的数字，别拿这篇当数据源。
设计目标不一样：给人写的接口 vs 给模型用的能力
REST 的出发点是「资源」：一个 URL 代表一样东西，HTTP 方法决定你怎么动它，语义靠文档和约定固定下来，调用方是人写好的代码。MCP 的出发点是「能力」：服务端在连接时告诉客户端我这边有哪些工具、哪些资源、哪些提示模板，客户端（通常是模型所在的宿主程序）在运行时再决定用哪个。一个偏静态契约，一个偏动态发现。
| 对比项 | REST API | MCP |
|---|---|---|
| 组织单位 | 资源与路径 | 工具、资源、提示三类原语 |
| 调用方 | 已写死的代码 | 运行时才决定的模型或宿主 |
| 能力发现 | 靠读文档、写死在代码里 | 连接时由服务端自报清单 |
| 语义约定 | HTTP 方法与状态码 | 工具描述里的名字、参数、用途 |
| 变更影响 | 改接口要改调用方 | 改描述可能直接影响模型选不选它 |
- 调用方是固定代码、参数提前确定——REST 够用，没必要加壳
- 调用方是不确定的模型、需要运行时挑能力，才值得上 MCP
- 只服务自家前端或内部服务的接口，硬套 MCP 只会多一层抽象
- 对外要过网关、审计、限流的接口，仍以 REST 为主入口更省事
调用方式对照：请求结构、发现机制与返回值
REST 的调用流程是：读文档 → 拼 URL、方法、参数 → 发请求 → 看状态码和响应体。MCP 多一步：先建立连接并拿到能力清单，再按清单里的描述挑一个工具，填参数调过去，拿回来的是给模型继续推理用的结构化结果。多出来的这一步「发现」，正是模型能自己干活的前提，也是你最容易踩坑的地方。
- 先对齐描述和真实接口把 MCP 工具描述里的参数名、类型、是否必填，逐条和原 REST 接口对上。名字不一致、类型对不上，模型大概率传错参数。
- 再确认传输通路确认客户端能连上服务端，本地进程还是远程连接，失败现象不同。连不通就先别查业务逻辑。
- 最后看返回能否被解析模型需要能读懂返回值。如果返回的是嵌套很深或字段名含糊的结构，要么在工具层转成清晰结构，要么就别指望模型用得好。
返回值这块差异最容易被忽略：REST 返回资源和状态码，调用方自己判成败；MCP 的返回值是给模型看的，错误信息写得含糊，模型就会自己脑补一个结果继续往下跑。所以工具层的错误提示要写成模型能理解的自然语言。
# 排查顺序示例：先验证通路，再验证参数，最后验证返回
# 1) 本地起服务，确认客户端能连上（看连接日志有没有握手成功）
# 2) 用固定参数单独调一次工具，确认参数名和类型对得上
# 3) 拿返回结果看结构，确认字段名和含义对模型友好状态、鉴权与传输：别把两套约定混在一起
REST 基本是无状态的，一次请求带一次凭证，网关层就能把限流、审计做完。MCP 连接本身有生命周期：要先初始化、协商能力，这会话期间服务端记着客户端的情况。这两套约定混着用，最常见的后果是鉴权边界糊了——把 REST 的长期密钥直接塞给模型。
- 无状态请求
- REST 的典型形态，一次请求独立完成，凭证放 Header
- 会话语义
- MCP 连接需要初始化和能力协商，连接本身是有生命的
- 鉴权边界
- 长期密钥不该暴露给模型，应由服务端或客户端进程注入
- 传输通路
- 本地进程与远程连接的失败现象和检查项不一样，别用同一套排错法
- 不要在工具描述里写密钥，描述是给模型读的
- 凭证让服务端自己管，或者由客户端进程在调用时注入
- 会话要设过期时间，别让一个连接长期挂着
- 对外公开的接口仍走 REST 网关，MCP 只做内部封装层
把长期密钥交给模型，等于把保险箱钥匙贴在门上。
工程落地：超时、并发、降级与日志怎么分别设
上了 MCP 之后，超时和并发不能再用 REST 那一套参数。REST 超时基本就是「一次请求多久回来」，MCP 要拆成两段：连上服务端的耗时，和工具真正执行的耗时。混成一个数，出问题时你分不清是模型慢、连接慢，还是后端接口慢，排查方向全乱。
| 关注点 | REST 常见做法 | MCP 要额外考虑 |
|---|---|---|
| 超时 | 单次请求超时 | 连接超时与工具执行超时分开设 |
| 并发 | 网关层限流排队 | 限制单会话内同时在跑的工具数 |
| 降级 | 返回错误码由调用方处理 | 明确失败让模型换路径，别静默返回空 |
| 日志 | 请求路径、状态码、耗时 | 会话标识、工具名、入参摘要、结果状态都要记 |
| 回归 | 固定用例打接口 | 挑真实任务跑，比较走 MCP 与直调 REST 的成功率和耗时 |
并发这点最容易被低估：REST 时代一个请求打一个接口，你在网关限流就行；MCP 里模型可能一次挑好几个工具并行跑，背后是好几路请求同时打你的后端。不限单会话内的并行数，数据库连接池会被打爆。
- 单会话内同时在跑的工具数设上限，超出就排队
- 工具失败时返回明确错误，让模型知道要换路径
- 日志把会话标识、工具名、入参摘要、耗时、结果状态都记上
- 回归测试挑真实任务，看走 MCP 和直调 REST 的成功率差多少
- 跑完回归去站内评测页面核对当时的基线数字，别凭感觉判断变好变坏
常见问题
已经有 REST 接口了，还有必要再封一层 MCP 吗？
看你是否要让模型自己决定调哪个能力。如果调用顺序和参数在代码里写死，REST 直接调更省事；如果希望模型在运行时按任务挑工具、拼参数，MCP 的描述发现机制才有价值。两条路可以并存，不必二选一。
MCP 能完全替代 REST 吗？
不能，也不该这么用。MCP 解决的是模型与能力之间的发现和调用约定，底层多半还是走 REST 或 RPC。对外暴露、需要网关鉴权和审计的接口，仍应以 REST 为主，MCP 更适合做内部的能力封装层。
两个一起用时最容易踩什么坑？
最常见的是工具描述和真实接口对不上，模型按描述传参结果后端报错；其次是超时只设了一个值，分不清是连接慢还是执行慢；再就是失败被静默吞掉，模型拿不到错误信息只能硬编。建议先统一入参 schema，再分开设超时，最后把失败显式返回。
