跳到主要内容

MCP与REST API：根本区别

将REST API与模型上下文协议（MCP）进行比较是一种类别错误。它们在抽象的不同层次上运行，为AI系统提供根本不同的功能。

架构差异​

特性MCPREST API
状态管理有状态 - 在交互中维护上下文无状态 - 每个请求都是独立的
连接类型持久、双向连接单向请求/响应
通信风格基于JSON-RPC的持续会话基于HTTP的离散请求
上下文处理上下文是协议的内在部分上下文必须手动管理
工具发现运行时发现可用工具设计时集成，需要预先了解
集成方式运行时集成，动态能力设计时集成，需要代码修改

不同层次，不同目的​

REST API和MCP服务于技术栈的不同层次：

  1. REST：暴露资源操作的低级Web通信模式
  2. 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的方法：

  • 所有工具的统一协议
  • 维护整个工作流程的上下文
  • 新工具可以无缝替换，无需代码修改

为什么Kilo Code使用MCP​

Kilo Code利用MCP提供：

  1. 可扩展性：添加无限自定义工具，无需等待官方集成
  2. 上下文感知：工具可以访问对话历史和项目上下文
  3. 简化集成：一个标准协议，而非多种API模式
  4. 运行时灵活性：动态发现和使用新功能

MCP在Kilo Code和外部服务之间创建了通用连接器，REST API通常在这些服务背后提供支持。

结论：互补而非竞争的技术​

MCP并不取代REST API - 它建立在它们之上。REST擅长提供离散服务，而MCP擅长为AI代理编排这些服务。

关键区别在于MCP是AI原生的：它把模型视为一等用户，提供AI代理在复杂环境中有效运行所需的上下文、有状态交互层。

Is this documentation incorrect or incomplete? Report an issue on GitHub