对比
MCP 与普通 API 的区别
你手上已经有一个 REST 接口了。这不代表它就是 MCP 服务端——而且大多数情况下，它也完全不需要变成。
先记住一句话
普通 API 是写给应用代码用的。调用方早就知道该打哪个接口、返回长什么样——因为有个开发读过文档、把它接好了。
MCP 服务端是写给模型在运行时挑的。这个能力必须把自己描述清楚，清楚到一个 agent 能判断该不该调它； 返回结果也必须足够结构化，让模型不需要开发者在中间翻译就能用。
真正的差别
API 假设调用方已经被告知该干什么；MCP 假设调用方必须自己判断该干什么。这一个前提差异，几乎解释了后面所有区别。
并排看
| 维度 | 普通 API | MCP 服务端 |
|---|---|---|
| 主要调用方 | 应用代码 | 代表模型行事的 AI 客户端 |
| 谁来选接口 | 开发者在构建时决定 | 模型在运行时决定 |
| 发现方式 | 读文档 | 能力在协议内直接描述给客户端 |
| 契约形式 | 接口、方法、返回结构 | 工具名、描述、输入与输出 schema |
| 错误设计 | 给代码分支用的状态码 | 给模型推理的消息，外加"要不要重试" |
| 鉴权 | 由调用方应用处理 | 必须显式，因为调用方不是人 |
| 典型受众 | 一个负责集成的团队 | 作者从没见过的多个客户端 |
普通 API 缺了什么
把现成接口交给 agent 之前，通常有三样东西是缺的。
自我描述模型没法可靠地读你的 OpenAPI 文件去推测意图。工具描述必须写清楚什么时候该用、什么时候不该用。
安全边界API 往往默认调用方是可信的。而 agent 可能出于错误的原因调错东西，所以最小权限和确认流程更重要。
可读的失败一个带嵌套校验对象的 422 对代码没问题，但模型需要的是"哪里错了、再试一次有没有用"。
什么情况下包一层才划算
1
该由模型挑，而不是开发者写死
如果"打哪个接口"真的取决于用户说了什么，那么用一个描述清楚的能力让模型自己选，比写死分支更好。
2
多个 agent 要接同一个系统
一个 MCP 服务端可以服务多个客户端。给每个 agent 单独写定制集成，成本通常高于统一暴露一次。
3
你需要比原 API 更窄的能力面
API 可能有四十个接口，而 agent 可能永远只需要其中三个，并且权限应当比原 API 更紧。
什么情况下不需要
如果调用完全是确定性的，就别加服务端。你的应用永远知道该打哪个接口、带什么参数，那么 MCP 服务端只是在 你和结果之间多加了一层。
还有一种情况值得先停下：接口返回的是大块非结构化数据，工具描述再怎么努力也救不回来。这时应该在服务端做好 过滤和裁剪，暴露一个 agent 真正能推理的能力，而不是把一个没人用得好、原样包一层就完事的接口推给模型。