Sự xuất hiện của Web 2.0 2.0: MCP

• Model Context Protocol (MCP) đang được áp dụng nhanh chóng và nổi lên như một tiêu chuẩn mở mới
• Giá trị cốt lõi của MCP không nằm ở sự hoàn hảo mà ở tính mở và khả năng tương tác
• Ý nghĩa thực sự của Web 2.0 không phải là nền tảng khép kín, mà là API mở và chia sẻ dữ liệu
• Đang xuất hiện một làn sóng quay trở lại giá trị của web mở sau thời kỳ khép kín trước đây
• Việc áp dụng MCP có thể khiến các nhà phát triển đòi hỏi mạnh mẽ hơn về kiểm soát nền tảng và tính minh bạch

---

MCP: sự xuất hiện của một web mở mới

Trong vài tháng gần đây, sự quan tâm của giới phát triển đối với Model Context Protocol (MCP) đã bùng nổ. Điểm khởi đầu là việc Anthropic thiết kế giao thức này vào năm 2023 để hệ thống LLM (Claude) của mình có thể tương tác với nhiều ứng dụng khác nhau. Sau đó, khi OpenAI hỗ trợ cùng giao thức trong ChatGPT, nó nhanh chóng được định hình như một tiêu chuẩn. Hiện tại, giao thức này đang mở rộng sang các nền tảng lớn, bao gồm cả việc được áp dụng trên Windows.

Điểm thú vị là thế mạnh của MCP không nằm ở mức độ rõ ràng hay hoàn thiện của chính đặc tả, mà ở sự tiện dụng và tốc độ triển khai. Không giống các tiêu chuẩn truyền thống được thiết kế chặt chẽ, MCP là một đặc tả tương đối mơ hồ và được định nghĩa khá lỏng, nhưng điểm mạnh quan trọng là nó thực sự hoạt động tốt trong thực tế. Trên hết, việc đây là một giao thức mở mà bất kỳ ai cũng có thể sử dụng khiến giá trị của nó càng trở nên đáng chú ý.

Ý nghĩa thực sự của web mở

Trong môi trường web ngoài đời thực, những tiêu chuẩn chưa hoàn hảo và còn đôi chút thiếu sót lại thường tạo ra tiến bộ thực sự khi được áp dụng nhanh chóng. Chính những dòng chảy như vậy đã tạo ra các đổi mới như "nghe ở bất cứ nơi nào bạn nghe podcast".

Tinh thần của Web 2.0 hướng đến một hệ sinh thái mở với API mở, chia sẻ dữ liệu và gia tăng quyền kiểm soát cho người dùng lẫn nhà phát triển. Cần lưu ý rằng các nền tảng khép kín như Facebook chính là những thực thể đã làm tiêu biến Web 2.0. Trước đây, Flickr, del.icio.us, Upcoming từng dẫn dắt một nền văn hóa coi trọng chia sẻ và kết nối, và tại các nền tảng như live blog, các cuộc thảo luận về tiêu chuẩn mở cho API/giao thức đã diễn ra rất sôi nổi.

Sự trở lại của tính mở

Sau một thế hệ, đây lại là thời điểm kỳ vọng về khả năng tương tác đang tăng lên. Trong quá khứ, việc các công ty công nghệ lớn theo đuổi chính sách khép kín đã liên tục dẫn đến trải nghiệm API bị chặn và dịch vụ biến mất. Ví dụ, công cụ phân tích dữ liệu mạng xã hội mà tác giả xây dựng cuối cùng đã bị khai tử do phía nền tảng chặn API. Những chính sách như vậy đã phá vỡ tầm nhìn Web 2.0 về dữ liệu mở và khả năng tương thích. Hệ quả là các vấn đề như không thể nhúng nội dung hay cản trở khả năng di chuyển dữ liệu trở thành chuyện thường ngày.

Tuy nhiên, với sự xuất hiện của MCP, có thể kỳ vọng AI sẽ trở thành chất xúc tác cho sự trỗi dậy trở lại của khả năng lập trình và tính mở. Việc nhiều nền tảng cùng áp dụng một giao thức có thể tạo ra một vòng tuần hoàn tích cực trên nền tảng công nghệ.

Khi các nền tảng chấp nhận giao thức đúng như nó vốn có và trung thành với quá trình tiêu chuẩn hóa, toàn bộ hệ sinh thái sẽ chứng kiến những thay đổi tích cực. Bài viết nhấn mạnh rằng ham muốn của nhà phát triển muốn "làm tốt hơn cả tiêu chuẩn" đôi khi lại có thể phản tác dụng và gây hại cho hệ sinh thái. Ngay cả HTML cũng là một đặc tả không hoàn hảo, nhưng rốt cuộc vẫn trở thành nền tảng cho khả năng tương tác quy mô lớn của internet.

Tầm quan trọng của việc tuân thủ tiêu chuẩn

Thế hệ nhà phát triển mới đang trực tiếp trải nghiệm sức mạnh của đổi mới dựa trên cùng một giao thức và định dạng. Trải nghiệm đó rất có thể sẽ dẫn đến sự gắn bó mạnh mẽ trở lại với tiêu chuẩn mở. Bầu không khí này gợi nhớ đến thời kỳ mà các định dạng mở như RSS, Podcast, OpenID, OAuth, OpenSocial thực sự trao quyền cho người dùng.

Hiện nay không còn là thời điểm chỉ dành cho các tập đoàn lớn, mà là lúc cộng đồng nhà phát triển và người dùng có thể tự mình thực thi quyền đòi hỏi. Mọi người cần có khả năng yêu cầu các nền tảng về quyền kiểm soát trải nghiệm và tính minh bạch, và khi áp dụng các tiêu chuẩn mở như MCP, tính minh bạch trong cách nền tảng vận hành nội bộ và sử dụng dữ liệu nhất thiết phải được bảo đảm. MCP mang tính mở, nhưng vẫn còn thiếu sót về hoạt động nội bộ và các vấn đề bảo mật, nên cần có những cải tiến tiếp theo.

Khả năng hồi sinh tinh thần Web 2.0

MCP không phải là một lời giải vạn năng cho mọi vấn đề, nhưng có vẻ sẽ trở thành một cơ hội để khơi lại hệ sinh thái mở từng tồn tại trong thời kỳ Web 2.0. Những hạn chế như sự cường điệu trong thảo luận về AI hay việc thiếu vắng phê phán vẫn còn nguyên.

Tuy vậy, đặc biệt trong giới phát triển trẻ, giá trị của một web có thể lập trình và thoát khỏi tính khép kín đang được nhìn nhận lại. Web vốn không phải tài sản của một vài tập đoàn khổng lồ, mà là một không gian mở nơi mọi người có thể sử dụng theo cách mình mong muốn, và MCP đang gợi ra khả năng có thể gọi lại triết lý đó.

[GN⁺]

Ý kiến Hacker News

• Có cảm giác nhiều người đang bỏ qua việc cốt lõi của MCP là nó rất phù hợp với phần mềm doanh nghiệp; ở chỗ LLM có thể đóng vai trò như một lớp trung gian linh hoạt kiểu “bộ dịch vạn năng”, nối các hệ thống vốn khó liên thông với nhau, nên trên thực tế việc triển khai máy chủ MCP cũng đang diễn ra rất sôi động trong ngành B2B SaaS. Ngay trong nội bộ công ty cũng ngày càng có nhiều thảo luận về việc điều chỉnh giới hạn hay cấu trúc cho phù hợp với kiểu sử dụng API. Dù giao thức này có thể chưa “enterprise-ready” theo nhiều nghĩa thì điều đó cũng không quá quan trọng. Trong lịch sử các tiêu chuẩn, những đặc tả chưa được gọt giũa, còn “thô” nhưng hợp nhu cầu thị trường rốt cuộc vẫn thường được chấp nhận
  • MCP được hiểu là có cảm giác giống RPC hoạt động trên kết nối dài, nhìn chung dựa trên WebSocket. Cá nhân thấy RPC dễ hơn, thứ nhất là nó giảm bớt các tranh cãi không cần thiết trong thiết kế endpoint REST như nên thay thế toàn bộ bằng POST hay chỉ sửa một vài trường bằng PUT; thứ hai là LLM không cần biết thuật ngữ/ngữ nghĩa của REST, chỉ cần nhìn method RPC rồi gọi ngay. Tóm lại, đây là hai điểm mạnh lớn
  • Muốn chỉ ra rằng từ góc nhìn doanh nghiệp, MCP là một mô hình doanh thu rất tốt. Mỗi yêu cầu dữ liệu đều gắn trực tiếp với một lần chạy LLM có tính phí. Mặt khác, vẫn thấy tiếc vì việc áp dụng MCP hiện chưa hề có các tối ưu như thương lượng schema để làm cho các truy vấn tương lai rẻ hơn
  • Đã có rest và openapi từ trước, vốn hỗ trợ các khả năng như self-discovery riêng của chúng. Vẫn tin rằng các công ty cung cấp MCP rồi rốt cuộc cũng sẽ đều cung cấp API tốt mà thôi
  • Rất đồng cảm với điểm này: trong các doanh nghiệp lớn có nhiều kỹ sư chỉ tập trung làm việc thật tốt từ 9 giờ đến 5 giờ, còn sau khi tan làm thì không muốn nghĩ gì về công ty nữa. Nếu vậy thì từ phía doanh nghiệp, lựa chọn hợp lý nhất là tận dụng cơ hội tối đa hóa năng suất của nhân viên trong đúng khung giờ làm việc
• Tò mò không biết sẽ mất bao lâu để xuất hiện các thí nghiệm điều khiển sinh vật như gián bằng máy chủ MCP; thực tế trong hơn 10 năm qua đã có nhiều ví dụ như thí nghiệm robo-roach, gián cyborg
• Trước đây các lập trình viên Unix từng viết tài liệu đặc tả rất chặt chẽ, nhưng thời thế đã đổi khác. Muốn nêu rằng chính sự nghiêm ngặt này cùng sự mệt mỏi với tính mở rộng (eXtensible) là một trong các nguyên nhân khiến kiến trúc dựa trên XML thất bại. Khi đó có XSL, XHTML, XSD, WSDL, RDF, RSS và một kiến trúc quá phức tạp; kết quả là các định dạng đơn giản như JSON trở nên phổ biến. Tuy vậy, gần đây cũng chứng kiến xu hướng XML được dùng nhiều hơn. Đặc biệt trong system prompt của các hệ thống LLM như Anthropic, có thể cảm nhận rõ việc dùng nhiều văn bản có cấu trúc như XML hay Markdown. Nhưng vẫn cho rằng mô hình MCP là sai hướng: thay vì bảo mô hình “kéo” thông tin về, cách tốt hơn là “đẩy” sẵn, tức cung cấp ngữ cảnh trước
  • Điều thú vị là gần đây khi tạo một ngôn ngữ mở rộng macro dựa trên JSON thì lại nhận ra mình đang tái phát minh XSLT hay XPath, và đã có trải nghiệm rất ấn tượng với đặc tả xpath vốn cực kỳ mạnh cho việc duyệt graph. Các công cụ như BaseX rất hữu ích vì có thể kéo XML bất kỳ vào DB rồi truy vấn bằng XPATH/XQUERY. Nếu muốn tạo một giao diện dữ liệu chắc chắn để ngăn LLM nói bậy, thì cho schema XML vào system prompt rồi để nó sinh câu truy vấn dữ liệu có lẽ là giải pháp tốt nhất
  • Vẫn nghi ngờ trên thực tế “mô hình đẩy sẵn ngữ cảnh” có thể xử lý được đến mức nào. Nếu người dùng đã biết trước thông tin thì họ sẽ tự giải quyết vấn đề luôn, còn phần lớn nhu cầu MCP dường như là kiểu “đừng bắt tôi học cách nối 15 nguồn dữ liệu, cứ xử lý truy vấn giúp tôi là được”
  • LLM xử lý XML dạng tag khá tốt, nhưng thực tế đa số không dùng các khối XML chuẩn chỉnh (bắt đầu bằng <?xml version="1.0" encoding="UTF-8"?>, có namespace, schema, v.v.) mà chỉ ở mức một tập tag kiểu SGML mà thôi
  • Muốn nhấn mạnh rằng lý do thật sự khiến semantic web thất bại là vì nó không thành công trong việc gắn với chèn quảng cáo hay mô hình kinh doanh
  • Có lập trường phê phán cách “đẩy ngữ cảnh”. Cửa sổ ngữ cảnh của LLM rất hạn chế, nên tối ưu là chỉ truyền tối thiểu đúng thông tin cần thiết. Khi từng mô hình có thể tự chọn và pull đúng phần ngữ cảnh mình cần thì khả năng vượt qua giới hạn sẽ cao hơn
• MCP dường như gieo hy vọng rằng nhờ độ phổ biến của AI, nhiều nền tảng sẽ trở nên có thể lập trình được cho bất cứ mục đích nào, nhưng lại nghĩ rằng cuối cùng nó sẽ thất bại. Bởi vì lý do semantic web thất bại cũng là không xây được cấu trúc doanh thu. Các tính năng “research” nơi AI đào sâu web thay con người cũng vậy. Ví dụ, về nguyên tắc có thể xuất bản menu nhà hàng dưới dạng metadata để tự động hóa việc như “tìm taco rẻ nhất ở Texas”, nhưng thực tế lại là cuộc cạnh tranh hạ tầng giữa việc khóa dữ liệu và các crawler AI tìm cách vượt qua nó. Nhìn ở bức tranh lớn, hệ thống hiện tại thật kém hiệu quả
  • Đánh giá rằng MCP rốt cuộc cũng chỉ là một dạng tiến hóa của robots.txt. Về bản chất, đó là mô hình “nếu tôi mô tả tài nguyên của mình đủ tốt thì bạn sẽ dùng nó”. Trước đây các hệ thống agent dựa trên Java thập niên 90 cũng thất bại vì vấn đề bất đối xứng thông tin giữa các agent, và có lo ngại rằng nếu loại bỏ giới hạn thiết kế này thì cả xã hội/hệ thống kinh doanh có thể ngừng vận hành
  • Có nhận định từ trải nghiệm rằng open API, trước cả bài toán doanh thu tiền bạc, trên thực tế sẽ phá sản vì làn sóng bot yêu cầu từ các AI agent sẽ làm cạn kiệt tài nguyên nếu không đổ vào đó nguồn lực gần như vô hạn. Về dài hạn, mô hình tính phí RPC pay-per-call có lẽ sẽ là phương án ổn định hơn. Nhà vận hành mô hình/agent sẽ đóng vai trò như clearing house thanh toán và có khả năng sẽ gộp chi phí đó vào phí thuê bao hay các khoản tương tự
  • Những lý tưởng kiến trúc REST như HATEOAS từng cực kỳ thịnh hành đầu thập niên 2010, nhưng rồi ngoài các công cụ tự động hóa như swagger yaml thì gần như chết yểu mà không có mở rộng thực chất nào. Ngay cả thuật ngữ cũng quá khó, tự chuốc lấy nguyên nhân thất bại
  • Không đồng ý với quan điểm xem văn bản con người đọc được là một rào cản nhân tạo. Ngược lại, việc yêu cầu một nhà hàng phải có kỹ năng tạo JSON hay triển khai phần mềm mới thật sự là rào cản nhân tạo. Nhờ các công cụ NLP, giờ có thể tận dụng luôn dữ liệu sẵn có nên chi phí phát triển gần như về 0; dù có sự không chính xác về ngôn ngữ thì đó vốn là đặc tính tự nhiên của ngôn ngữ con người nên không xem là vấn đề lớn
  • Dù đang phê phán semantic web nên nói ra cũng hơi dè dặt, nhưng vẫn nghĩ rằng nếu chủ nhà hàng thật sự muốn thì họ luôn có thể xuất bản metadata, và đó có thể trở thành cơ hội giúp kết nối người mua với người bán dễ dàng hơn. Lấy plugin WordPress làm ví dụ, đã có hỗ trợ metadata như schema.org/Restaurant, Menu, MenuItem, Offer, nên có lẽ rào cản lớn nhất cuối cùng lại là chuyện gatekeeping kiểu Cloudflare. Trên thực tế đây chính là yếu tố cản trở các ý tưởng tự động hóa bằng Python
• Vì LLM có thể đọc tài liệu API và tự thích nghi, nên việc tuân thủ đặc tả API chuẩn có lẽ không còn bắt buộc như trước. Dù có áp dụng đặc tả MCP hay không, bản thân kỳ vọng rằng mỗi website sẽ “cung cấp API” đã là một thay đổi lớn
  • Trong môi trường thực tế, tài liệu API có thể nghèo nàn nên LLM có thể sinh mã hoặc lời gọi sai; khi người dùng sửa lại rồi đưa cho LLM thì rốt cuộc cũng dẫn đến việc tạo ra một lớp trung gian kiểu máy chủ MCP. Khi cho LLM quyền truy cập API trực tiếp thì cũng phát sinh rủi ro về bảo mật và quản lý tài nguyên (ví dụ gọi quá mức gây bùng nổ chi phí). Có nhiều pain point bổ sung, và một phần trong số đó được giải quyết bằng chính cấu trúc có giao diện trung gian như MCP. “Kẻ trung gian” đó có nhất thiết phải là MCP hay không thì là chuyện khác, nhưng ở thời điểm hiện tại đây là một giải pháp đủ thực dụng
• Điều đáng lo nhất ở MCP không phải là mức độ chưa hoàn thiện của giao thức, mà là quyền cải thiện/chỉnh sửa lại tập trung trong tay các đội ngũ bên trong những công ty như Anthropic hay OpenAI. Cũng có cảm giác cảnh giác rằng đây là một đặc tả vẫn chỉ dừng ở giai đoạn brainstorming chứ chưa thực sự lấy nhà phát triển/vận hành làm trung tâm. Nó gợi một cái bóng giống kiểu song quyền Visa-Mastercard
  • Có trường hợp Microsoft cũng tham gia steering committee
• “Semantic web” thực ra chỉ là cú pháp cấu trúc, còn MCP biết đâu mới là thứ thật sự có khả năng trở thành hiện thực
• Có nhận thức rằng “các lập trình viên Unix kiểu cũ chủ chốt quá cầu toàn và khó tính”, nhưng điều mỉa mai là chính Unix mới là cái nôi của văn hóa “thử nhanh rồi phá vỡ”. Dù khác thế hệ, bản chất có lẽ vẫn không đổi
• Có lo ngại rất thực tế rằng MCP có thể bị lạm dụng để phát tán quảng cáo và spam nhắm vào AI, giống như SEO cho công cụ tìm kiếm của Google
• Cần cẩn trọng với ảo tưởng rằng nhờ MCP mọi người sẽ dễ dàng truy cập đủ loại dữ liệu; thực tế lại dễ đồng cảm hơn với viễn cảnh bị trói trong nhiều lớp xác thực thanh toán, whitelist IP được cấp phép, và cuối cùng người dùng chỉ nhận về lỗi “ERR 402”