WebMCP: Biến Website Thành Công Cụ Cho AI Agent

Posted on: 10/12/2026 1:13:36 AM

Hãy quan sát một AI agent đang cố đặt một lịch hẹn trên website của bạn. Nó chụp màn hình, đoán đâu là ô "Ngày", click nhầm vào banner khuyến mãi, cuộn xuống, chụp lại, đọc cây accessibility, gõ ngày sai định dạng, rồi chờ trang báo lỗi. Ba mươi giây và vài chục nghìn token để làm một việc mà người dùng chỉ mất năm giây. Chỉ cần đội frontend đổi tên một class CSS, toàn bộ "kỹ năng" đó sụp đổ.

WebMCP đề xuất một cách khác hẳn: thay vì để agent đoán giao diện, chính website khai báo những việc nó cho phép làm — dưới dạng các tool có tên, mô tả bằng ngôn ngữ tự nhiên và JSON Schema cho tham số. Agent chạy trong trình duyệt chỉ việc gọi book_appointment({ date: "2026-10-20", slot: "09:00" }), website thực thi bằng chính JavaScript của mình, với phiên đăng nhập sẵn có của người dùng, và giao diện cập nhật ngay trước mắt họ. Bài viết này mổ xẻ WebMCP ở thời điểm tháng 10/2026: cách nó hoạt động, hai API khai báo và lập trình, khác gì MCP, mô hình bảo mật, cách thiết kế tool để agent dùng đúng, và có nên áp dụng ngay hay chưa.

1. Ba cách agent đang "dùng" web — và vì sao đều chưa ổn

Để hiểu WebMCP giải quyết vấn đề gì, hãy nhìn ba con đường mà agent hiện dùng để tương tác với một website:

• Nhìn pixel (computer use / vision): chụp màn hình, cho model đa phương thức đoán toạ độ rồi click. Tổng quát nhất, nhưng chậm, tốn token ảnh và rất nhạy với thay đổi layout, popup, A/B test.
• Đọc DOM hoặc cây accessibility: các framework như Playwright MCP hay Browser Use chuyển trang thành cấu trúc văn bản để model chọn phần tử. Nhanh hơn, nhưng vẫn là suy luận ngược từ UI vốn thiết kế cho mắt người: agent phải tự hiểu rằng ba ô input và một nút "Tiếp tục" nghĩa là "đặt lịch".
• Gọi API backend (MCP server, REST): chính xác và ổn định, nhưng chạy tách khỏi phiên trình duyệt của người dùng. Phải làm OAuth riêng, phải duy trì một server riêng, và người dùng không nhìn thấy điều gì đang diễn ra.

WebMCP là con đường thứ tư: giữ lại ngữ cảnh trình duyệt (cookie, phiên đăng nhập, trạng thái giỏ hàng, trang đang xem) như hai cách đầu, nhưng có hợp đồng rõ ràng như cách thứ ba. Website trở thành "MCP server" của chính nó, sống trong tab, không cần backend mới.

flowchart LR
  A["AI Agent trong trình duyệt"]
  A --> V["Nhìn pixel
chụp màn hình rồi click"]
  A --> D["Đọc DOM / cây accessibility
đoán phần tử cần thao tác"]
  A --> M["Gọi MCP server backend
OAuth riêng, ngoài tab"]
  A --> W["WebMCP
gọi tool do trang khai báo"]
  V --> R1["Chậm, dễ gãy khi đổi layout"]
  D --> R2["Nhanh hơn nhưng vẫn phải đoán ý"]
  M --> R3["Ổn định nhưng mất ngữ cảnh phiên"]
  W --> R4["Có schema, dùng phiên sẵn có,
người dùng thấy UI cập nhật"]
  style A fill:#2c3e50,stroke:#fff,color:#fff
  style W fill:#e94560,stroke:#fff,color:#fff
  style R4 fill:#f8f9fa,stroke:#e94560,color:#2c3e50
  style V fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
  style D fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
  style M fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50

2. WebMCP là gì, và nó đang ở đâu

WebMCP (Web Model Context Protocol) là một đề xuất chuẩn web do W3C Web Machine Learning Community Group phát triển, với các biên tập viên đến từ Microsoft và Google. Cần nói rõ ngay: đây là Draft Community Group Report, chưa phải W3C Recommendation và chưa nằm trên standards track. Tên gọi có chữ MCP vì nó mượn các khái niệm cốt lõi của Model Context Protocol (tool, mô tả, input schema), nhưng không dùng lớp giao thức JSON-RPC của MCP — trình duyệt đứng giữa làm trung gian.

3. Kiến trúc: trình duyệt là người trung gian

Điểm mấu chốt của WebMCP là trang web không nói chuyện trực tiếp với model. Trang đăng ký tool vào document.modelContext; agent (Gemini trong Chrome, một extension, hay một agent bên ngoài điều khiển trình duyệt) hỏi trình duyệt danh sách tool, chọn tool, và trình duyệt gọi hàm execute của trang. Kết quả đi ngược lại theo đúng đường đó.

sequenceDiagram
  actor U as Người dùng
  participant AG as Agent (vd Gemini in Chrome)
  participant BR as Trình duyệt
  participant P as Trang web (tab đang mở)
  P->>BR: registerTool(name, description, inputSchema, execute)
  U->>AG: "Đặt lịch khám thứ Hai tuần sau, buổi sáng"
  AG->>BR: getTools()
  BR-->>AG: Danh sách tool + JSON Schema
  AG->>U: "Thứ Hai 19/10, khung 9h hay 10h?"
  U->>AG: "9h"
  AG->>BR: executeTool(book_appointment, {date, slot})
  BR->>BR: Kiểm tra permissions policy, annotation, xác nhận nếu cần
  BR->>P: Gọi execute() với cookie và phiên sẵn có
  P->>P: Gọi API nội bộ, cập nhật UI trước mắt người dùng
  P-->>BR: { content: [...] } hoặc thông báo lỗi
  BR-->>AG: Kết quả tool
  AG-->>U: "Đã đặt lịch 9h thứ Hai 19/10"

Kiến trúc này có ba hệ quả quan trọng:

• Tool là tạm thời, gắn với tab. Tool chỉ tồn tại khi trang đang mở. Người dùng chuyển trang hoặc đóng tab là agent mất quyền truy cập. Không có "server" nào chạy nền.
• Tool chạy với quyền của người dùng. Hàm execute chạy trong trang, dùng chung cookie, token và trạng thái ứng dụng. Không cần OAuth riêng cho agent — nhưng cũng có nghĩa là một agent bị thao túng có thể làm mọi thứ người dùng làm được (xem mục 8).
• Người dùng nhìn thấy. Vì tool tác động lên chính UI đang hiển thị, người dùng quan sát được agent làm gì và có thể huỷ giữa chừng. Đây là khác biệt lớn về niềm tin so với agent chạy headless ở backend.

4. Declarative API: biến form có sẵn thành tool

Cách nhanh nhất để "agent-ready" là thêm vài thuộc tính vào những form bạn đã có. Trình duyệt tự suy ra JSON Schema từ các trường của form.

<form toolname="book_appointment"
      tooldescription="Đặt lịch khám tại phòng khám. Trả về mã lịch hẹn."
      action="/appointments" method="post">

  <label for="dept">Chuyên khoa</label>
  <select id="dept" name="department" required
          toolparamdescription="Chuyên khoa cần khám, quyết định bác sĩ được phân công.">
    <option value="general">Nội tổng quát</option>
    <option value="pediatrics">Nhi</option>
    <option value="dermatology">Da liễu</option>
  </select>

  <label for="date">Ngày khám</label>
  <input id="date" name="date" type="date" required
         toolparamdescription="Ngày khám, định dạng YYYY-MM-DD.">

  <label for="note">Triệu chứng</label>
  <textarea id="note" name="note"></textarea>

  <button type="submit">Đặt lịch</button>
</form>

Các thuộc tính chính:

• toolname và tooldescription trên <form>: định danh tool. Xoá một trong hai thuộc tính là tool bị huỷ đăng ký.
• toolparamdescription trên từng trường: mô tả tham số. Nếu bỏ trống, trình duyệt lấy nội dung <label>, rồi tới aria-description — một lý do nữa để viết form có label đúng chuẩn accessibility.
• toolautosubmit: khi có, agent điền xong là form được submit luôn. Khi không có, agent chỉ điền sẵn và người dùng phải tự bấm nút — mặc định an toàn cho các hành động có hậu quả.

Ở phía JavaScript, trang có thể biết lần submit này đến từ agent và trả kết quả có cấu trúc thay vì điều hướng sang trang mới:

form.addEventListener('submit', (e) => {
  if (!e.agentInvoked) return;          // người dùng tự bấm: giữ hành vi cũ
  e.preventDefault();
  e.respondWith((async () => {
    const res = await fetch('/api/appointments', {
      method: 'POST',
      body: new FormData(form)
    });
    if (!res.ok) return 'Khung giờ đã kín. Hãy gọi lại với ngày khác.';
    const { code, time } = await res.json();
    return `Đã đặt lịch ${time}, mã ${code}.`;
  })());
});

Trang cũng nhận được sự kiện toolactivated (khi agent đã điền sẵn các trường) và toolcancel (khi người dùng huỷ hoặc form bị reset) trên document.modelContext — hữu ích để hiện gợi ý "Trợ lý đang điền giúp bạn" hoặc ghi log.

5. Imperative API: tool cho ứng dụng SPA phức tạp

Không phải hành động nào cũng là một form. Lọc danh sách, thêm sản phẩm vào giỏ, chuyển tab, đọc trạng thái đơn hàng — những thứ này cần API lập trình:

// Tương thích cả draft cũ và mới
const mc = document.modelContext ?? navigator.modelContext;

if (mc) {
  const controller = new AbortController();

  await mc.registerTool({
    name: 'search_orders',
    description: 'Tìm đơn hàng của người dùng hiện tại trong một khoảng thời gian. ' +
                 'Trả về mã đơn, trạng thái giao hàng và địa điểm hiện tại.',
    inputSchema: {
      type: 'object',
      properties: {
        from:   { type: 'string', description: 'Ngày bắt đầu, YYYY-MM-DD' },
        to:     { type: 'string', description: 'Ngày kết thúc, YYYY-MM-DD' },
        status: { type: 'string', enum: ['pending', 'shipping', 'delivered', 'returned'] }
      },
      required: ['from', 'to']
    },
    annotations: { readOnlyHint: true },
    execute: async ({ from, to, status }, { signal }) => {
      const orders = await api.orders.search({ from, to, status }, { signal });
      store.setOrderFilter({ from, to, status });   // UI cập nhật theo
      if (orders.length === 0)
        return 'Không có đơn nào. Gợi ý: mở rộng khoảng ngày hoặc bỏ lọc trạng thái.';
      return { content: [{ type: 'text', text: JSON.stringify(orders.slice(0, 20)) }] };
    }
  }, { signal: controller.signal });

  // Khi rời khỏi route này:
  // controller.abort();
}

Vài điểm đáng chú ý:

• Huỷ đăng ký bằng AbortSignal. Truyền { signal } làm tham số thứ hai, gọi abort() khi component unmount. Từ Chrome 153, huỷ đăng ký không làm gãy các lời gọi đang chạy dở.
• Hàm execute nhận signal riêng để huỷ fetch khi agent hoặc người dùng dừng giữa chừng.
• Tool nên thay đổi theo trạng thái ứng dụng. Trang giỏ hàng có update_quantity, apply_coupon; trang checkout mới có place_order. Agent nghe sự kiện toolchange để biết danh sách đã đổi. Đăng ký tool theo route là cách tự nhiên để giới hạn những gì agent làm được ở mỗi bước.
• Tool trong iframe khác origin bị tắt mặc định bởi permissions policy tools (mặc định self); muốn bật phải khai báo <iframe allow="tools">.

Với React, Vue hay Angular, mẫu phổ biến là bọc việc đăng ký trong một hook hoặc composable: đăng ký khi mount, abort khi unmount, và để execute gọi thẳng vào store/action sẵn có thay vì viết logic mới. Tool khi đó chỉ là một "cổng vào" khác của cùng business logic mà nút bấm đang dùng.

6. WebMCP và MCP: không phải chọn một

Một hiểu lầm phổ biến là WebMCP sẽ thay MCP server. Thực tế chúng phục vụ hai ngữ cảnh khác nhau và được thiết kế để dùng song song:

flowchart TB
  subgraph Client["Phía người dùng"]
    AG["Agent trong trình duyệt"]
    TAB["Tab website
WebMCP tools"]
    AG -->|"executeTool"| TAB
  end
  subgraph Backend["Phía hệ thống"]
    API["Business API / Domain services"]
    MCPS["MCP server"]
    MCPS --> API
  end
  DESK["Agent desktop / IDE / workflow nền"] -->|"JSON-RPC"| MCPS
  TAB -->|"fetch với phiên người dùng"| API
  style AG fill:#2c3e50,stroke:#fff,color:#fff
  style TAB fill:#e94560,stroke:#fff,color:#fff
  style MCPS fill:#16213e,stroke:#fff,color:#fff
  style API fill:#f8f9fa,stroke:#e94560,color:#2c3e50
  style DESK fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50

Kiến trúc hợp lý cho một sản phẩm SaaS: business logic nằm ở API như cũ; MCP server phục vụ agent chạy ngoài trình duyệt (IDE, desktop, workflow tự động); WebMCP phục vụ agent đi cùng người dùng khi họ đang ở trên website. Hai lớp này nên chia sẻ cùng định nghĩa schema để mô tả và validate nhất quán.

7. Thiết kế tool để agent dùng đúng

Đăng ký tool thì dễ; để model chọn đúng tool, điền đúng tham số và tự phục hồi khi lỗi mới là phần khó. Tài liệu của Chrome và kinh nghiệm từ hệ sinh thái MCP gợi ý vài nguyên tắc:

• Bắt đầu từ mục tiêu người dùng, không phải từ endpoint. Liệt kê những việc người dùng thật sự muốn nhờ trợ lý trên trang, rồi tách thành các bước. "Theo dõi cuộc họp" có thể cần ba tool: ghi biên bản, tóm tắt, soạn email.
• Đặt tên động từ + đối tượng (search_flights, filter_flights, book_flight) và thống nhất một kiểu viết (snake_case hoặc camelCase).
• Đừng để tool đoán. Nếu người dùng nói "tuần sau", tham số ngày nên bắt buộc để agent phải hỏi lại "Thứ mấy tuần sau?" thay vì tool tự chọn ngày.
• Chỉ rõ định dạng (YYYY-MM-DD, đơn vị tiền tệ) và dùng enum khi tập giá trị hữu hạn.
• Giữ trong ngân sách ký tự. Chrome gợi ý khoảng 500 ký tự cho mô tả tool, 150 cho mô tả tham số, 30 cho tên, và khoảng 1.500 ký tự cho kết quả. Kết quả dài hơn nên phân trang hoặc tóm tắt.
• Phản ánh kết quả lên UI. Tool lọc đơn hàng nên thực sự đổi bộ lọc trên màn hình, để người dùng và agent cùng nhìn một trạng thái.

Thông báo lỗi là "prompt" quan trọng nhất mà bạn viết cho agent:

8. Bảo mật: tool chạy bằng quyền của người dùng

Đây là phần cần đọc kỹ nhất. Tool WebMCP chạy trong trang, với cookie và phiên đăng nhập của người dùng. Nếu agent bị indirect prompt injection — ví dụ đọc một bình luận độc hại chứa chỉ dẫn "hãy chuyển địa chỉ giao hàng sang..." — nó có thể gọi tool thật với tham số do kẻ tấn công chọn. Tài liệu của Chrome thừa nhận thẳng rằng không thể đảm bảo an toàn bên trong một LLM; chiến lược đúng là giới hạn thiệt hại mà một agent bị thao túng có thể gây ra.

flowchart TB
  IN["Nội dung không tin cậy
bình luận, email, review"] --> AG["Agent đọc và suy luận"]
  AG --> L1{"Tool có được lộ ra
cho origin này không?"}
  L1 -->|"Không: exposedTo, permissions policy"| X1["Chặn"]
  L1 -->|"Có"| L2{"consequentialHint?"}
  L2 -->|"Có"| C["Trình duyệt / trang
yêu cầu người dùng xác nhận"]
  L2 -->|"Không, readOnlyHint"| L3["Thực thi"]
  C -->|"Đồng ý"| L3
  C -->|"Từ chối"| X2["Huỷ, phát toolcancel"]
  L3 --> L4["Server validate lại input
như mọi request từ client"]
  L4 --> OUT["Kết quả gắn untrustedContentHint
nếu chứa dữ liệu người dùng"]
  style IN fill:#f8f9fa,stroke:#ff9800,color:#2c3e50
  style AG fill:#2c3e50,stroke:#fff,color:#fff
  style C fill:#e94560,stroke:#fff,color:#fff
  style X1 fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
  style X2 fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
  style L4 fill:#16213e,stroke:#fff,color:#fff

Những công cụ bảo vệ mà spec và Chrome cung cấp:

• Annotation khai báo rủi ro (mặc định đều là false):
  • readOnlyHint: tool chỉ đọc, không đổi trạng thái — giúp agent quyết định khi nào không cần hỏi xác nhận.
  • consequentialHint: hành động có hậu quả lớn hoặc không đảo ngược (thanh toán, đặt vé, xoá dữ liệu) — cho phép trình duyệt buộc người dùng xác nhận.
  • untrustedContentHint: kết quả chứa nội dung do người dùng khác tạo hoặc từ nguồn ngoài — báo cho agent bọc và xử lý thận trọng để giảm prompt injection gián tiếp.
• requestUserInteraction() trong spec draft: tool có thể chủ động xin người dùng xác nhận hoặc nhập thêm thông tin giữa lúc thực thi.
• Cô lập theo origin. Mặc định trang khác và iframe khác origin không thấy tool của bạn; muốn chia sẻ phải liệt kê qua exposedTo. Tool chỉ đọc vẫn có thể làm lộ dữ liệu người dùng, nên chỉ expose cho đối tác bạn sẵn sàng chia sẻ dữ liệu đó.
• Chỉ trên HTTPS (secure context) và chịu permissions policy tools.

9. Góc UX: agent và người dùng cùng nhìn một màn hình

WebMCP thú vị với người làm UX vì nó mở ra mô hình "đồng điều khiển": agent thao tác, người dùng quan sát và có quyền chặn lại. Để mô hình này đáng tin, giao diện cần cho người dùng biết chuyện gì đang xảy ra.

Chrome thêm hai pseudo-class: :tool-form-active cho form đang được agent điều khiển và :tool-submit-active cho nút submit tương ứng. Mặc định trình duyệt vẽ viền nét đứt; bạn có thể tuỳ biến cho hợp design system:

form:tool-form-active {
  outline: 2px dashed var(--brand-accent);
  outline-offset: 6px;
}
form:tool-form-active::before {
  content: "Trợ lý AI đang điền giúp bạn — kiểm tra trước khi gửi";
  display: block;
  font-size: .875rem;
  margin-bottom: .5rem;
}
button:tool-submit-active {
  box-shadow: 0 0 0 3px var(--brand-accent);
}

Một số nguyên tắc UX đáng áp dụng:

• Mặc định không auto-submit với hành động có hậu quả: để agent điền, người dùng bấm. Đây là "human in the loop" rẻ nhất có thể.
• Cho thấy dấu vết. Khi tool lọc danh sách hay đổi tab, hãy cập nhật UI và URL như thể người dùng tự làm, để họ có thể tiếp tục từ đó.
• Huỷ phải dễ. Lắng nghe toolcancel để khôi phục trạng thái và không để form ở trạng thái điền dở.
• Form tốt cho người thì tốt cho agent. Label rõ, required, type đúng, thông báo lỗi cụ thể — những thứ accessibility đòi hỏi từ lâu giờ trực tiếp làm agent chính xác hơn.

10. Kiểm thử và công cụ

• Bật flag chrome://flags/#enable-webmcp-testing để dùng WebMCP khi phát triển mà không cần token origin trial.
• Model Context Tool Inspector: extension liệt kê tool của trang, cho chạy thử và dùng prompt ngôn ngữ tự nhiên để xem agent có gọi đúng tool không (cần API key Gemini của bạn).
• Model chạy trên máy: bật chrome://flags/#prompt-api-tool-use để thử với Prompt API mà không cần API key.
• DevTools cho phép debug tool và kiểm tra trình duyệt parse JSON Schema thế nào — hữu ích khi tool khai báo theo kiểu declarative.
• Lighthouse có các audit kiểm tra tool đã đăng ký, độ phủ form và tính hợp lệ của schema; trang không dùng WebMCP sẽ nhận "Not Applicable".
• Polyfill MCP-B cung cấp API cho trình duyệt chưa hỗ trợ, tiện để chạy thử với agent dạng extension.

11. Có nên áp dụng ngay? Lộ trình bốn bước

Với hầu hết đội sản phẩm, câu trả lời hợp lý là: chuẩn bị ngay, bật dần, đo kỹ. Phần lớn công việc chuẩn bị có lợi ngay cả khi WebMCP không bao giờ thành chuẩn.

flowchart LR
  S1["Bước 1
Chuẩn hoá form và business action
label, schema, lỗi rõ ràng"] --> S2["Bước 2
Declarative trên 2-3 form
tác động thấp, không auto-submit"]
  S2 --> S3["Bước 3
Imperative cho tool đọc
readOnlyHint, theo route"]
  S3 --> S4["Bước 4
Tool ghi có xác nhận
consequentialHint, log, evals"]
  style S1 fill:#f8f9fa,stroke:#e94560,color:#2c3e50
  style S2 fill:#f8f9fa,stroke:#e94560,color:#2c3e50
  style S3 fill:#2c3e50,stroke:#fff,color:#fff
  style S4 fill:#e94560,stroke:#fff,color:#fff

1. Chuẩn hoá trước. Gom các hành động nghiệp vụ thành hàm rõ ràng (đặt lịch, tìm đơn, thêm giỏ) với schema validate dùng chung cho UI, API và MCP server. Form có label chuẩn, lỗi rõ nghĩa.
2. Declarative trên vài form an toàn: tìm kiếm, lọc, đăng ký nhận tin. Không dùng toolautosubmit cho bất kỳ thứ gì tốn tiền.
3. Imperative cho tool chỉ đọc: tra cứu đơn, so sánh gói, kiểm tra tồn kho. Đăng ký theo route, đánh dấu readOnlyHint, gắn untrustedContentHint nếu trả về review hay bình luận.
4. Tool ghi dữ liệu sau cùng, với consequentialHint, xác nhận người dùng, log đầy đủ, rate limit phía server và bộ evals chạy trong CI.

Luôn feature-detect (document.modelContext ?? navigator.modelContext) và coi WebMCP là progressive enhancement: trình duyệt không hỗ trợ thì website vẫn chạy bình thường, chỉ là agent phải quay về cách nhìn pixel hay đọc DOM.

Kết luận

Trong hơn hai mươi năm, chúng ta tối ưu website cho hai loại "người đọc": con người và bot của công cụ tìm kiếm. WebMCP là nỗ lực đầu tiên ở tầng chuẩn web để thêm loại thứ ba — AI agent — mà không bắt nó phải giả làm người. Ý tưởng cốt lõi rất đơn giản: thay vì để agent đoán giao diện, hãy nói cho nó biết trang làm được gì, với hợp đồng rõ ràng và ranh giới bảo mật rõ ràng.

Chuẩn này còn non: chưa có trình duyệt nào ngoài Chromium cam kết, API vừa đổi chỗ ở document, và chưa có agent phổ biến nào thực sự dùng. Nhưng phần việc chuẩn bị — tách business action thành hàm có schema, form có label tốt, thông báo lỗi giúp người đọc tự sửa, xác nhận cho mọi hành động quan trọng — đều làm sản phẩm của bạn tốt hơn ngay hôm nay, cho cả người dùng lẫn agent. Một thử nghiệm nhỏ cho sprint tới: chọn form tìm kiếm của bạn, thêm toolname và tooldescription, bật flag và xem một agent dùng nó như thế nào.