理解 MCP 协议的数据传递：HTTP 之上的一层“壳子

以下是以 CSDN 博客的风格记录你对 MCP 协议数据传递的理解和发现，内容涵盖了 MCP 协议基于 HTTP 的本质、JSON-RPC 的“壳子”作用，以及为什么熟悉 HTTP 协议就足以理解 MCP 的数据传递。文章面向技术社区，结构清晰，适合分享。

---

理解 MCP 协议的数据传递：HTTP 之上的一层“壳子”

作者：[你的用户名]
日期：2025-04-13
标签：MCP 协议、HTTP、JSON-RPC、数据传递、AI 代理

背景

最近在研究 MCP（Model Context Protocol）协议，探索如何通过它实现 AI 代理的自动化任务，例如清理缓存文件夹。起初，我对 MCP 的数据传递机制感到困惑，因为我对数据传递的理解主要停留在 HTTP 协议的层面（例如 REST API 的 GET、POST 请求）。通过深入分析，我发现 MCP 协议的底层传输仍然是 HTTP，只不过在 HTTP 之上“套了一层壳子”——JSON-RPC 2.0 协议。这篇文章记录了我的发现和理解，分享给对 MCP 协议感兴趣的朋友。

---

发现过程

1. MCP 协议的底层传输：HTTP

MCP 协议是一个为 AI 代理设计的协议，允许 AI 代理安全地访问外部工具和数据源（例如文件系统）。通过研究，我发现 MCP 的数据传递完全依赖 HTTP 协议（）。

1.1 MCP 的 HTTP 请求和响应

MCP 服务器监听一个 HTTP 端点（例如 http://localhost:8000/mcp），AI 代理通过 HTTP POST 请求发送数据，服务器返回 HTTP 响应。以下是一个典型的 MCP 请求和响应：

• HTTP 请求（调用 list_files 工具）：

  POST /mcp HTTP/1.1
  Host: localhost:8000
  Content-Type: application/json
  
  {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "list_files",
      "arguments": {
        "path": "/path/to/cache"
      }
    }
  }

• HTTP 响应：

  HTTP/1.1 200 OK
  Content-Type: application/json
  
  {
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
      "files": [
        {"name": "temp1.log", "path": "/path/to/cache/temp1.log", "mtime": "2025-03-01T12:00:00Z"},
        {"name": "temp2.log", "path": "/path/to/cache/temp2.log", "mtime": "2025-04-01T12:00:00Z"}
      ]
    }
  }

1.2 与 HTTP API 的对比

如果你熟悉 HTTP API（例如 REST API），MCP 的数据传递模式非常相似：

• HTTP API：通过 URL 和 HTTP 方法定义操作，例如 GET /files?path=/path/to/cache 获取文件列表。

• MCP：通过 HTTP POST 发送 JSON 数据，操作定义在 JSON 的 method 字段中（例如 tools/call）。

发现：

• MCP 的底层传输就是 HTTP，与我熟悉的 HTTP API 没有本质区别。请求是 HTTP POST，响应是 HTTP 200 OK，数据格式是 JSON。

---

2. MCP 的“壳子”：JSON-RPC 2.0

虽然 MCP 的底层是 HTTP，但它在 HTTP 之上定义了一层 JSON-RPC 2.0 协议（），这就是所谓的“壳子”。

2.1 JSON-RPC 的结构

JSON-RPC 是一种轻量级的远程过程调用（RPC）协议，通过 JSON 格式定义请求和响应。MCP 使用 JSON-RPC 来封装 AI 代理与 MCP 服务器之间的通信。

• JSON-RPC 请求：

  json

  {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "list_files",
      "arguments": {
        "path": "/path/to/cache"
      }
    }
  }

  • jsonrpc：协议版本。

  • id：请求 ID，用于匹配响应。

  • method：要调用的方法（例如 tools/call）。

  • params：方法参数。

• JSON-RPC 响应：

  json

  {
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
      "files": [
        {"name": "temp1.log", "path": "/path/to/cache/temp1.log", "mtime": "2025-03-01T12:00:00Z"},
        {"name": "temp2.log", "path": "/path/to/cache/temp2.log", "mtime": "2025-04-01T12:00:00Z"}
      ]
    }
  }

  • result：成功时的返回结果。

  • 如果失败，返回 error 字段。

2.2 JSON-RPC 与 HTTP API 的对比

• HTTP API：操作通过 URL 和 HTTP 方法定义，例如 GET /files 获取文件列表，DELETE /files/temp1.log 删除文件。

• JSON-RPC：操作通过 JSON 的 method 字段定义（例如 tools/call），参数通过 params 传递，URL 通常是固定的（例如 /mcp）。

等价转换：

• JSON-RPC 请求：

  json

  {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "list_files",
      "arguments": {
        "path": "/path/to/cache"
      }
    }
  }

• 等价的 HTTP API 请求：

  GET /files?path=/path/to/cache HTTP/1.1
  Host: localhost:8000

发现：

• JSON-RPC 只是 HTTP 请求体的一种特定格式。method 相当于 HTTP API 的 URL 路径，params 相当于请求体或查询参数。熟悉 HTTP API 后，JSON-RPC 非常容易理解。

---

3. 为什么熟悉 HTTP 协议就够了？

通过对比，我发现 MCP 协议的数据传递本质上就是 HTTP 传输，只不过请求体的内容是 JSON-RPC 格式。

3.1 MCP 的数据传递流程

以清理缓存文件夹的任务为例：

1. AI 代理发送 HTTP POST 请求，调用 list_files 工具，获取文件列表。

2. MCP 服务器返回 HTTP 响应，包含文件列表（JSON 格式）。

3. AI 代理解析响应，筛选出超过 30 天的文件（例如 temp1.log）。

4. AI 代理发送另一个 HTTP POST 请求，调用 delete_file 工具。

5. MCP 服务器返回 HTTP 响应，确认删除成功。

HTTP 视角：

• 整个流程与 HTTP API 的请求-响应模式完全一致。

• 唯一不同的是，MCP 的请求体是 JSON-RPC 格式，而不是普通的 JSON 数据。

3.2 熟悉 HTTP 后需要额外关注的点

虽然熟悉 HTTP 协议就足够理解 MCP 的数据传递，但需要额外关注以下两点：

1. JSON-RPC 格式：

   • 理解 JSON-RPC 的核心字段（method、params、result 等）。

   • 把 method 看作 HTTP API 的 URL 路径，把 params 看作请求体。

2. MCP 的方法和工具：

   • MCP 定义了一些方法（例如 tools/call）和工具（例如 list_files、delete_file）。

   • 可以通过 tools/list 请求获取可用工具：

     json

     {
       "jsonrpc": "2.0",
       "id": 1,
       "method": "tools/list",
       "params": {}
     }

发现：

• 熟悉 HTTP 协议后，只需要几分钟就能学会 JSON-RPC 的格式和 MCP 的方法/工具，MCP 的数据传递就完全可以理解。

---

4. MCP 的“壳子”带来的额外功能

虽然 MCP 是在 HTTP 之上“套了个壳子”，但这个壳子带来了一些额外的功能：

1. 结构化的通信：

   • JSON-RPC 提供了统一的请求和响应格式（method、params、result），比 HTTP API 更结构化。

   • AI 代理可以更容易地解析和处理数据。

2. 支持复杂通信模式：

   • MCP 支持 Server-Sent Events（SSE）（），用于实时推送任务状态。

   • MCP 支持异步任务，AI 代理可以通过轮询或 SSE 获取任务进度。

3. 工具化的接口：

   • MCP 通过工具（例如 list_files）提供标准化的接口，AI 代理可以直接调用，无需关心底层实现。

SSE 示例：

• AI 代理订阅任务状态：

  GET /mcp/sse HTTP/1.1
  Host: localhost:8000
  Accept: text/event-stream

• 服务器推送更新：

  event: TaskStatusUpdateEvent
  data: {"taskId": "task-001", "status": "working"}

发现：

• SSE 是 HTTP 的扩展功能，如果熟悉 HTTP API 的 SSE，MCP 的实时推送模式也很容易理解。

---

5. 对比 A2A 协议：同样的“壳子”

A2A（Agent2Agent）协议也基于 HTTP 和 JSON-RPC（），但用途不同：

• MCP：AI 代理与外部工具的交互（例如文件系统），通过 tools/call 调用工具。

• A2A：代理之间的通信，通过 tasks/send 提交任务，支持协作（）。

A2A 的 HTTP 请求示例：

• 请求：

  POST /a2a HTTP/1.1
  Host: localhost:9000
  Content-Type: application/json
  
  {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tasks/send",
    "params": {
      "taskId": "task-001",
      "message": {
        "role": "user",
        "parts": [
          {"type": "TextPart", "value": "List files in /path/to/cache"}
        ]
      }
    }
  }

• 响应：

  HTTP/1.1 200 OK
  Content-Type: application/json
  
  {
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
      "taskId": "task-001",
      "status": "working"
    }
  }

发现：

• A2A 和 MCP 都基于 HTTP，数据传递方式相同（HTTP POST + JSON-RPC）。

• A2A 的“壳子”更注重任务管理和代理协作，而 MCP 的“壳子”更注重工具调用。

---

总结

通过这次研究，我对 MCP 协议的数据传递有了更清晰的理解：

1. MCP 的底层是 HTTP：MCP 的数据传递完全依赖 HTTP，与 HTTP API 的请求-响应模式一致。

2. JSON-RPC 是“壳子”：MCP 在 HTTP 之上使用 JSON-RPC 2.0 协议，定义了结构化的请求和响应格式。

3. 熟悉 HTTP 就够了：如果你已经熟悉 HTTP 协议（例如 POST 请求、JSON 数据、SSE），只需要额外理解 JSON-RPC 的格式和 MCP 的方法/工具，就能完全掌握 MCP 的数据传递。

未来计划：

• 抓包分析 MCP 的 HTTP 请求，深入理解 JSON-RPC 的细节。

• 探索 A2A 协议的通信模式（例如 SSE 和推送通知），学习更复杂的协作场景。

如果你对 MCP 协议或 HTTP 相关技术有更多想法，欢迎留言讨论！

---

参考资料

1. Anthropic 官方文档：Introducing the Model Context Protocol

2. Google A2A 协议文档：Agent2Agent Protocol Specification

3. JSON-RPC 2.0 规范：JSON-RPC 2.0 Specification

---

以上是 CSDN 风格的博客记录，总结了你的发现和理解。如果你需要调整某些部分（例如添加代码示例或截图），可以告诉我！