MCP 与 REST API：根本性的区别
将 REST API 与 Model Context Protocol (MCP) 进行比较是一种分类错误。它们在 AI 系统中运行于不同的抽象层级，服务于根本不同的目的。
架构差异
| 特性 | MCP | REST API |
|---|---|---|
| 状态管理 | 有状态 - 在交互过程中保持上下文 | 无状态 - 每个请求相互独立 |
| 连接类型 | 持久、双向连接 | 单向请求/响应 |
| 通信方式 | 基于 JSON-RPC 的持续会话 | 基于 HTTP 的离散请求 |
| 上下文处理 | 上下文是协议的内在特性 | 上下文需手动管理 |
| 工具发现 | 运行时发现可用工具 | 设计时集成，需要预先了解 |
| 集成方式 | 运行时集成，具备动态能力 | 设计时集成，需要代码更改 |
不同层级，不同用途
REST API 与 MCP 在技术栈中服务于不同的层级：
- REST：低级 Web 通信模式，用于暴露资源上的操作
- MCP：高级 AI 协议，用于协调工具使用并维护上下文
MCP 经常在内部使用 REST API，但对 AI 隐藏了这些细节。可以将 MCP 视为中间件，它将离散的 Web 服务转换为 AI 可以运行的统一环境。
上下文保持：AI 工作流的关键
MCP 的有状态设计解决了 REST 在 AI 应用中的一个关键限制：
- REST 方式：每次调用相互隔离，需要在步骤间手动传递上下文
- MCP 方式：一次对话上下文在多次工具使用中持续存在
例如，AI 调试代码库时，可以打开文件、运行测试并识别错误，而无需在步骤间丢失上下文。MCP 会话会保持对之前操作和结果的感知。
动态工具发现
MCP 使 AI 能够在运行时发现和使用工具：
// AI 发现可用工具
{
"tools": [
{
"name": "readFile",
"description": "从文件中读取内容",
"parameters": {
"path": { "type": "string", "description": "文件路径" }
}
},
{
"name": "createTicket",
"description": "在问题跟踪器中创建工单",
"parameters": {
"title": { "type": "string" },
"description": { "type": "string" }
}
}
]
}
这种"即插即用"能力允许在不重新部署或修改 AI 本身的情况下添加新工具。
真实世界示例：多工具工作流
考虑一个需要多个服务的任务："检查最近的提交，为 bug 修复创建 JIRA 工单，并发布到 Slack。"
基于 REST 的方式：
- 需要分别为 Git、JIRA 和 Slack API 集成
- 需要自定义代码在调用间管理上下文
- 如果任何服务更改其 API，集成就会中断
基于 MCP 的方式：
- 所有工具使用统一协议
- 在整个工作流中保持上下文
- 可以在不更改代码的情况下交换新工具
Roo Code 为何使用 MCP
Roo Code 利用 MCP 提供：
- 可扩展性：无需等待官方集成即可添加无限的自定义工具
- 上下文感知：工具可以访问对话历史和项目上下文
- 简化的集成：一个标准协议，而不是多种 API 模式
- 运行时灵活性：可以即时发现和使用新功能
MCP 在 Roo Code 与外部服务之间创建了一个通用连接器，而 REST API 通常在后台为这些服务提供支持。
结论：互补而非竞争的技术
MCP 不会取代 REST API——它建立在 REST API 之上。REST 擅长提供离散服务，而 MCP 擅长为 AI 代理协调这些服务。
关键区别在于 MCP 是 AI 原生的：它将模型视为一等用户，提供 AI 代理在复杂环境中有效运行所需的上下文化、有状态交互层。