MCP: Hệ thống plugin phổ dụng (một cách tình cờ)

• USB-C có giá trị không chỉ vì dùng để sạc và truyền tệp, mà còn ở tính phổ dụng có thể mở rộng sang nhiều mục đích khác nhau
• MCP(Model Context Protocol) ban đầu được thiết kế cho trợ lý AI, nhưng trên thực tế có thể trở thành một hệ thống plugin phổ dụng kết nối mọi nguồn dữ liệu và công cụ
• Giống như trường hợp NFT Base64, giao thức có thể mở rộng vượt ra ngoài mục đích ban đầu để trực tiếp lưu trữ và khai thác dữ liệu trong thế giới thực
• Càng có nhiều máy chủ MCP, mỗi ứng dụng càng có thể dễ dàng mang về nhiều chức năng đa dạng mà không cần tích hợp riêng
• Giống như USB-C, MCP cũng sẽ trở thành một 'không gian khả năng nơi có thể kết nối mọi thứ', làm nền tảng cho những đổi mới không ngờ tới

---

MCP: An (Accidentally) Universal Plugin System (Or: The Day My Toaster Started Taking Phone Calls)

USB-C và tính phổ dụng ngoài dự kiến

• Ai cũng nghĩ USB-C chỉ dùng để sạc hoặc truyền tệp, nhưng nhờ chính cấu trúc của nó, nó có thể mở rộng sang nhiều mục đích khác nhau
• Câu chuyện người bạn Rex của tác giả nối máy nướng bánh mì với màn hình, khiến máy nướng bánh có đầu ra HDMI, cho thấy khả năng vô hạn của USB-C
• Đó là vì USB-C có cấu trúc cho phép kết nối bất cứ thứ gì miễn là đầu cắm khớp nhau, mà không cần quá bận tâm tới chuẩn điện năng và dữ liệu

Nguyên lý của ổ châm thuốc trên ô tô

• Ổ châm thuốc trên ô tô ban đầu dùng để châm thuốc lá, nhưng giờ đã trở thành một cổng cấp nguồn phổ dụng cho nhiều mục đích khác nhau
• Giống như ổ châm thuốc, giao thức không giới hạn lựa chọn của người dùng mà cho phép nhiều cách sử dụng đa dạng
• MCP cũng có khả năng mở rộng tương tự

Tái khám phá MCP: vô tình trở thành hệ thống plugin phổ dụng

• Thông thường, MCP(Model Context Protocol) được biết đến là công cụ giúp các trợ lý AI (ví dụ: Claude) sử dụng dữ liệu
• Tài liệu chính thức cũng nêu rõ rằng nó "kết nối các mô hình AI với nhiều nguồn dữ liệu và công cụ theo cách tiêu chuẩn hóa"
• Nhưng nếu loại bỏ yếu tố AI, MCP sẽ trở thành cách để "bất cứ thứ gì" kết nối với các nguồn dữ liệu và công cụ khác nhau
• Điều này khiến nó, bất kể mục đích ban đầu, trở thành một giao thức kết nối phổ dụng

Sự khai sáng từ NFT Base64

• NFT ban đầu được dùng để tham chiếu tới hình ảnh, nhưng đến một lúc nào đó, chính phần tham chiếu lại trở thành dữ liệu
• Khi tinh thần ban đầu của giao thức thay đổi, thẻ thư viện bắt đầu đóng vai trò của chính cuốn sách
• Nó biến thành một công cụ trực tiếp xử lý dữ liệu thực tế rộng hơn rất nhiều so với ý định ban đầu

Hiệu ứng mạng mà không ai ngờ tới

• Càng có nhiều máy chủ MCP cho AI xuất hiện, sẽ càng xảy ra hiệu ứng là mọi ứng dụng đều có được chức năng mới mà không cần phát triển riêng
• Ví dụ, nếu ai đó tạo ra máy chủ MCP cho Spotify, một ứng dụng luyện tập có thể tự động tạo playlist thông qua MCP
• Một hiệu ứng mạng sẽ xuất hiện, nơi các nhà phát triển và ứng dụng vốn không hề biết nhau vẫn tự nhiên kết nối và cùng có lợi
• Mỗi máy chủ MCP đều có thể được tái sử dụng như một plugin phổ dụng
• Không ai thiết kế ra điều đó, nhưng một hệ sinh thái plugin phổ dụng đã hình thành một cách tình cờ

Ý nghĩa của USB-C và triết lý của MCP

• MCP thường được ví là USB-C của AI, và điều khiến USB-C trở nên đặc biệt không phải chỉ là một cổng kết nối đơn thuần, mà là một không gian khả năng nơi có thể kết nối mọi thứ
• Giống như USB-C chấp nhận điện năng, dữ liệu, video và những chức năng chưa biết khác, MCP cũng không chỉ là thứ 'dành cho AI' mà đóng vai trò như 'một lỗ cắm được thiết kế tốt cho chức năng', để bất kỳ ai cũng có thể kết nối bất kỳ chức năng nào

Đoạn tôi nói với bạn rằng tôi đang xây một thứ gì đó

• Tác giả đang phát triển một ứng dụng quản lý công việc tên là APM(Actions Per Minute)
• APM hoạt động như một hệ thống plugin nhưng chỉ dùng máy chủ MCP
• Mỗi khi muốn thêm chức năng, người dùng chỉ cần kết nối máy chủ MCP (ví dụ: kiểm tra chính tả, tự động gọi cà phê, phản ứng của nhân vật game, v.v.)
• Đây là một cấu trúc cho phép chính ứng dụng biến đổi linh hoạt thành nhiều hình thái khác nhau

Nguyên lý Giao thức Máy nướng bánh mì

• Mọi giao thức vĩ đại đều tạo ra đổi mới bằng cách được dùng vào những mục đích không ngờ tới, khác với ý định ban đầu
  • HTTP: dùng cho bài báo học thuật → hạ tầng của nền văn minh
  • Bluetooth: hands-free → mở khóa cửa trước, v.v.
  • USB: thiết bị nhập liệu → sạc quạt cầm tay, v.v.
• MCP cũng vậy: ban đầu là để truyền ngữ cảnh cho AI, nhưng về bản chất là một giao thức kết nối mọi thứ với mọi thứ
• Tác giả nhấn mạnh rằng đây là nền tảng cho một hệ sinh thái plugin tạo ra những đổi mới khó lường
• Dù hoàn toàn không được định sẵn, đây lại là cách làm cực kỳ hợp với thời đại nối máy nướng bánh với màn hình bằng HDMI

Kết

• PS: Nếu bạn tạo được một chiếc máy tính tỏa ra mùi bánh mì mới nướng bằng máy chủ MCP, hãy nhớ liên hệ nhé
• PPS: APM Early Access đã được mở, và tác giả khuyến khích những thử nghiệm táo bạo cùng thực nghiệm sáng tạo
• (Ở đâu đó, vẫn có những giao thức đang được dùng đúng với mục đích ban đầu của chúng. Điều này rất đáng ngờ)

[a1eng0]

Phản hồi của máy chủ MCP nhiều khả năng là ngôn ngữ tự nhiên, không có schema cố định.

Sẽ khó xử lý phản hồi ngôn ngữ tự nhiên này theo kiểu lập trình mà không dùng LLM.

[winterjung]

Xin nói thêm, trong đặc tả mcp 2025-06-18 mới được bổ sung structured tool output, nên giờ đã có thể mô tả response schema. Các công cụ mcp đã được triển khai trước đây phần lớn đúng như bạn nói là unstructured, nhưng có vẻ các công cụ mcp sắp tới sẽ đáng để kỳ vọng hơn.

[a1eng0]

Lại gặp anh Winter ở đây nữa rồi haha

Mình đã không theo dõi được bản đặc tả 250618. Cảm ơn bạn!

[GN⁺]

Ý kiến Hacker News

• Tôi thực sự thích bài viết này và cả giao thức MCP. Nhưng nhìn MCP lại khiến tôi liên tưởng đến microservices và SOA. Tôi lo rằng đây có thể là cơn ác mộng lặp lại của việc tạo ra những điểm lỗi mới. Mặt khác, cũng có cảm giác kỳ vọng rằng nhờ việc đưa agent vào, chuyện cải thiện độ tin cậy có thể diễn ra tự nhiên hơn

• Tôi đồng tình với tư tưởng của bài viết, và thấy rất thú vị khi tác giả dùng MCP theo một cách hơi lệch khỏi mục đích ban đầu. Điểm mấu chốt thực sự ở đây không phải là sự xuất hiện của một giao thức cho phép làm những việc hoàn toàn mới chưa từng có. Thực ra, như các bình luận khác cũng nói, bản thân MCP không phải là ý tưởng gì đặc biệt mới mẻ hay thú vị. Điều thực sự đáng chú ý là nhờ làn sóng AI agent, tính tương tác liên vận (interoperability) đang được chú ý, còn vấn đề vendor lock-in thì bị xem như thứ đã lỗi thời. Không biết hiện tượng này sẽ kéo dài bao lâu, nhưng hiện tại vẫn là một diễn biến đáng mừng

  • Điều này làm tôi nhớ tới thời Winsock được đưa vào sử dụng. Từng có thời trên Windows, mọi thứ liên quan đến mạng đều dùng các giao diện riêng lẻ, đóng kín và khác nhau. Rồi có câu chuyện về ngày mà nhiều vendor ngồi lại với nhau và quyết định tạo ra một tiêu chuẩn chung có lợi cho tất cả. Xem thêm Wikipedia về Winsock
  • Điểm cốt lõi không chỉ là interoperability trở nên thịnh hành hay việc kết nối dễ dàng hơn. Đổi mới thực sự nằm ở chỗ chính LLM đã học được cách sử dụng công cụ. Chỉ cần xây backend xong thì frontend không còn là việc của tôi nữa, AI sẽ tự xử lý. Claude và Gemini cũng có thể tự dùng công cụ nếu chỉ được nêu mục tiêu. Trước đây lúc nào cũng phải viết quy trình từng bước thật rõ để ra được kết quả mong muốn, còn giờ LLM thích nghi với tình huống linh hoạt tốt hơn hẳn các chương trình cố định, nên đây là một thay đổi cực lớn
  • Đúng là hiện tại có cảm giác kỳ vọng bị đẩy lên quá cao. Nhưng theo tôi, AI agent quả thực đã tạo ra động lực mạnh cho interoperability. Trước đây ai cũng làm chậm trong hệ thống riêng của mình thì coi như đảm bảo được việc làm ổn định, còn bây giờ xu hướng là kết nối mọi thứ với nhau. Agent sống nhờ khả năng tích hợp, giống như việc để CEO tự đi giao pizza cho hackathon còn rẻ hơn. Với tư cách người từng trực tiếp cưỡi trên làn sóng cách mạng tích hợp API trước đây, tôi có cảm giác cuối cùng thế giới cũng bắt kịp. Hy vọng bầu không khí này kéo dài được lâu
  • Tôi không hoàn toàn đồng ý với nhận định rằng làn sóng AI agent đang dẫn dắt trào lưu interoperability và khiến vendor lock-in trở thành chuyện của quá khứ. Những công cụ đang được chú ý gần đây như Cursor cũng chỉ dùng MCP theo một chiều, chứ không xuất ngược lịch sử hội thoại hay context ra ngoài. Tôi thích Cursor, nhưng bắt đầu từ việc nó là một fork VS Code không open source, kiểu tư duy “không trả lại” này sẽ ảnh hưởng tiêu cực đến niềm tin của developer. Cuối cùng thì lock-in vẫn còn rất vững
  • Trớ trêu là các biện pháp siết quyền truy cập API gần đây lại còn nặng hơn do liên quan đến việc huấn luyện dữ liệu AI. Thực ra kiểu khóa API này đã tồn tại từ lâu rồi, và cũng có góc nhìn hoài nghi rằng nếu xu hướng mở mới không theo kịp cơn sốt kỳ vọng hiện nay, mọi thứ có thể khép lại lần nữa bất kỳ lúc nào

• Tác giả đặt nhiều kỳ vọng vào tính phổ dụng của MCP, nhưng thành thật mà nói tôi vẫn tự hỏi nó khác khái niệm API ở điểm nào. Nếu thay MCP bằng REST thì nội dung bài viết có thay đổi nhiều không? API hệ điều hành, POSIX hay Unix pipes cũng có nét tương đồng. Dĩ nhiên MCP đơn giản và phổ dụng hơn tất cả những thứ đó rất nhiều. Nhưng có lẽ lời giải thật sự không phải là cứ tạo thêm abstraction mới mỗi lần, mà là quay về làm phần mềm cơ bản thật tốt và thật đơn giản

  • MCP khác REST. Đúng hơn, MCP giống như một giao thức cho phép khám phá động các REST endpoint ngay tại runtime, đồng thời để người dùng tự cấu hình sẽ dùng REST endpoint nào. Ví dụ, nếu app muốn phát nhạc từ Spotify thì tất nhiên bạn dùng Spotify API. Sau này muốn hỗ trợ thêm bài từ Sonofm thì cách cũ là phải sửa code, thêm nhánh điều kiện, phát hành bản mới, hướng dẫn người dùng update, v.v. Còn MCP cho phép cấu hình những việc đó ngay tại runtime nên cho cảm giác mở rộng linh hoạt hơn nhiều
  • Khác biệt cốt lõi là MCP yêu cầu tự mô tả ngay từ đầu. REST cũng có OpenAPI nhưng đó là thứ được thêm vào sau, và mức độ áp dụng chuẩn cũng không cao. Còn MCP yêu cầu phải công khai phần mô tả trước tiên, nên khả năng tiếp cận khác hẳn
  • Theo tôi, điều khiến MCP có vẻ thực sự mới mẻ chỉ là việc nó bắt buộc cung cấp schema ở cấp giao thức. Tất nhiên việc cấu trúc request/response nhất quán sẽ giúp các thư viện bọc dynamic type thành static type dễ quản lý hơn. Thực ra ai cũng đã làm điều tương tự trong API từ trước rồi. Chỉ là chúng ta chưa thống nhất được về hình thức envelope đó. Vì ngay từ đầu việc cung cấp schema là bắt buộc, và các mô hình AI có thể tận dụng ngay điều này, nên MCP mới được chú ý như vậy
  • Điểm khác biệt lớn giữa MCP và REST là MCP có lệnh tích hợp sẵn list-tools. REST API có nhiều cách để liệt kê tài nguyên, còn MCP chỉ cung cấp một cách tiêu chuẩn hóa duy nhất
  • Một khác biệt lớn nữa là MCP có quy trình discovery được tích hợp sẵn trong giao thức. REST không có thành phần nào để cho client biết những tài nguyên nào khả dụng hay bản thân API có những chức năng gì

• Nhiều người nói MCP rất ghê gớm, nhưng tôi chưa thấy nhiều ví dụ thực sự làm ra thứ gì ấn tượng. Cảm giác khá giống thời blockchain bùng nổ. Cuối cùng tôi nghĩ MCP cũng chỉ là giải pháp tạm thời cho đến khi AI thông minh hơn. Khoảng 2 năm nữa, có lẽ thay vì MCP, người ta sẽ chỉ nạp nguyên tài liệu công cụ hoặc OpenAPI vào, rồi AI tự tiêu hóa toàn bộ context theo cách tự nhiên hơn

  • Ví dụ, tôi không rõ chỉ đưa tài liệu của Ableton Live vào thì sẽ giúp Claude trực tiếp sáng tác nhạc được đến mức nào
  • Dù mô hình có mạnh đến đâu, nếu cuối cùng không được cấp quyền truy cập công cụ mang tính xác định và thông tin về trạng thái của thế giới thực, thì mức độ hữu dụng vẫn bị hạn chế rất nhiều. Và xét đến vấn đề bảo mật, cũng không thể để mô hình tự do phát request trong môi trường production mà không kiểm soát. Tôi nghĩ không khí cường điệu quanh MCP có phần quá đà, nhưng bản thân vấn đề đang được bàn tới ở đây là có thật và rất quan trọng. Nếu giao thức này khiến developer mở chức năng ra thành API rõ ràng hơn thì đó là điều rất đáng kỳ vọng
  • Cơn sốt blockchain và MCP khá khác nhau. Tôi cũng từng hoài nghi lúc đầu, nhưng chỉ cần tự tay triển khai thử một chút MCP server là sẽ thấy trải nghiệm hoàn toàn khác. Việc kết hợp AI hội thoại/giọng nói với các LLM hiện tại, cùng MCP và đủ loại công cụ, hàm, API và dữ liệu/dịch vụ riêng tư đã mở ra cảm giác như đang bước vào một frontier hoàn toàn mới. Nó chưa hoàn hảo 100%, nhưng đủ tốt cho gần như hầu hết các trường hợp sử dụng thực tế, và cách làm ứng dụng trong tương lai có lẽ sẽ thay đổi rất nhiều
  • Thực tế là tôi muốn biết các nghị sĩ trong bang đã làm gì trong tuần này, nhưng không có cách nào dễ để tìm thông tin liên quan, nên khi nghe nói MCP kết hợp với API của congress.gov khá hấp dẫn, tôi đã thử tự làm một MCP server. Công khai mã ở đây. Giờ tôi thực sự đang dùng nó khá hiệu quả để theo dõi diễn biến Quốc hội Mỹ theo thời gian thực
  • Chừng nào kiến trúc mô hình AI còn tiếp tục tiến hóa, tôi nghĩ lớp middleware trung gian như MCP sẽ khó biến mất một cách dễ dàng

• Tôi nghĩ chiến lược "Embrace, Expand, Extinguish" mà Microsoft vẫn luôn dùng cũng đang được áp dụng ở đây. Lý do là nếu để agent tự động khám phá công cụ một cách không kiểm soát thì sẽ làm tăng nguy cơ xung đột, xét về độ ổn định hệ thống và bảo mật. Có các lựa chọn thay thế như PydanitcAI, nhưng cuối cùng Microsoft đang chính thức đẩy MCP tại 'Build 2025' và dẫn dắt ngành theo nhịp của riêng họ. Anthropic đã tung ra tiêu chuẩn trong tình trạng công cụ còn yếu và governance thì thiếu, nên Microsoft rất dễ chiếm lĩnh. Bước tiếp theo có thể là Microsoft biến registry của mình thành chuẩn thực tế của ngành, rồi kết hợp với các lệnh chuyên biệt cho Windows. Cuối cùng, họ sẽ xoay chuyển tiêu chí “bảo mật” theo hướng có lợi cho mình để gạt đối thủ ra ngoài

• Nếu bỏ hẳn yếu tố AI thì sao? Có lo ngại rằng nếu phụ thuộc trực tiếp vào MCP server mà không có middleware AI, ta sẽ ngay lập tức đụng phải vấn đề tương thích ngược. Bởi vì các MCP server được xây trên giả định rằng bên gọi là một thuật toán AI, nên các thay đổi phá vỡ tương thích đối với công cụ hoặc schema input/output có thể xảy ra bất kỳ lúc nào

• Tôi cũng từng nghĩ tương tự, nhưng rồi lại thấy rằng phần lớn MCP server thực chất chỉ là client mới của các API sẵn có. Ví dụ, MCP server của Kagi chỉ đơn giản gọi Kagi API. Nếu vậy thì chẳng phải dùng trực tiếp API sẽ tốt hơn sao? Ngoài ra, hệ thống rồi sẽ ngày càng có thêm nhiều Python interpreter tương ứng với số MCP server, nên tôi cũng tò mò liệu sau này có xuất hiện một dịch vụ “hosting” để gom tất cả lại và bridge một lần hay không

  • Theo cách tôi hiểu thì MCP chỉ giống như gắn thêm một endpoint API /list-tools vào API hiện có. Tất cả client trước tiên sẽ truy cập /list-tools để lấy danh sách công cụ khả dụng, sau đó mới gọi các API tương ứng
  • Cách tiếp cận của tôi là thế này. Nếu đã có một API với OpenAPI spec sẵn rồi, chẳng phải chỉ cần bọc nó lại bằng FastMCP là xong sao? Thực tế tôi đã thử tích hợp vào Goose trong lúc xử lý các yêu cầu xác thực, và kết luận là Goose rốt cuộc cũng chỉ bắn lệnh curl vào các route API có sẵn. Nếu OpenAPI spec đã đủ tốt thì MCP có thể không thực sự cần thiết. Dĩ nhiên, nếu chưa có API sẵn thì có vẻ hướng phát triển là để chính MCP server thực hiện luôn phần hành vi cốt lõi

• Tôi thấy khá đồng cảm với nhiều ý kiến hoài nghi trong phần bình luận. Tuần trước tôi đã tự triển khai MCP server, và thành thật mà nói tôi cho rằng khen nó là “được thiết kế tốt” thì hơi quá. Một trong các mục tiêu của MCP là “để người ta có thể làm nó một cách đơn giản”, nhưng thực tế làm rồi thì không hề dễ đến thế. Dẫu vậy, điều quan trọng là hiện tại ánh nhìn của vô số developer đang đổ dồn về cùng một hướng. Trong kiểu momentum như thế này, tốc độ giải quyết vấn đề có thể tăng lên rất nhanh. Và hệ sinh thái cũng cần đạt một khối lượng phê bình đủ lớn mới hình thành được; tôi có cảm giác chính điểm bẻ đó đang thực sự đến. Chúc mọi người có đủ kiên nhẫn và may mắn

  • Chỉ cần dùng thư viện MCP Python là rất dễ. Gắn decorator vào hàm là công cụ có ngay. Tôi cũng chẳng biết gì về giao thức MCP, vậy mà làm theo cách đó vẫn chạy tốt. Tất nhiên nếu phải tự triển khai giao thức thì câu chuyện có thể khác
  • MCP server chỉ cần “phơi bày lại các API công khai hoặc bán công khai đã tồn tại”. Quan điểm cho rằng nên triển khai với mức thay đổi tối thiểu có thể đối với endpoint gốc là khá thuyết phục
  • Trước đây cũng đã có những nỗ lực kiểu này, nhưng rồi vài năm sau các app lại khóa endpoint lại để chỉ cho các server cụ thể như chatgpt, claude v.v. truy cập. Interoperability trên thực tế cũng chính là portability của người dùng, mà trong thực tế nhiều công ty công nghệ hướng đến lock-in và độc quyền hơn là portability

• Tôi muốn nhấn mạnh rằng trong suốt lịch sử, việc hạ thấp rào cản tiếp cận đã luôn đóng vai trò quan trọng trong việc công nghệ được chấp nhận và lan rộng. MCP cũng là một phần nối dài của điều đó, và không nên bị xem nhẹ. Ngay trong đội của chúng tôi, một người hoàn toàn không có nền tảng kỹ thuật cũng đã có thể trực tiếp dùng agent để tự động hóa công việc chia sẻ tệp. Tất nhiên trước đây chuyện đó chỉ có thể làm bằng hàng trăm ngôn ngữ lập trình, thư viện và API, nhưng nhờ MCP mà giờ cả người không chuyên cũng có thể giải quyết ngay mà không cần bận tâm. Về hiệu năng thì không phải tốt nhất, cách triển khai cũng chưa phải tối ưu nhất, nhưng giá trị mà kiểu tiếp cận mới này mang lại, trong điều kiện tài nguyên và trình độ công nghệ hiện nay, là điều chưa từng có tiền lệ. Đó mới là điểm cốt lõi thực sự

  • Tôi cho rằng câu chuyện một thành viên không phải dân kỹ thuật mà tự mình dọn dẹp file share tốt là hơi phóng đại. Nếu chỉ là sắp xếp vài nghìn tệp thì còn có thể, nhưng theo kinh nghiệm của tôi, gần như mọi nỗ lực dọn dẹp file share đều rất khó nhận được sự hợp tác từ các bộ phận liên quan. Ngay cả những người phụ trách công việc đó cũng ghét phải làm vì vốn dĩ không phải việc của họ. Nhiều khi phải lôi cả lãnh đạo cấp cao vào mới thuyết phục được, hoặc ngồi cùng nhau cả tiếng chỉ để nặn ra cấu trúc thư mục. 50% khối lượng là chính trị giữa các phòng ban, 20% là cập nhật quy trình, 20% là đào tạo, còn vấn đề kỹ thuật chỉ 10%. Tôi từng trải qua từ thảm họa lớn nhỏ đến hỗn loạn bất tận, nên rất khó tin rằng chỉ vì AI giúp tạo công cụ dễ hơn thì thực tế sẽ đơn giản như vậy. Dự đoán bi quan của tôi là vài tháng sau sẽ lại phải làm việc khôi phục từ bản sao lưu

• Có câu đùa rằng “giá mà AI agent trong Warcraft 3 phản hồi theo kiểu peon, được sai gì làm nấy rồi đáp lại”, còn tôi thì muốn đi thuyền hơn

  • Tôi chỉ muốn chỉ ra rằng I'd rather be sailing là câu thoại trong Warcraft 2, còn trong Warcraft 3 thì câu đáp là I'd rather be flying