以下是以 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 的數據傳遞流程
以清理緩存文件夾的任務為例:
-
AI 代理發送 HTTP POST 請求,調用 list_files 工具,獲取文件列表。
-
MCP 服務器返回 HTTP 響應,包含文件列表(JSON 格式)。
-
AI 代理解析響應,篩選出超過 30 天的文件(例如 temp1.log)。
-
AI 代理發送另一個 HTTP POST 請求,調用 delete_file 工具。
-
MCP 服務器返回 HTTP 響應,確認刪除成功。
HTTP 視角:
-
整個流程與 HTTP API 的請求-響應模式完全一致。
-
唯一不同的是,MCP 的請求體是 JSON-RPC 格式,而不是普通的 JSON 數據。
3.2 熟悉 HTTP 后需要額外關注的點
雖然熟悉 HTTP 協議就足夠理解 MCP 的數據傳遞,但需要額外關注以下兩點:
-
JSON-RPC 格式:
-
理解 JSON-RPC 的核心字段(method、params、result 等)。
-
把 method 看作 HTTP API 的 URL 路徑,把 params 看作請求體。
-
-
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 之上“套了個殼子”,但這個殼子帶來了一些額外的功能:
-
結構化的通信:
-
JSON-RPC 提供了統一的請求和響應格式(method、params、result),比 HTTP API 更結構化。
-
AI 代理可以更容易地解析和處理數據。
-
-
支持復雜通信模式:
-
MCP 支持 Server-Sent Events(SSE)(),用于實時推送任務狀態。
-
MCP 支持異步任務,AI 代理可以通過輪詢或 SSE 獲取任務進度。
-
-
工具化的接口:
-
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 協議的數據傳遞有了更清晰的理解:
-
MCP 的底層是 HTTP:MCP 的數據傳遞完全依賴 HTTP,與 HTTP API 的請求-響應模式一致。
-
JSON-RPC 是“殼子”:MCP 在 HTTP 之上使用 JSON-RPC 2.0 協議,定義了結構化的請求和響應格式。
-
熟悉 HTTP 就夠了:如果你已經熟悉 HTTP 協議(例如 POST 請求、JSON 數據、SSE),只需要額外理解 JSON-RPC 的格式和 MCP 的方法/工具,就能完全掌握 MCP 的數據傳遞。
未來計劃:
-
抓包分析 MCP 的 HTTP 請求,深入理解 JSON-RPC 的細節。
-
探索 A2A 協議的通信模式(例如 SSE 和推送通知),學習更復雜的協作場景。
如果你對 MCP 協議或 HTTP 相關技術有更多想法,歡迎留言討論!
參考資料
-
Anthropic 官方文檔:Introducing the Model Context Protocol
-
Google A2A 協議文檔:Agent2Agent Protocol Specification
-
JSON-RPC 2.0 規范:JSON-RPC 2.0 Specification
以上是 CSDN 風格的博客記錄,總結了你的發現和理解。如果你需要調整某些部分(例如添加代碼示例或截圖),可以告訴我!