- MCP-B: giao thức tự động hóa AI native cho trình duyệt
- Không phải cách chụp màn hình và nhấp chuột truyền thống, mà là giao thức ngữ cảnh trình duyệt cho phép AI tự động hóa nhanh hơn và chính xác hơn 1.000 lần bằng cách truy cập trực tiếp vào API của website
- Chỉ cần thêm khoảng 50 dòng mã là có thể tích hợp AI ngay với thông tin xác thực trong site, không cần OAuth riêng, API key hay cấu hình phức tạp
- Tận dụng phiên trình duyệt và hệ thống xác thực hiện có để hoạt động ngay mà không cần xác thực hay thiết lập quyền mới, đồng thời vẫn tôn trọng nguyên vẹn chính sách bảo mật API của từng web app
- Thông qua extension, trợ lý AI có thể trực tiếp tra cứu dữ liệu và thực hiện công việc xuyên qua nhiều tab và ứng dụng, giúp hiệu năng (thực thi trong vài ms) và độ tin cậy vượt trội so với tự động hóa truyền thống
- Nhờ truy cập API có cấu trúc, không còn bị ảnh hưởng bởi thay đổi UI, lỗi screenshot hay vấn đề quản lý selector phức tạp. Cả cài đặt lẫn sử dụng đều rất đơn giản
Tổng quan về MCP-B
- MCP-B (Machine Context Protocol for Browsers) là model context protocol dành cho trình duyệt, cung cấp một tiêu chuẩn để điều khiển và tương tác với môi trường trình duyệt theo cách tương tự tự động hóa terminal bằng AI
- Giao thức này xác định rõ cách trình duyệt và engine AI giao tiếp với nhau, từ đó cấu trúc hóa nhiều dạng tự động hóa và tương tác với mô hình
Điểm khác biệt so với cách hiện tại
- Tự động hóa trình duyệt truyền thống: phân tích screenshot, nhấp vào phần tử, dễ vỡ khi UI thay đổi, chậm và thiếu ổn định (10~20 giây mỗi tác vụ, chi phí $4~5)
- Cách MCP hiện có: cần API key và xác thực phức tạp, rào cản thiết lập ban đầu cao
- MCP-B: tận dụng phiên trình duyệt, truy cập API trực tiếp, hoạt động ngay mà không cần xác thực hay cấu hình phức tạp
Nguyên lý và kiến trúc cốt lõi
- MCP server theo từng tab: mỗi web app tự chạy MCP server riêng dựa trên TypeScript (truyền trong bộ nhớ, tái sử dụng xác thực cookie/JWT hiện có)
- Extension MCP-B: extension cho Chrome/Edge/Firefox (content script giao tiếp với server của tab qua
postMessage), hợp nhất tool và API của mọi tab về một nơi - Tích hợp trợ lý AI: có thể tự động hóa trình duyệt qua MCP-B từ Native Bridge và nhiều client khác nhau (Claude Desktop, Cursor IDE, v.v.)
Cách sử dụng và triển khai
- Nhà phát triển: 1) cài package 2) thêm mã MCP server 3) triển khai xong → không cần API key riêng, OAuth hay cấu hình phức tạp
- Người dùng: cài extension là có thể dùng ngay, chỉ cần cấu hình AI là tự động hóa tức thì
Lợi ích thực tế
- Xác thực: dùng nguyên trạng thông tin đăng nhập và phiên hiện có của website, không cần OAuth 2.1/xác thực riêng
- Hiệu năng: hoàn thành tác vụ ở mức mili giây nhờ gọi API trực tiếp (cải thiện 10.000 lần so với trước đây)
- Bảo mật: chạy bên trong ứng dụng, tuân thủ nguyên vẹn cơ chế kiểm soát truy cập và chính sách phân quyền hiện có
- Khả năng mở rộng: có thể quản lý tập trung nhiều web app, tab và công cụ AI thông qua MCP-B
- Thiết lập: chỉ khoảng 50 dòng mã là sẵn sàng cho tự động hóa
Tóm tắt so sánh
| Phương thức | Xác thực và thiết lập | Cách hoạt động | Hiệu năng và độ tin cậy |
|---|---|---|---|
| Tự động hóa cũ | Xác thực phức tạp, API key | Screen scraping, nhấp chuột | Chậm và thiếu ổn định (10~20 giây) |
| MCP hiện có | Cần API key, OAuth | Truy cập API | Rào cản gia nhập cao |
| MCP-B | Không cần thiết lập, dùng phiên trình duyệt | Gọi API trực tiếp | Mức ms, rất nhanh/ổn định |
Kết luận: tự động hóa AI thế hệ mới trên nền trình duyệt
- MCP-B là giao thức tự động hóa AI được tối ưu cho môi trường trình duyệt, mang tính đột phá ở mọi mặt như xác thực, bảo mật, khả năng mở rộng và hiệu năng
- Có thể triển khai tự động hóa AI quy mô lớn chỉ bằng cách gọi API trực tiếp trong trình duyệt, không cần xác thực bổ sung hay cấu hình phức tạp
- Giấy phép MIT, định hướng cộng đồng, hỗ trợ tất cả các trình duyệt lớn
2 bình luận
Tôi cho rằng tầm nhìn cốt lõi của công nghệ MCP-B là như sau.
"Thông qua một trung gian đáng tin cậy là tiện ích mở rộng Chrome (Extension), tận dụng thông tin người dùng mà trình duyệt đã quản lý an toàn sẵn có (cookie, phiên, xác thực, v.v.),
gọi và điều khiển các 'công cụ (Tools)' mà nhà phát triển đã định nghĩa trước trên trang web bằng lệnh ngôn ngữ tự nhiên từ cửa sổ chat AI."
Tuy nhiên, tôi cảm thấy rằng "có vẻ không có nhiều khả năng để mở rộng", và tôi nghĩ lý do là như sau.
Kết luận là,
ý tưởng của MCP-B tự thân rất thú vị và đổi mới về mặt kỹ thuật, nhưng có vẻ chưa thể đưa ra câu trả lời rõ ràng cho câu hỏi cốt lõi của cả người dùng lẫn nhà phát triển rằng "tại sao nhất định phải dùng cách này?". So với phương thức API hiện có, lợi ích đạt được còn không rõ ràng, trong khi các nhược điểm như lo ngại bảo mật và độ phức tạp trong phát triển lại rất rõ ràng.
Vì vậy, ở thời điểm hiện tại, công nghệ này có thể được sử dụng thử nghiệm trong phạm vi một số người đam mê hoặc các nhà phát triển có mục đích cụ thể, nhưng có vẻ sẽ gặp nhiều khó khăn để mở rộng ra toàn bộ hệ sinh thái web.
Ý kiến trên Hacker News
Dự đoán: nó sẽ đi theo con đường giống RSS. Các công ty có xu hướng không thích việc người dùng tự mình kiểm soát cách dữ liệu được khai thác
REST API cũng vậy; đã từng có thời người ta kỳ vọng nó sẽ trở thành tương lai của tự động hóa và tích hợp dịch vụ cùng với làn sóng thiết kế 'API-first'. Nhưng các doanh nghiệp nhanh chóng nhận ra rằng cung cấp năng lực như vậy sẽ đe dọa mô hình doanh thu của họ, nên hướng đi đó sớm bị bẻ lái. Cuối cùng họ lại nhận ra rằng mọi dòng tiền đều phụ thuộc vào việc người dùng không có những quyền này
Tôi nghĩ RSS không hề thất bại mà ngược lại còn cực kỳ thành công. Sau khi Google Reader biến mất, tôi chuyển sang trình đọc khác và suốt hơn 20 năm qua các feed RSS vẫn hoạt động tốt, không gặp vấn đề gì. Tôi gần như chưa từng gặp trang web nào không hỗ trợ RSS
Phần lớn website vẫn hỗ trợ RSS, và một số còn mặc định có feed ngay cả khi không hiển thị trên trang. Dù một số nơi không công khai toàn bộ nội dung, nó vẫn rất có giá trị như thông báo cập nhật hoặc trigger tự động hóa. RSS vẫn đang sống khỏe và cực kỳ hữu ích, kiểu như lò vi sóng: cứ mặc nhiên tồn tại ở đó
Cấu trúc thị trường đã thay đổi, nên giờ các công ty lớn tập trung vào 'lớp trí tuệ' hơn là bản thân nội dung. Nội dung ngày càng bị hàng hóa hóa. Google cần nắm lấy ánh nhìn, sự chú ý của người dùng và công nghệ đủ thông minh để giữ họ lại thì mới tiếp tục bán quảng cáo được. Lý do Google không muốn RSS là vì RSS có thể đi vòng qua Google Search
Khi AI sớm có khả năng click và cuộn như con người, sẽ lại có thêm một vòng cạnh tranh vô hạn nữa
Lịch sử đóng góp của dự án Github rất thú vị (trích dẫn trực tiếp liên kết). MiguelsPizza commit 3 lần, Claude 2 lần, nhưng lượng mã Claude thay đổi gần như áp đảo hoàn toàn
Đã có lúc extension tạm thời bị chuyển sang chế độ riêng tư và lịch sử git được điều chỉnh nên có khác đôi chút so với thực tế. Dù vậy, việc Claude viết khoảng 85% tổng mã là sự thật
Có vẻ sau này kiểu mẫu này (đóng góp mã quy mô lớn dựa trên AI) sẽ ngày càng phổ biến hơn
Biểu đồ commit của Claude rất đặc biệt. Trông như thể Claude Code trực tiếp commit, nhưng thực ra hầu như không phải vậy. Xem thêm hồ sơ claude
Nếu xem danh sách commit thực tế thì tất cả đều mang tên MiguelsPizza / Alex Nahas (liên kết). Trông có gì đó lạ lạ
Có nhắc tới một phần trích từ blog, bàn về vấn đề xác thực của MCP. OAuth2.1 về dài hạn vẫn ổn, nhưng hiện giờ lại rơi vào tình huống phải tái phát minh cách xác thực dành cho agent hành động thay người dùng. Rủi ro rò rỉ dữ liệu trong ứng dụng đa tenant vẫn chưa được giải quyết
Việc giới hạn phạm vi thiệt hại và dữ liệu truy cập của model có thể là một lợi thế lớn của MCP. API phía client trong ứng dụng đa tenant vốn được kỳ vọng đã bị giới hạn theo phạm vi người dùng, nên nếu chỉ đưa phần đó cho model thì thiệt hại sẽ không lớn. Cũng có nhắc tới vấn đề tương thích giữa hệ thống xác thực nội bộ của Amazon và OAuth2.1 (ở Amazon cách xác thực khác)
Có người thắc mắc liệu một phần chức năng của OAuth2.1 đã được đề cập trong RFC 8693 về ủy quyền và mạo danh hay chưa
Phạm vi model có thể truy cập rốt cuộc vẫn giống người dùng, nên việc triển khai bảo mật chắc chắn là trách nhiệm của quản trị viên website
Tôi không nghĩ ví dụ Amazon áp dụng OAuth không đúng là vấn đề cốt lõi. Một kiểu truy cập hậu môn vượt quá phạm vi quyền của người dùng là cực kỳ nguy hiểm. Nếu mọi hành vi của ứng dụng MCP đều được ghi nhận vào cùng nhóm với truy cập của người dùng thì có thể phát sinh rất nhiều vấn đề compliance. Xét theo góc nhìn này thì rất thú vị, nhưng về mặt bảo mật có vẻ dễ trở thành một đường vòng đầy rủi ro
Có người đưa ra ý tưởng rằng chỉ cần công bố đặc tả Swagger(OpenAPI) và có một swagger mcp client dùng chung là gần như thay thế được tất cả những phần triển khai này rồi. Có vẻ chỉ cần để người dùng tự mở phiên xác thực bằng tay. Người đó cũng đề xuất rằng Claude nếu đọc tốt API key từ prompt/cấu hình thì dùng API client dựa trên swagger chẳng phải cũng như nhau sao
Đây là cách mà ai cũng nghĩ đến đầu tiên khi MCP xuất hiện. Nhưng trên thực tế người ta nhận ra có quá nhiều tool nên nó không hoạt động tốt. Dù vậy, các thử nghiệm thú vị trong lĩnh vực này vẫn tiếp tục
Cũng có lời nhắc phải cẩn thận đừng đưa API key vào prompt
Claude Code chỉ cần được cho link swagger.json trong CLAUDE.md là việc test API đã trở nên cực kỳ tiện lợi
Họ khuyến khích cứ tự thử đi
Không rõ ai là người dùng mục tiêu. Trong test frontend, việc UI thay đổi lớn làm test bị gãy thực ra lại là điều hữu ích. Còn nếu mục đích là tự động hóa ở những chỗ khác thì tôi nghĩ cung cấp API thật sẽ tốt hơn
Trước phép so sánh rằng 'nếu làm bàn ở Home Depot thì còn khó hơn', có người nêu thắc mắc rằng Home Depot cũng đầy gỗ mà
Home Depot còn bán cả bàn làm sẵn nữa
Ở Home Depot thậm chí có cả dụng cụ chính xác tốt hơn lẫn chuyên gia, nên có khi còn dễ làm hơn
Có người đùa theo kiểu 'gỗ thì bạn phải tự tưởng tượng rồi tạo ra chứ'
Tác giả nói đã chỉnh lại câu chữ để phản ánh góp ý đó
Tôi chưa trực tiếp dùng MCP, nhưng dưới góc nhìn của người khuyết tật thì MCP có vẻ có tiềm năng rất lớn cho các ứng dụng accessibility trong tự động hóa trình duyệt và smartphone. Tuy vậy, cũng băn khoăn liệu công nghệ như vậy có bị kẻ xấu lạm dụng nên rốt cuộc các web/app lớn sẽ không dám triển khai hay không. Không biết đã có trường hợp nào thực sự dùng nó để cải thiện accessibility chưa
Cảm thấy biết ơn vì MCP-B được phát hành mã nguồn mở. Dù hầu hết mọi thứ diễn ra trong trình duyệt, MCP có một giả định hơi khác là AI client sẽ thực hiện công việc. Về căn bản, người này thắc mắc MCP-B khác gì với việc nối trực tiếp JS API của web app vào LLM server để dùng. Rốt cuộc có phải là cùng một thứ không, hay còn có bức tranh lớn hơn
Chỉ nhìn nội dung trên trang chủ thì vẫn khó hiểu, nên có người hỏi liệu nó có cảm giác như phiên bản trình duyệt của Selenium không
Có người dự đoán rằng nếu tự động hóa trình duyệt bằng MCP bắt đầu nhắm tới người dùng LLM miễn phí, thì sẽ đến lúc ngay cả model miễn phí cũng bị yêu cầu Captcha. Vấn đề là Captcha lại không hiệu quả lắm với LLM, nên cuối cùng có thể mở ra một thời đại chiến tranh robot kỳ quặc, nơi các LLM phải đánh nhau để chặn quyền truy cập của các LLM tự động hóa khác