Giao thức truyền thông của MCP

MCP định nghĩa một giao thức truyền thông chuẩn để client và server trao đổi thông điệp theo cách nhất quán, dễ đoán. Việc chuẩn hoá này là yếu tố then chốt cho khả năng tương tác (interoperability) trong cộng đồng. Trong bài này, chúng ta sẽ tìm hiểu cấu trúc giao thức và các cơ chế truyền tải (transport) mà MCP sử dụng.

JSON-RPC: nền móng

Về cốt lõi, MCP dùng JSON-RPC 2.0 làm định dạng thông điệp cho mọi trao đổi giữa client và server. JSON-RPC là một giao thức gọi thủ tục từ xa (remote procedure call) gọn nhẹ, được mã hoá bằng JSON, nhờ đó nó:

• Dễ đọc với con người và dễ gỡ lỗi
• Không phụ thuộc ngôn ngữ, có thể cài đặt trong bất kỳ môi trường lập trình nào
• Đã phổ biến, có đặc tả rõ ràng và được dùng rộng rãi

Giao thức định nghĩa ba loại thông điệp:

1. Yêu cầu (request)

Do client gửi tới server để bắt đầu một thao tác. Một thông điệp request gồm:

• Một định danh duy nhất (id)
• Tên phương thức cần gọi (ví dụ tools/call)
• Tham số cho phương thức (nếu có)

Ví dụ request:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "weather",
    "arguments": {
      "location": "San Francisco"
    }
  }
}

2. Phản hồi (response)

Do server gửi về client để trả lời một request. Một thông điệp response gồm:

• Cùng id với request tương ứng
• Hoặc result (khi thành công), hoặc error (khi thất bại)

Ví dụ response thành công:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "temperature": 62,
    "conditions": "Partly cloudy"
  }
}

Ví dụ response lỗi:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32602,
    "message": "Invalid location parameter"
  }
}

3. Thông báo (notification)

Thông điệp một chiều, không cần phản hồi. Thường do server gửi tới client để cập nhật tiến độ hoặc báo về các sự kiện.

Ví dụ notification:

{
  "jsonrpc": "2.0",
  "method": "progress",
  "params": {
    "message": "Processing data...",
    "percent": 50
  }
}

Cơ chế truyền tải

JSON-RPC quy định định dạng thông điệp, còn MCP quy định thêm cách các thông điệp này được truyền giữa client và server. Có hai cơ chế truyền tải chính:

stdio (Standard Input/Output)

Transport stdio dùng cho giao tiếp cục bộ, khi client và server chạy trên cùng một máy.

Ứng dụng host khởi chạy server như một tiến trình con (subprocess) và giao tiếp với nó bằng cách ghi vào standard input (stdin) và đọc từ standard output (stdout) của tiến trình đó.

Ưu điểm chính của transport này: đơn giản, không cần cấu hình mạng và được hệ điều hành cô lập (sandbox) an toàn.

HTTP + SSE (Server-Sent Events) / Streamable HTTP

Transport HTTP+SSE dùng cho giao tiếp từ xa, khi client và server có thể nằm trên các máy khác nhau.

Việc giao tiếp diễn ra qua HTTP, trong đó server dùng Server-Sent Events (SSE) để đẩy cập nhật tới client qua một kết nối duy trì liên tục.

Ưu điểm chính của transport này: hoạt động qua mạng, cho phép tích hợp với dịch vụ web và tương thích với môi trường serverless.

Các bản cập nhật gần đây của chuẩn MCP đã giới thiệu hoặc hoàn thiện "Streamable HTTP". Cơ chế này linh hoạt hơn: server có thể chủ động nâng cấp lên SSE để stream khi cần, đồng thời vẫn tương thích với môi trường serverless.

Vòng đời tương tác

Ở phần trước, chúng ta đã bàn về vòng đời của một lần tương tác đơn lẻ giữa client (💻) và server (🌐). Giờ hãy xem vòng đời của một phiên tương tác hoàn chỉnh giữa client và server trong giao thức MCP.

Giao thức MCP định nghĩa một vòng đời tương tác có cấu trúc giữa client và server:

Khởi tạo (initialization)

Client kết nối tới server, hai bên trao đổi phiên bản giao thức và khả năng (capability); server trả lời bằng phiên bản giao thức và các capability mà nó hỗ trợ.

Client xác nhận việc khởi tạo đã hoàn tất bằng một thông điệp notification.

Khám phá (discovery)

Client hỏi thông tin về các capability hiện có và server trả về danh sách các tool khả dụng.

Quá trình này có thể lặp lại cho từng loại tool, resource hoặc prompt.

Thực thi (execution)

Client gọi các capability dựa trên nhu cầu của host.

Kết thúc (termination)

Kết nối được đóng một cách êm thấm khi không còn cần nữa, và server xác nhận yêu cầu tắt (shutdown).

Client gửi thông điệp exit cuối cùng để hoàn tất việc kết thúc.

Sự phát triển của giao thức

Giao thức MCP được thiết kế để dễ mở rộng và thích ứng. Giai đoạn khởi tạo có bước thương lượng phiên bản, giúp giữ tương thích ngược khi giao thức thay đổi. Ngoài ra, cơ chế khám phá capability cho phép client thích ứng với các tính năng cụ thể mà mỗi server cung cấp, nhờ đó server cơ bản và server nâng cao có thể cùng tồn tại trong một hệ sinh thái.

Nguồn

• Dịch và biên tập từ huggingface/mcp-course · units/en/unit1/communication-protocol.mdx, giấy phép Apache-2.0.