WebMCP là gì: khi website tự phơi "công cụ" cho AI agent

#WebMCP thực ra giải quyết chuyện gì (góc web owner)

Suốt hai năm qua, tối ưu web cho AI xoay quanh được đọc và được trích dẫn: đó là AEO/GEO. WebMCP mở một mặt trận khác — được thao tác. Khi một AI agent thay người dùng đặt lịch, lọc sản phẩm, hay điền một form nhiều bước, nó phải làm gì đó trên trang, không chỉ đọc.

Cách agent làm việc đó hôm nay chủ yếu là "nhìn màn hình như người": chụp ảnh trang → đưa vào mô hình thị giác → đoán nút nằm đâu → bấm → chụp lại → lặp. Cách này mong manh: đổi CSS một chút là gãy, mỗi bước là một vòng token đắt đỏ, và trang web không hề biết agent đang cố làm gì.

WebMCP lật ngược: thay vì để agent đọc ngược giao diện, website chủ động khai báo những việc nó làm được. Agent nhận một danh sách tool kèm mô tả và schema tham số (kiểu JSON Schema), rồi gọi đúng tool nó cần — một lượt, có cấu trúc, ít đoán mò. Điểm mấu chốt mà một MCP server thường ở backend khó chạm tới: trang web đang giữ sẵn trạng thái đăng nhập, dữ liệu phiên và logic nghiệp vụ; WebMCP chạy ngay trong trình duyệt nên tận dụng được hết mà không phải dựng lại một server riêng.

So sánh cách AI agent thao tác website — trước và với WebMCP:

WebMCP đảo chiều: thay vì agent đọc ngược giao diện, website chủ động khai báo việc nó làm được.

#Hai cách khai báo tool: declarative và imperative

WebMCP cho hai lối, ứng với hai mức phức tạp:

• Declarative (qua HTML form). Với những hành động vốn đã là form — tìm kiếm, lọc, đăng ký — bạn chỉ cần chú thích thêm vào markup form sẵn có (tên tool, mô tả) để nó thành một WebMCP tool. Ít code nhất, hợp với phần lớn trang nội dung/thương mại.
• Imperative (qua JavaScript). Với luồng động, nhiều bước, cần logic — bạn định nghĩa tool bằng JS qua navigator.modelContext.provideContext(...), mỗi tool có name, description, một inputSchema (JSON Schema) và một hàm thực thi. Về hình dạng, nó giống cách định nghĩa tool khi gọi API của OpenAI hay Anthropic — nhưng chạy hoàn toàn client-side, trong trình duyệt.

Một phác thảo tối giản của lối imperative (API còn đang thay đổi theo spec, xem như minh hoạ hình dạng chứ không phải mã production):

// Website khai báo một tool cho AI agent, ngay trong trình duyệt
navigator.modelContext.provideContext({
  tools: [
    {
      name: "search_products",
      description: "Tìm sản phẩm theo từ khoá và khoảng giá",
      inputSchema: {
        type: "object",
        properties: {
          query: { type: "string" },
          maxPrice: { type: "number" },
        },
        required: ["query"],
      },
      async execute({ query, maxPrice }) {
        // Tận dụng chính logic + trạng thái phiên của trang
        const results = await store.search(query, { maxPrice });
        return { results };
      },
    },
  ],
});

Agent không cần biết nút "Tìm" nằm ở đâu trên màn hình; nó đọc search_products, gửi tham số đúng schema, nhận kết quả có cấu trúc.

#Ranh giới an toàn (đừng bỏ qua)

Vì WebMCP để agent chạy hành động trên trang, bảo mật là phần không được xem nhẹ:

• Chỉ chạy trong secure context — HTTPS, và trên tài liệu được origin-isolated. Không có chuyện phơi tool bừa trên trang http.
• Cùng chính sách của nền web — same-origin, CSP áp dụng như mọi tính năng khác.
• Permission/consent — được kiểm soát qua Permissions Policy tools (mặc định self); iframe khác origin phải có allow="tools". Nghĩa là bạn quyết ai được phơi tool, không phải mặc định mở.

Nguyên tắc delivery tôi giữ: tool ghi/không đảo ngược thì luôn có xác nhận. Cho agent tra cứu, lọc, xem — thoải mái; cho agent "đặt đơn", "huỷ lịch", "thanh toán" — phải có bước người xác nhận, y như khi thiết kế bất kỳ tool nguy hiểm nào.

#Khung sẵn sàng WebMCP cho website (4 trục)

Đây là phần làm được ngay bây giờ, dù WebMCP còn preview — vì phần lớn là dọn nền tảng, không phải cược vào một API chưa chốt. Tôi soi bốn trục:

Cách đọc khung cho gọn: chưa cần viết một dòng WebMCP nào, bạn vẫn có thể "sẵn sàng" bằng cách biết rõ tool của mình là gì, form nào sạch, hành động nào nguy hiểm. Khi API ổn định, phần bổ sung chỉ còn là kỹ thuật.

#WebMCP nằm ở đâu trong bức tranh (đừng nhầm)

Ba thứ bổ trợ nhau, không thay thế nhau. AEO/GEO lo được đọc; WebMCP lo được làm. Nếu bạn đang tối ưu để AI trích dẫn (xem khung 5 trục AEO/GEO), thì WebMCP là bước kế: chuẩn bị cho ngày agent không chỉ đọc mà còn bấm.

#Cảnh báo: còn sớm, đừng cược lớn

Thành thật: WebMCP mới ở preview. API còn đổi, mới Chrome hỗ trợ (sau cờ), các trình duyệt khác chưa cam kết mốc thời gian. Vì vậy:

• Đừng đổ resource lớn để "làm WebMCP cho production" lúc này — spec chưa chốt.
• Đừng nhầm WebMCP với MCP server: một cái chạy trong trình duyệt trên trang bạn, một cái là server backend.
• Nên làm bốn trục ở khung trên — chúng có giá trị bất kể WebMCP về đích thế nào, và giúp bạn bật nhanh khi nó ổn định.

Đây đúng kiểu cửa sổ mà tôi thích chuẩn bị sớm: đủ mới để chưa ai chắc, đủ có căn cứ (Google + Microsoft + W3C, đã có bản chạy) để không phải hype suông.

#Kết

WebMCP là mảnh còn thiếu giữa AI agent và web: để agent làm việc trên trang mà không phải dò dẫm giao diện. Với chủ website, nó là lời nhắc rằng "tối ưu cho AI" sắp không dừng ở được-trích-dẫn, mà tiến tới được-thao-tác. Chưa cần vội code, nhưng nên bắt đầu nghĩ theo ngôn ngữ "tool": site của bạn cho phép làm những gì, cái nào an toàn để một agent gọi thay người dùng.

Đọc thêm trong cùng mạch: nền tảng giao thức MCP ở ghi chú khoá Model Context Protocol và bản nâng cao; còn khi bạn xây agent để dùng những tool này, xem Claude Agent SDK vs Claude API vs Claude Code. Toàn bộ lộ trình học Claude/agent gom ở /learn/claude.