Nhìn nhận MCP một cách phản biện

• MCP(Model Context Protocol) cung cấp một phương thức tích hợp được chuẩn hóa để LLM tương tác với thế giới bên ngoài
• Gần đây, các tiêu chuẩn tương tự như ACP của IBM và A2A của Google xuất hiện, kéo theo số lượng triển khai MCP và các công cụ liên quan tăng nhanh
• Tuy nhiên, các thực hành kỹ thuật còn non nớt như thiết kế gây nhầm lẫn, tài liệu thiếu sót, thiếu đặc tả giao thức thực tế đang bị chỉ ra là vấn đề
• Các phương thức truyền tải hiện được đề xuất như HTTP+SSE và Streamable HTTP làm gia tăng độ phức tạp và các vấn đề bảo mật, và việc dùng WebSocket được khuyến nghị như một phương án thay thế
• Giao thức mới nhất đang bổ sung sự thiếu nhất quán và độ phức tạp quá mức trong ủy quyền và quản lý phiên

---

Xem xét MCP và các xu hướng gần đây

• MCP là một giao thức mở được tạo ra để chuẩn hóa cách các ứng dụng cung cấp ngữ cảnh cho mô hình ngôn ngữ lớn (LLM)
• Trong một tháng gần đây, MCP nổi lên như tiêu chuẩn cốt lõi để biến LLM thành agent, và việc sử dụng cũng như triển khai đang lan rộng rất nhanh
• Các tiêu chuẩn chính thống có mục đích tương tự như ACP của IBM hay A2A của Google cũng đang xuất hiện nhanh chóng

Các vấn đề về thực hành kỹ thuật và đặc tả giao thức

• Mức độ triển khai thực tế và tài liệu hóa còn thấp được bộc lộ ở nhiều nơi
• Các công ty công nghệ lớn đầu tư khổng lồ vào huấn luyện mô hình, nhưng SDK và tài liệu lại ở mức kém, gây ra sự bối rối cho người dùng
• MCP cũng cho thấy những vấn đề tương tự: một số thiết kế thiếu hợp lý, trong khi đặc tả, ví dụ và hướng dẫn vẫn còn thiếu

Bàn về giao thức truyền tải (Transport)

Phương thức truyền tải stdio

• Stdio là cách truyền thống để kết nối trực tiếp máy chủ MCP và client cục bộ qua pipe (stdout, stdin)
• Cách này ít phải xử lý socket phức tạp hay các vấn đề theo từng hệ điều hành, đồng thời cho phép cấu hình môi trường gọn nhẹ như biến môi trường và luồng vào/ra

Phương thức HTTP+SSE / Streamable HTTP

• Với ý định hỗ trợ cả nền tảng HTTP phù hợp thời đại web, các phương thức HTTP+SSE và Streamable HTTP đã được chấp nhận
• Tuy nhiên, trong khi nhắm tới việc thay thế WebSocket, cách này lại gây ra nhiều mơ hồ, rối rắm trong thiết kế và độ phức tạp hơn
• Một phiên và kết nối có thể được tạo hoặc kết thúc theo nhiều cách khác nhau, tạo gánh nặng lớn cho việc quản lý trạng thái và bảo mật phía máy chủ

Khó khăn trong các trường hợp triển khai máy chủ/client MCP

• Vấn đề hỗ trợ còn yếu ở nhiều ngôn ngữ, như việc thiếu Go SDK chính thức, là điều đặc biệt nổi bật
• Do tài liệu và đặc tả không rõ ràng, nhiều trường hợp phải triển khai thông qua reverse engineering
• Dù các máy chủ mẫu chủ yếu dựa trên Python, JavaScript, nhưng các vấn đề về phụ thuộc và tính khả chuyển khiến khó áp dụng vào môi trường làm việc thực tế
• Khi triển khai máy chủ, SSE/Streamable HTTP cố giả lập socket, nhưng trên thực tế rất khó duy trì nhất quán trạng thái phiên và kết nối, đồng thời còn cần hạ tầng riêng như hàng đợi thông điệp

Cấu trúc và vấn đề của HTTP+SSE và Streamable HTTP

Chế độ HTTP+SSE

• Client mở một phiên SSE với máy chủ, rồi khi gửi yêu cầu ghi tới một endpoint riêng, máy chủ trả về phản hồi 202 và gửi kết quả qua kết nối SSE hiện có
• Việc duy trì đồng bộ trạng thái và kết nối phiên là cần thiết, nhưng quá trình này vừa thiếu tài liệu vừa có độ phức tạp vận hành rất cao

Chế độ Streamable HTTP

• Tạo phiên, mở SSE, truyền phản hồi đều bị trộn lẫn theo nhiều cách, khiến luồng một yêu cầu ~ phản hồi không còn nhất quán
• Nhiều lớp quản lý trạng thái cùng tồn tại, nhiều endpoint và cách dùng header đan xen, tạo ra trở ngại nghiêm trọng cho khả năng triển khai thực tế và mở rộng

Hàm ý chung

• Cùng với việc độ phức tạp kỹ thuật tăng lên, gánh nặng nhận thức và bảo trì của lập trình viên cũng lớn hơn, đồng thời nảy sinh các vấn đề như không tương thích, hành vi khó đoán trước giữa nhiều cách triển khai máy chủ và client
• Máy chủ phải theo dõi mọi trạng thái và tình huống kết nối; trong môi trường phân tán, việc mở rộng hiệu quả và đồng bộ trạng thái càng trở nên khó khăn hơn

Hàm ý về bảo mật

• Các cách kết nối/phiên đa dạng và vi mô làm gia tăng các lỗ hổng bảo mật trong quản lý trạng thái như chiếm quyền phiên, tấn công phát lại, từ chối dịch vụ (DoS)
• Nhiều điểm vào và nhiều cách phản hồi mở rộng bề mặt tấn công, đồng thời có thể cho phép che giấu hoạt động độc hại qua những luồng ngoài dự kiến

Sự rối rắm trong giao thức quản lý quyền hạn (Authorization)

• Đặc tả hiện tại áp dụng các quy tắc thiếu nhất quán, chẳng hạn chỉ bắt buộc OAuth2 với truyền tải HTTP, còn truyền tải STDIO thì tùy ý dùng biến môi trường
• Điều này tạo ra sự khó hiểu và bất hợp lý, ví dụ như tại sao chỉ truyền tải HTTP lại bị ép phải triển khai OAuth2 phức tạp

Đề xuất hướng cải thiện

• Cần đơn giản hóa về một giao thức JSON RPC thống nhất, với phương thức truyền tải thực chất chỉ tập trung vào Stdio và WebSocket
• Cách tiếp cận phù hợp là ánh xạ biến trong môi trường Stdio thành header trong môi trường HTTP, còn đầu vào/đầu ra thì ánh xạ tương ứng thành các luồng hai chiều của WebSocket
• Nhờ đó có thể loại bỏ việc theo dõi phiên không cần thiết, quản lý trạng thái và vô số xử lý ngoại lệ
• WebSocket nên trở thành lựa chọn tiêu chuẩn cho mọi truyền tải dựa trên HTTP, đồng thời cũng giải quyết được các vấn đề đồng bộ trạng thái phức tạp

So sánh với các giao thức thay thế và xu hướng thị trường

• ACP của IBM và A2A của Google cung cấp thiết kế Transport gọn gàng hơn và khả năng khám phá agent tốt hơn về mặt liên thông giữa các agent
• Nhưng về bản chất, phần lớn chúng vẫn chỉ ở mức có thể được tích hợp như công cụ riêng trong môi trường xây dựng MCP
• Việc các giao thức mới tiếp tục xuất hiện có nguy cơ dẫn tới sự phân mảnh tiêu chuẩn, vì vậy ưu tiên sự đơn giản của Transport là điều quan trọng cho tăng trưởng của ngành

[GN⁺]

Ý kiến trên Hacker News

• Tôi tin chắc lý do tài liệu do các nhà cung cấp LLM viết lại gây rối là vì chính họ đang dùng LLM để viết tài liệu, đây là một cách tiếp cận rất tệ, đặc biệt việc dùng LLM cho công việc viết đặc tả còn tệ hơn nhiều so với dùng LLM để viết tài liệu thông thường, bản thân quá trình viết đặc tả mới là cốt lõi, điều quan trọng là các nhà thiết kế con người phải suy nghĩ kỹ để tìm ra lỗi, chỗ thiếu sót và xử lý các trường hợp, nhưng ở đặc tả MCP tôi không thấy nhiều dấu vết của kiểu trăn trở mang tính con người đó, phong cách nhạt nhòa đặc trưng, sự lan man và cách tổ chức thiên về liệt kê đúng là sản phẩm do LLM viết
  • Vấn đề của tài liệu DeepSeek lại là có quá nhiều lỗi chính tả và ngữ pháp, thật kỳ lạ khi một công ty suốt ngày làm việc với ngôn ngữ, từng có lúc sở hữu cả LLM tiếng Anh hàng đầu thế giới, mà vẫn không tạo ra được tài liệu trông đủ chuyên nghiệp theo tiêu chuẩn nghề nghiệp
  • Tôi cũng có cảm giác rất mạnh rằng đặc tả này là do LLM viết, mọi bằng chứng đều chỉ về điều đó, tôi đoán phần lớn sản phẩm hiện nay đều đã được tạo ra kiểu lấy trung bình những kết quả nghe có vẻ hợp lý nhất để khoe với nhà đầu tư phục vụ IPO
  • Nếu điều đó là thật thì thực sự đáng buồn, Anthropic có rất nhiều người tài, vậy mà chuyện này lại xảy ra ở một thành phần cốt lõi của hệ sinh thái quan trọng thì đúng là đáng tiếc
  • Giờ tôi mới nghĩ ra rằng các nhà cung cấp AI coding có thể có động cơ cố tình làm cho tài liệu khó hiểu, bằng cách tạo ra mã mà con người không hiểu được và chỉ AI của họ mới giải thích nổi, họ sẽ khiến người dùng phụ thuộc hoàn toàn vào dịch vụ AI riêng của mình, nếu trong vòng 2 năm họ không thể thay thế hoàn toàn lập trình viên thật thì chiến lược này sẽ khiến người tiêu dùng biến mất hết và làm sụp luôn cả thị trường của họ, cuối cùng chỉ còn lại một đống mã khổng lồ mà con người và AI không thể chuyển đổi qua lại
  • Khi đọc văn xuôi do LLM viết, tôi cảm thấy sự tập trung bị phá vỡ, và có lẽ đó không chỉ là vấn đề riêng của tôi, kiểu câu chữ lặp đi lặp lại và thiếu ngữ cảnh do máy tạo ra không chứa đựng suy nghĩ sâu sắc, thậm chí ngày càng gây mệt mỏi về cảm xúc, khi chính kiểu LLM này còn viết cả đặc tả kỹ thuật thì rốt cuộc những nội dung ngay cả tác giả cũng không hiểu sẽ vô thức bị trộn vào, điều đó khiến tôi ngày càng lo ngại
  • Tài liệu của DeepSeek nhìn chung có vẻ không tệ, trông như được làm rất nhanh nhưng vẫn ở mức ổn, điều này có thể là ngoại lệ cho lập luận rằng cứ để LLM viết tài liệu thì đều tệ
• Dạo này lĩnh vực LLM đang bắt chước rất nhanh các mô thức phần mềm như thể dùng cheat code vậy, cách phơi bày hàm từ xa đã có rất nhiều ví dụ trong quá khứ như DLL, gRPC, SOAP, IDL, dCOM, thế mà phe LLM hiện tại dường như còn chẳng biết những thứ đó tồn tại, tôi kỳ vọng theo thời gian mọi thứ sẽ trưởng thành hơn nhưng rốt cuộc vẫn phải xử lý phần bài tập còn lại
  • Chắc chỉ vài tháng nữa là sẽ trưởng thành hơn thôi, nhưng nhìn vào hệ sinh thái Python thời kỳ đầu lại gợi nhớ cảnh các sai lầm bị cố định ở tầng dưới của stack rồi mọi người cứ tiếp tục chất thêm công cụ mới lên trên, lần này càng đáng buồn hơn vì đã có cả lịch sử những sai lầm y hệt trong quá khứ mà hệ sinh thái AI vẫn đi đúng lối đó
  • Lần đầu tiếp xúc với MCP tôi nghĩ ngay đến COM/DCOM, rồi nhớ tới thời DLL Hell ngày xưa, tôi sẽ tiếp tục xem MCP rồi sẽ vận hành ra sao
  • Tôi vẫn chưa tìm được lời giải thích nào giúp hiểu chính xác MCP là gì, và tò mò không biết nếu gọi theo ngôn ngữ phát triển trước đây thì nó sẽ là gì
  • Tôi muốn chỉ ra rằng trong những giao thức chặt chẽ và mang tính khai báo như thế này, không gian hàm nghĩa tiềm năng và thế mạnh ngữ nghĩa của LLM lại bị loại bỏ, có khi chỉ cần đặt file agents.json ở web root rồi để các agent tự giải quyết thông qua đối thoại ngữ nghĩa còn trực quan hơn, kết quả là HTTP trở thành đầu vào/đầu ra chuẩn cho agent
  • Tôi nghĩ tất cả các ví dụ được nêu ra đều phù hợp
  • Tôi thắc mắc liệu MPC có dựa trên JSON-RPC không
• Tôi đồng ý với toàn bộ bài viết, đặc biệt là chia sẻ trải nghiệm bối rối khi không thể tìm được thông tin thực chất trên trang MCP, RFC thì khó đọc nhưng vẫn tốt hơn rất nhiều so với kiểu “cứ dùng SDK đi”
  • Tôi ước nhiều người nhận ra tầm quan trọng của bài blog này, nên tạm dừng việc áp dụng MCP và xem lại xem liệu nó có nền tảng kỹ thuật thực sự vững chắc hay không, hiện có rất nhiều sự cuồng nhiệt nhưng nếu đi sâu vào giai đoạn triển khai thực tế sẽ thất vọng, nhiều quyết định cốt lõi như WebSocket đều gây nghi ngờ, không phải tất cả nhưng nhìn chung có cảm giác như một giải pháp chắp vá làm vội
  • Thật đáng tiếc khi trang web không có một đặc tả rõ ràng, có cảm giác một nửa đặc tả được Sonnet sinh ra, và cách giao thức thật sự vận hành không được mô tả minh bạch, so với nó thì đặc tả GraphQL được viết tốt hơn nhiều
• Hiện nay phần lớn công việc trong lĩnh vực AI đang do các nhà toán học, nhà khoa học (dữ liệu), sinh viên và những người đam mê nghiệp dư đảm nhiệm, xét theo tiêu chuẩn của kỹ sư phần mềm chuyên nghiệp thì nhiều thứ còn chưa trưởng thành, trông như dự án cuối tuần
  • Cá nhân tôi nghĩ các kỹ sư phần mềm chuyên nghiệp thực ra vẫn đang làm phần lớn công việc
• MCP lẽ ra ngay từ đầu nên đi theo hướng stateless HTTP, phần lớn máy chủ không cần duy trì trạng thái, chỉ cần lưu trạng thái toàn cục hoặc có session identifier là đủ
  • Tôi không hiểu cấu trúc tương tác thực sự của MCP, tại sao nó không phải là stateless, và tại sao phải giữ kết nối mở liên tục
  • Kinh nghiệm cá nhân của tôi chưa nhiều, nhưng nếu đóng kết nối sau mỗi request thì phải kết nối lại cho request tiếp theo, còn nên giữ session mở hay đóng thì phụ thuộc vào nhiều biến số như mô thức sử dụng, mức tiêu thụ bộ nhớ, v.v.
• Tôi đang xây dựng một dịch vụ MCP tên là ninja.ai dựa trên Ruby on Rails, đây là một app store cài đặt máy chủ MCP chỉ với một cú nhấp chuột, nó cài máy chủ Model Context Protocol lên thiết bị khách bằng Tauri, đồng thời cung cấp cả máy chủ MCP trên cloud bằng Rails, tôi có cái nhìn phê phán với HTTP+SSE hay Streamable HTTP, với giao tiếp thời gian thực hai chiều thì WebSockets tốt hơn, và do hỗ trợ SSE của Rails bị hạn chế nên tôi phải migrate endpoint sang web server Falcon, tôi tò mò vì sao các kỹ sư Shopify lại chọn Streamable HTTP, có thể là do ràng buộc về hạ tầng/triển khai, cũng cần lưu ý rằng tầng vận chuyển của MCP được trừu tượng hóa, nên các triển khai tương lai hoàn toàn có thể mở sang WebSockets hoặc WebRTC
• Tôi là người vận hành một trong các MCP registry (glama.ai/mcp/servers), tôi đồng ý một phần với tác giả nhưng giao thức này vẫn còn ở giai đoạn rất sớm nên trong tương lai có thể thay đổi khá nhiều, nó nhận được sự chú ý lớn hơn nhiều so với dự đoán, từ vài chục máy chủ ban đầu tăng vọt lên hàng nghìn máy chủ ngay ở giai đoạn cực sớm, nhưng trong số đó chỉ một phần thực sự hoạt động nên tôi tốn rất nhiều thời gian để sàng lọc, đây là hiện tượng xảy ra vì MCP thu hút sự chú ý của công chúng trước khi kịp trưởng thành, tuy nhiên gần đây hệ sinh thái như framework mã nguồn, registry, client hỗ trợ MCP phát triển nhanh đến mức đáng kinh ngạc, chỉ trong nửa năm mà có thay đổi như vậy là điều chưa từng có, nếu xu hướng này tiếp tục thì tôi nghĩ triển vọng khá sáng sủa, tôi cũng cung cấp một bộ tài liệu hữu ích cho người mới bắt đầu
  • Nếu mắc sai lầm ở giai đoạn đầu của thiết kế giao thức thì sẽ phải mang theo sai lầm đó mãi mãi, nên cần xây dựng đặc tả với sự khiêm tốn, một cấu trúc kiểu Goldberg với SSE có thể không sửa nổi và bị giữ lại vĩnh viễn, ở cấp độ enterprise thì bất kỳ thay đổi phá vỡ giao thức nào cũng không hề dễ nên có thể bị mắc kẹt rất lâu với các quyết định ban đầu mà không thể sửa
  • Bản thân giao thức MCP thì đương nhiên sẽ tiếp tục phát triển theo thời gian, nếu kỳ vọng nó hoàn thiện ngay từ đầu mới là điều lạ, hơn hết việc chuẩn hóa agentic API thực sự là một thay đổi rất mạnh, bạn phải tự trải nghiệm việc chỉ cần viết và triển khai mã rồi AI lập tức nhận ra và tự động dùng được thì mới cảm nhận rõ
  • Điều tôi lo là với tốc độ này, liệu mcp có chấp nhận quá sớm một thiết kế tầng vận chuyển đáng ra phải bền vững rất lâu hay không, nó khiến tôi nhớ đến các tiêu chuẩn phân mảnh kéo dài thời chiến tranh trình duyệt thập niên 90, như việc IE11 tồn tại quá lâu
• Tranh cãi liên quan đến quyền hạn (Authentication) đã được cập nhật, họ đã phối hợp với Anthropic và cộng đồng bảo mật để triển khai việc tách vai trò resource server (RS) và authorization server (AS) trong MCP, đồng thời công bố trước một bản đặc tả nháp tạm thời cho đến khi phiên bản giao thức mới được chính thức hóa
  • Tôi tò mò không biết tỷ lệ nào trong đặc tả MCP là đầu ra của LLM, những tín hiệu cảnh báo cứ hiện ra liên tục khiến tôi tự hỏi liệu mình chỉ đang linh cảm theo bản năng hay không
  • Tôi giữ lập trường tương đối trung lập, nhưng cảm giác như họ chỉ sao chép qua loa bản nháp OAuth, và tôi không hài lòng với cấu trúc khi đã dùng HTTP thì không có lựa chọn nào khác ngoài việc phải tuân theo, thực ra họ có thể viết rõ hơn để cả client và server mỗi bên đều có thể hỗ trợ OAuth2 một cách tùy chọn
• Liên quan đến việc phát hành Streamable HTTP của MCP, tôi từng mở issue hỏi liệu có thể biến mọi thứ thành các HTTP request thông thường hay không, đặc tả MCP có triển vọng như một lời giải phổ quát để nối LLM với công cụ, nhưng trên thực tế nó vấp phải rất nhiều khó khăn như xác thực, streaming, lệnh tùy biến theo từng công cụ, xác minh độ tin cậy của công cụ, v.v., tôi thấy tích hợp chỉ bằng REST API thực ra đơn giản hơn, OpenAI hay Gemini cũng nói sẽ áp dụng MCP nhưng tôi đoán sớm muộn gì đặc tả này cũng sẽ va vào những điểm không khớp ở UI, tầng tương tác và các chỗ mà đặc tả không mong muốn, dẫn đến chuyện không hợp với thương hiệu hoặc phát sinh vấn đề như bị chiếm đoạt xác thực
  • Dù Anthropic có xây dựng MCP đi nữa thì quy mô của họ vẫn nhỏ hơn hẳn so với ChatGPT, tôi nghi ngờ liệu các ông lớn như OpenAI hay Google có chấp nhận lâu dài một đặc tả do một nhóm bên ngoài đặt ra giới hạn cho trải nghiệm người dùng hay không, đã từng có tiền lệ như ChatGPT Plugins thất bại không phải vì kỹ thuật không hay mà vì giới hạn của trải nghiệm tiêu dùng, dù vậy tôi vẫn sẵn sàng kỳ vọng vào sức mạnh của cộng đồng
  • Sau khi đăng blog, tôi cũng từng trực tiếp để lại một issue tương tự, vì đây là chuyện thực sự quan trọng nên nếu làm sai sẽ rất khó quay lại
• Tôi thấy khó hiểu vì sao MCP lại nổi lên đến vậy, nhưng dù sao nó cũng là xu hướng, tôi muốn nghe giải thích xem so với đặc tả OpenAPI thì MCP tốt hơn ở điểm nào
  • Theo tôi, phần lớn độ phổ biến của MCP đến từ việc khả năng dùng công cụ của LLM gần đây thực sự đã tốt hơn, plugin OpenAI năm 2023 thất bại vì khi đó LLM chưa đủ đáng tin để dùng công cụ, còn MCP thì ra đời đúng thời điểm hơn nhiều
  • Một yếu tố lớn khác là việc khởi động máy chủ MCP lần đầu rất dễ và rào cản gia nhập thấp, khi công cụ nhiều lên thì lượng văn bản gửi cho LLM cũng tăng, nhưng nếu cung cấp OpenAPI cùng chi tiết từng endpoint và thông điệp mô tả thì Claude vẫn có thể tích hợp rất tốt
  • Một trong những lý do MCP quan trọng là OpenAPI là tài liệu tĩnh nên LLM phải tự chịu trách nhiệm tạo toàn bộ quá trình request, còn máy chủ MCP giảm gánh nặng đó nhờ lớp trừu tượng, kết quả là từ góc nhìn của LLM thì nó dễ hơn, nhanh hơn và an toàn hơn
  • Tôi không cho rằng MCP là hoàn hảo, nhưng nó có vài điểm phù hợp với LLM hơn OpenAPI, trước hết các công cụ MCP có thể được đặc tả ngắn gọn và đơn giản hơn nhiều, còn đặc tả OpenAPI quá lớn nên chiếm ngữ cảnh của LLM quá mức, LLM thực chất không tạo lời gọi thật mà chỉ sinh văn bản đầu ra nên cách làm của MCP tự nhiên hơn, và MCP cũng linh hoạt hơn nhiều với cấu trúc động như thêm hoặc thay đổi công cụ, vượt qua giới hạn tĩnh của OpenAPI, dĩ nhiên vẫn có vấn đề rõ ràng, đặc biệt là tầng vận chuyển còn nhiều chỗ có thể cải thiện, nhưng các thư viện đại diện cũng đã được triển khai khá tốt rồi