Nhìn nhận MCP một cách phê phán

• MCP là một giao thức dựa trên JSON-RPC nhằm giúp LLM/Agent làm việc với công cụ bên ngoài và nguồn dữ liệu theo cách tiêu chuẩn, nhưng bị chỉ trích vì thiết kế truyền tải qua HTTP và chất lượng tài liệu làm tăng gánh nặng triển khai
• Điểm gây tranh cãi lớn nhất là khi triển khai giao tiếp hai chiều đơn giản trên HTTP, nó đã gián tiếp tái dựng hành vi gần giống WebSocket bằng HTTP+SSE và Streamable HTTP
• Streamable HTTP chia nhỏ việc tạo phiên, kết nối SSE và đường chuyển phản hồi thành nhiều nhánh, làm tăng gánh nặng quản lý trạng thái, gỡ lỗi, khả năng tương tác, khả năng mở rộng và bảo mật
• Truyền tải HTTP đi kèm yêu cầu cấp quyền tập trung vào OAuth2, trong khi stdio lại được thiết kế để lấy thông tin xác thực từ biến môi trường, khiến mô hình xác thực thay đổi theo từng phương thức truyền tải
• Truyền tải HTTP nên được đơn giản hóa bằng WebSocket, vốn gần nhất với luồng vào/ra của stdio, và thiết kế nên được tối ưu cho các trường hợp sử dụng phổ biến thay vì ngoại lệ

---

MCP đang lan rộng rất nhanh

• MCP(Model Context Protocol) là một giao thức mở chuẩn hóa cách ứng dụng cung cấp ngữ cảnh cho LLM
• Anthropic ví MCP như cổng USB-C của ứng dụng AI, mô tả nó là cách tiêu chuẩn để kết nối mô hình AI với nhiều nguồn dữ liệu và công cụ khác nhau
• Trong khoảng một tháng gần đây, MCP lan rộng rất nhanh, và MCP Server cùng Client mới được tạo ra mỗi ngày, có thể xem trên các trang như mcp.so và pulsemcp.com
• IBM công bố Agent Communication Protocol(ACP) như một “tiêu chuẩn trực giao” với MCP, còn Google cũng giới thiệu Agent2Agent(A2A)
• Điểm bị phê phán cốt lõi là các công ty lớn sẵn sàng chi rất nhiều cho huấn luyện và tinh chỉnh mô hình, nhưng mức độ hoàn thiện của tài liệu, SDK và hướng dẫn triển khai lại còn thấp

Bản thân giao thức và tầng truyền tải

• MCP là một giao thức JSON-RPC với các method và endpoint được định nghĩa sẵn để dùng cùng LLM
• Các phương thức truyền tải chính được chia thành stdio gần với chạy cục bộ và truyền tải dựa trên HTTP

  • stdio

    • Khởi động MCP Server cục bộ, nối các pipe stdout, stdin với Client để trao đổi JSON, và dùng stderr cho logging
    • Việc dùng mô hình pipe của Unix/Linux cho giao tiếp hai chiều vẫn có thể bị phê phán, nhưng nó hoạt động dễ dàng trên mọi hệ điều hành và không cần xử lý socket nên khá dễ hiểu

  • Truyền tải dựa trên HTTP

    • Đây là cách chạy trên HTTP, gồm HTTP+SSE và Streamable HTTP được đưa ra để thay thế nó
    • Cả hai cách đều cố triển khai trao đổi thông điệp hai chiều đơn giản bằng tổ hợp request HTTP và kết nối SSE, khiến độ phức tạp tăng lên

Phê phán HTTP+SSE và Streamable HTTP

• Cách truyền tải HTTP hiện có là HTTP+SSE(Server-Sent Events), và trong đặc tả mới nó được định thay bằng Streamable HTTP
• HTTP+SSE để tạo full duplex sẽ để Client mở một phiên SSE chỉ-đọc bằng request như GET /sse, nhận URL chỉ-ghi trong phản hồi đầu tiên, rồi gửi request như POST /a-endpoint?session-id=1234
  • Server trả về 202 Accepted với phần thân rỗng
  • Phản hồi thực tế phải được đọc từ kết nối /sse đã mở sẵn
• Streamable HTTP xử lý session ID bằng HTTP header thay vì endpoint riêng, và có thể mở phiên SSE bằng GET hoặc POST /mcp
  • Phản hồi có thể đến qua một luồng SSE mới
  • Có thể đến trong phần thân phản hồi POST với 200
  • Hoặc có thể được gửi sau qua một trong các luồng SSE đã có
• Thiết kế này gần với cấu trúc muốn hoạt động như WebSocket trên SSE, và lập luận cho việc không dùng WebSocket thực sự đã được thảo luận trong modelcontextprotocol/pull/206
• Truyền tải HTTP cố mô phỏng stdio nhưng vì không phải socket thực sự, phần triển khai server phải gánh thêm việc ghép nối(join) nhiều lời gọi HTTP và kết nối khác nhau

Vấn đề về tài liệu và SDK bộc lộ qua trải nghiệm triển khai

• Khi thử triển khai MCP Server bằng Go, không có Go SDK chính thức và để hiểu giao thức thì trên thực tế gần như phải reverse engineer
• Tài liệu trên modelcontextprotocol.io bỏ qua hoặc thiếu các chi tiết giao thức quan trọng, đồng thời cũng không cung cấp ví dụ về luồng hội thoại
• Website có xu hướng dẫn người đọc sang tutorial triển khai SDK hơn là giúp đọc hiểu bản thân tiêu chuẩn
• Server mẫu được viết bằng Python hoặc JavaScript và giả định sẽ chạy cục bộ qua stdio
  • Python và JavaScript bị phê phán là lựa chọn không tốt cho công cụ cục bộ cần chạy ổn định trên máy người khác
  • Việc các ví dụ cũng được cung cấp dưới dạng container Docker cho thấy dường như vấn đề này phần nào đã được nhận ra
• Với việc chạy MCP cục bộ, các ngôn ngữ có tính di động cao hơn hoặc lựa chọn dựa trên VM như Rust, Go, Java, C# được cho là phù hợp hơn

Độ phức tạp do Streamable HTTP tạo ra

• Trong Streamable HTTP, có thể tạo phiên mới theo ba cách
  • Request GET rỗng
  • Request POST rỗng
  • Request POST chứa lời gọi RPC
• SSE cũng có thể được mở theo bốn đường khác nhau
  • GET để khởi tạo
  • GET để tham gia lại một phiên trước đó
  • POST để khởi tạo phiên
  • POST chứa request và nhận phản hồi qua SSE
• Phản hồi request lại có thể được chuyển theo ba cách
  • Phản hồi HTTP của POST chứa lời gọi RPC
  • Sự kiện SSE được mở để phản hồi cho chính POST đó
  • Một sự kiện SSE bất kỳ đã được mở từ trước
• Khi có quá nhiều đường khác nhau để đạt cùng một kết quả, gánh nặng nhận thức, độ khó gỡ lỗi và chi phí bảo trì đều tăng lên
• Nếu Client và Server mỗi bên chỉ triển khai một phần mà họ cho là cần thiết, sẽ phát sinh vấn đề tương tác và có thể dẫn tới hành vi ngoài dự kiến
• Trong cấu hình server trải trên nhiều máy, việc quản lý trạng thái kết nối và cơ chế chuyển phản hồi có thể trở thành nút thắt về khả năng mở rộng

Vấn đề bảo mật và cấp quyền

• Tính linh hoạt của Streamable HTTP làm nảy sinh nhiều lo ngại bảo mật
  • Quản lý trạng thái phiên trải trên HTTP và SSE là phức tạp, có thể tạo ra nguy cơ chiếm phiên, tấn công phát lại và DoS
  • Việc có nhiều điểm vào cho tạo phiên và kết nối SSE làm mở rộng bề mặt tấn công
  • Sự đa dạng trong cách khởi tạo phiên và chuyển phản hồi có thể bị lợi dụng để che giấu hoạt động độc hại
• Đặc tả authorization trong giao thức mới nhất khuyến nghị các triển khai truyền tải HTTP tuân theo đặc tả đó
• Cũng trong đặc tả này, các triển khai truyền tải STDIO được khuyến nghị không nên tuân theo đặc tả đó mà thay vào đó lấy thông tin xác thực từ môi trường
• Cấu trúc này dẫn đến phàn nàn rằng nếu dùng truyền tải HTTP thì phải triển khai quy trình OAuth2, trong khi với stdio có vẻ chỉ cần mức truy cập kiểu API key

Đề xuất: đơn giản hóa truyền tải HTTP bằng WebSocket

• MCP có một giao thức JSON-RPC duy nhất, và stdio dường như là phương thức truyền tải được ưu tiên rõ ràng
• Truyền tải HTTP nên được làm cho giống stdio nhất có thể, và chỉ khác đi khi thật sự cần thiết
• Biến môi trường của stdio có thể tương ứng với HTTP header trong HTTP
• Luồng vào/ra kiểu socket của stdio có thể tương ứng với WebSocket trong HTTP
• Dùng WebSocket có thể giảm bớt quản lý trạng thái phức tạp giữa các server cho phiên làm việc và nhiều corner case
• Tuy vậy, việc cấp quyền có thể phức tạp hơn trong một số trường hợp, một số firewall có thể chặn WebSocket, các phiên ngắn có thể phát sinh overhead, và việc nối lại phiên bị ngắt cũng khó hơn
• Bản thân đặc tả MCP cũng nêu rằng đây là giao thức transport-agnostic có thể được triển khai trên bất kỳ kênh truyền thông nào hỗ trợ trao đổi thông điệp hai chiều
• Ngành nên tối ưu cho các trường hợp sử dụng phổ biến nhất, thay vì cho các corner case

Đánh giá bổ sung về ACP và A2A

• MCP là giao thức để phơi bày API cho LLM, còn ACP và A2A gần với giao thức để phơi bày Agent cho LLM hơn
• Khi xem đặc tả A2A, nhu cầu thực tế có vẻ khá hạn chế, và nhiều tính năng của A2A dường như có thể xử lý bằng chính MCP hoặc chỉ cần bổ sung nhỏ
• ACP và A2A có thể được triển khai như công cụ của MCP Server hơn là như giao thức riêng biệt
• IBM cũng đưa ra góc nhìn trong tài liệu MCP adapter rằng ACP Agent có thể được xem là tài nguyên MCP và được gọi như công cụ MCP
• ACP bị đánh giá là mang màu sắc quảng bá cho công cụ xây dựng agent của IBM là BeeAI
• Ưu điểm mà ACP và A2A mang lại là tầng truyền tải hoàn chỉnh hơn và cách khám phá Agent