Giao thức MCP đối mặt với làn sóng chỉ trích về việc thiếu các tính năng doanh nghiệp và lỗ hổng bảo mật

Giao thức Model Context Protocol ( MCP ), được thiết kế để chuẩn hóa các tương tác công cụ AI, đang đối mặt với làn sóng chỉ trích ngày càng gia tăng từ các nhà phát triển và kiến trúc sư doanh nghiệp, những người cho rằng nó thiếu các tính năng cơ bản cần thiết cho việc triển khai sản xuất. Giao thức này, tự định vị mình như USB-C cho AI, đã gây ra cuộc tranh luận gay gắt về việc liệu tính đơn giản của nó có đến với cái giá quá cao cho các ứng dụng nghiêm túc hay không.

Mối quan ngại về Type Safety và xác thực dữ liệu

Một trong những cuộc thảo luận gay gắt nhất xoay quanh cách tiếp cận xác thực dữ liệu của MCP. Các nhà phê bình chỉ ra rằng giao thức sử dụng JSON không có schema với các gợi ý kiểu tùy chọn, cho phép các lỗi thời gian chạy có thể có hậu quả thảm khốc. Trong các dịch vụ tài chính, điều này có thể có nghĩa là các thuật toán giao dịch hiểu sai độ chính xác số. Trong y tế, dữ liệu bệnh nhân có thể được xử lý không chính xác, có khả năng ảnh hưởng đến các khuyến nghị liều lượng thuốc.

Tuy nhiên, những người ủng hộ lập luận rằng MCP có hỗ trợ xác thực JSON Schema, và việc triển khai đúng cách sẽ phát hiện những lỗi này trước khi chúng đến mô hình AI. Cuộc tranh luận làm nổi bật sự căng thẳng cơ bản giữa tính linh hoạt và an toàn trong thiết kế giao thức.

So sánh Giao thức MCP với các Hệ thống RPC Đã Được Thiết lập

Các khoảng trống hoạt động doanh nghiệp

Cộng đồng đã xác định một số tính năng quan trọng còn thiếu khiến MCP không phù hợp cho các triển khai quy mô lớn. Phân bổ chi phí nổi bật như một mối quan ngại lớn - khi các tổ chức nhận được hóa đơn API đáng kể từ các dịch vụ như OpenAI, họ không thể truy vết công cụ MCP hoặc người dùng cụ thể nào đã tạo ra những chi phí đó. Việc thiếu khả năng hiển thị này khiến việc tối ưu hóa chi tiêu hoặc hiểu các mô hình sử dụng tài nguyên trở nên không thể.

Distributed tracing đưa ra một thách thức đáng kể khác. Trong khi các giao thức đã được thiết lập như gRPC cung cấp correlation ID tích hợp và theo dõi yêu cầu qua các dịch vụ, MCP không cung cấp cách chuẩn hóa nào để gỡ lỗi các vấn đề trải rộng trên nhiều hệ thống. Các nhà phát triển báo cáo rằng việc khắc phục sự cố mất vài phút với các giao thức khác có thể kéo dài hàng ngày với MCP.

Các Tính Năng Doanh Nghiệp Chính Còn Thiếu Trong MCP

• Service Discovery: Không có cơ chế cho việc mở rộng quy mô động hoặc các tình huống chuyển đổi dự phòng
• Quản Lý Phiên: Các hoạt động có trạng thái/không trạng thái hỗn hợp mà không có ngữ nghĩa thử lại rõ ràng
• Tối Ưu Hóa Hiệu Suất: Giao thức dựa trên văn bản tạo ra các điểm nghẽn cổ chai cho các ứng dụng có thông lượng cao
• Audit Logging: Không có định dạng chuẩn hóa cho các yêu cầu tuân thủ
• Quản Lý Phiên Bản: Các thay đổi giao diện công cụ có thể làm hỏng client mà không có cảnh báo
• Resource Quotas: Không có khả năng giới hạn tốc độ hoặc quản lý hạn ngạch tích hợp sẵn

Vấn đề phân mảnh

Một vấn đề đặc biệt gây tranh cãi là sự phụ thuộc của MCP vào các thư viện bên thứ ba để lấp đầy các khoảng trống chức năng. Thay vì xây dựng các tính năng thiết yếu như xác thực và giám sát vào giao thức cốt lõi, hệ sinh thái phụ thuộc vào các tiện ích mở rộng được cộng đồng duy trì khác nhau. Cách tiếp cận này tạo ra cái mà các nhà phê bình gọi là một chòm sao các thư viện bên thứ ba mà các doanh nghiệp phải đánh giá, duy trì và bảo mật một cách độc lập.

Khi bạn giải quyết các yêu cầu doanh nghiệp bằng một chòm sao các thư viện bên thứ ba, bạn không xây dựng một giao thức. Bạn đang xây dựng một công thức cho sự phân mảnh.

Sự phân mảnh mở rộng đến sự không nhất quán triển khai qua các ngôn ngữ lập trình. Không có các ràng buộc chuẩn hóa, các triển khai Python và JavaScript của MCP có thể xử lý dữ liệu khác nhau, dẫn đến các vấn đề tích hợp tinh tế chỉ xuất hiện dưới các điều kiện cụ thể.

Bài học từ lịch sử giao thức

Cuộc thảo luận đã rút ra các so sánh với các chu kỳ phát triển giao thức trước đây. Nhiều nhà phát triển lưu ý rằng ngành công nghiệp có xu hướng từ bỏ các giao thức phức tạp nhưng giàu tính năng để ủng hộ các lựa chọn thay thế đơn giản hơn, chỉ để dần dần khám phá lại tại sao những tính năng đó lại cần thiết. Mô hình này đã diễn ra với quá trình chuyển đổi từ SOAP sang REST API, và bây giờ dường như đang lặp lại với MCP.

Một số thành viên cộng đồng lập luận rằng tính đơn giản của MCP thực sự là điểm mạnh của nó, cho phép áp dụng và lặp lại nhanh chóng. Họ cho rằng các tính năng còn thiếu có thể được thêm vào theo thời gian khi giao thức trưởng thành. Những người khác lo lắng rằng việc trang bị thêm các khả năng quan trọng sau khi áp dụng rộng rãi tạo ra những vấn đề tương tự đã dẫn đến sự phức tạp của SOAP.

Tình trạng hiện tại và triển vọng tương lai

Bất chấp những chỉ trích, MCP tiếp tục được áp dụng, đặc biệt trong các môi trường thử nghiệm và phát triển. Những người duy trì giao thức đã bắt đầu giải quyết một số mối quan ngại, gần đây đã thêm hỗ trợ cho các chú thích công cụ phân biệt giữa các hoạt động chỉ đọc và phá hoại. Tuy nhiên, nhiều tính năng quan trọng cho doanh nghiệp vẫn vắng mặt khỏi đặc tả cốt lõi.

Cuộc tranh luận phản ánh những căng thẳng rộng lớn hơn trong ngành AI giữa việc di chuyển nhanh chóng để tận dụng các cơ hội và xây dựng cơ sở hạ tầng mạnh mẽ, sẵn sàng sản xuất. Khi các tổ chức ngày càng triển khai các hệ thống AI cho các ứng dụng quan trọng, áp lực giải quyết những hạn chế giao thức cơ bản này có thể sẽ tăng cường.

Cuộc thảo luận cộng đồng cho thấy rằng trong khi MCP có thể đủ cho các trường hợp sử dụng thử nghiệm hiện tại, các tổ chức lập kế hoạch triển khai AI nghiêm túc nên đánh giá cẩn thận xem giao thức có đáp ứng các yêu cầu hoạt động của họ hay không hoặc liệu họ có cần triển khai các hệ thống bảo vệ và giám sát bổ sung.

Tham khảo: Why MCP's Disregard for 40 Years of RPC Best Practices Will Burn Enterprises