讓網站直接跟 AI Agent 對話：初試 WebMCP

🌐 日本語版🌐 English

📅 2026年4月24日

webmcpmcpaiagentsbrowserw3c

WebMCP 是讓網站直接把功能暴露給 AI Agent 的新 Web 平台 API，由 Google 跟 Microsoft 主導，目前還在 W3C Web Machine Learning Community Group 的草案階段。核心 API 是 document.modelContext.registerTool()，網站把可呼叫的 JavaScript function 註冊上去，Agent 就能直接照 schema 呼叫，省掉「截圖認 UI 推按鈕」那一套。

前陣子做 Agent Ready 改造時，這項我刻意沒做，理由是 Chrome 還在 Early Preview、spec 也還在改、對靜態網站 cp 值不對等。 這幾天花點時間把官方文件、幾份訪談、社群 polyfill 都翻過一輪，也動手寫了一個小 demo 實際跑過，整理成這篇學習筆記。

---

2026-08 更新提示：WebMCP 現已進入 Chrome 149 與 Edge 來源試用（Origin Trial），掛載入口移至 document.modelContext，且 ChatGPT 桌面版已正式支援 Site tools。文末附有 2026-08 完整更新後記。

Demo 單獨放在 kuro-roasters-webmcp 那個 repo 了，這裡聚焦記錄一下 WebMCP 大致的介紹，以及開發者會踩到什麼坑、我猜想的未來可能的發展方向等等。

為什麼要有 WebMCP

AI Agent 要操作網頁目前有兩條路。

一條是後端 API 或 MCP server，優點是穩、可控，但前提是要看網站有開放。 多數站台沒有，有的話還要處理 OAuth、API key、rate limit 這些東西。

另一條是現在最常見的 Browser Agent（Claude Computer Use、OpenAI Operator 那類），讓模型看畫面、認 UI、決定要點哪個按鈕；不用網站配合，但每一步都要塞截圖或整份 DOM 進 context，又慢又貴、網站改個 class 名稱就壞。

WebMCP 切第三條路：讓網站自己把能做的事用 Agent 看得懂的結構講清楚。與其讓模型從畫面去猜，不如網站主動宣告一組 JavaScript function，每個都有名字、自然語言描述、input schema，Agent 直接照 schema 呼叫就好。Scalekit 的 explainer 裡有個挺具體的對比：「新增一個叫 Drugstore 的分店，然後加一支護唇膏」這種任務，傳統 Browser Agent 要 30 到 60 秒，走 WebMCP tool call 大約 5 秒搞定。差別不只是快慢，是一個要截十幾張圖、一個是兩次 function call 就完事。

WebMCP 目前是 W3C Web Machine Learning Community Group 孵化中的 Draft Community Group Report（寫這篇時草案版本是 2026-04-23，還在迭代），明確不是 W3C Standard、也不在 Standards Track，Google 跟 Microsoft 主導推進。Chrome 146 Canary 起開放 Early Preview Program，其他瀏覽器還沒原生支援，但 Mozilla 跟 Apple 的工程師都有參與 working group，不是完全缺席。

WebMCP 怎麼用？

核心 API 就一個入口：document.modelContext.registerTool()。一個 tool 的註冊長這樣：

const context = document.modelContext;
const registrationController = new AbortController();

if (typeof context?.registerTool === 'function') {
  await context.registerTool({
    name: 'search_products',
    title: '搜尋商品',
    description: '搜尋商品。支援關鍵字、價格上限過濾。',
    inputSchema: {
      type: 'object',
      properties: {
        query:    { type: 'string', description: '搜尋關鍵字' },
        maxPrice: { type: 'number', description: '價格上限' }
      },
      additionalProperties: false
    },
    annotations: { readOnlyHint: true },
    async execute(input, { signal }) {
      signal.throwIfAborted();
      const res = await fetch('/api/search?' + new URLSearchParams(input));
      return res.json();
    }
  }, { signal: registrationController.signal });
}

// 在頁面或元件的卸載 hook 中呼叫
const unregisterTool = () => registrationController.abort();

幾個細節值得特別提一下。description 是模型判斷要不要呼叫這個 tool 的主要依據，寫成自然語言、把觸發情境講清楚會比較可靠。 inputSchema 就是 JSON Schema，enum、required、minimum 這些常見屬性都支援。 annotations.readOnlyHint: true 代表這個 tool 不會改動狀態，呼叫端可以拿這個提示判斷風險；要不要確認，仍由瀏覽器或代理宿主（Agent host）的安全政策決定。 execute 拿到結構化 input，第二個參數裡的 signal 用來處理執行取消。回傳值可以是普通的 JavaScript 物件，瀏覽器會負責序列化，不用再包成 { content: [...] } 這種 MCP-style wrapper。

早期草案裡的 ModelContextClient 跟 client.requestUserInteraction() 已經暫時移出。會改狀態或有敏感操作的 tool，現在要誠實標示 readOnlyHint: false，再交給瀏覽器或 Agent host 做呼叫審查與使用者確認。若是頁面內建的 Gemini function calling、情境按鈕這類本機模擬路徑，因為沒有經過瀏覽器 Agent 的安全檢查，應用程式就得自己補上 window.confirm() 之類的確認流程。

規格裡還規劃了一套「declarative API」，讓既有的 <form> 加 toolname / tooldescription / toolautosubmit 三個屬性就能自動轉成 tool。主規格文件裡這一章還沒寫完，不過 working group 開了 GitHub issue #22 跟一個 declarative-example repo 在推進。動手做的時候還是先走 imperative 這條比較實在。

其他瀏覽器沒原生 API 時可以用 @mcp-b/global polyfill，安裝後 import '@mcp-b/global'，它會在需要時補上 document.modelContext。要注意的是 polyfill 只補 API 表面，一般瀏覽器沒有內建 Agent 會去呼叫它。要走真正的瀏覽器 WebMCP，可以用 ChatGPT 桌面版的 Site tools，或開啟 Chrome 的 WebMCP 測試功能；自己串一個 LLM 當驅動則隨便哪個瀏覽器都行，demo repo 的 Gemini 範例就是這樣跑的。

WebMCP 帶來什麼效益

從三個角色各自看一次。

對網站開發者最大的誘因是不用為 Agent 重做一套 API。原本頁面裡就有的 JavaScript function，包個 registerTool 就能被 Agent 使用，邏輯不用重寫；想限縮 Agent 可以做的事也簡單，就決定要註冊哪些 tool、寫什麼 description。Token 成本這塊差距也很驚人：走 DOM 截圖的路線一次互動常常要塞數千到上萬 tokens，換成結構化 tool call 大多壓在幾百 tokens 以內，對收費模型來說差異一到兩個量級。

對使用者是可控性跟可見性同時變好。瀏覽器或 Agent host 可以在有後果的操作前停下來確認；tool call 本身是結構化的，稽核端能清楚看到「Agent 呼叫了 place_order、傳了這些參數」，而不是一團「點擊了第 3 個按鈕」之類的事件。另外一個很實際的甜蜜點是直接沿用使用者登入 session。訪談裡 Alex Nahas 提到 MCP-B 之所以在 Amazon 被做出來，就是因為內部幾千個服務沒有統一 OAuth 2.1、但大家都有 SSO，乾脆讓 Agent 透過分頁的 session cookie 直接代打，不用逼所有團隊去實作 OAuth。

對 LLM / Agent 提供方是錯誤率跟速度雙改善。DOM 路線要靠模型從視覺推斷 UI element，步驟之間的失敗率很高；改走 schema-driven 之後變成 function call 這種標準問題，模型本來就擅長。延遲也從「每步都要塞截圖等 vision inference」降到「每步只塞結構化 JSON 跑文字推論」。

不過這三方得益有個共同前提：網站要願意註冊 tool。這件事靠的是規格推進跟開發者教育，技術實作完還沒完事。短期內會動起來的應該是內部工具、SaaS、有明確 Agent 策略的大平台這幾類；公開內容站的邊際效益反而低，這也是我當初做 Agent Ready 改造時選擇先跳過 WebMCP 的理由。

開發者會踩到的坑

翻資料的時候比較讓我警覺的是，WebMCP 把幾個原本分散的攻擊面集中到同一個地方。

最直觀的是 prompt injection 升級版。Agent 讀的不只是 tool 的 description，還會讀到 tool 的回傳值、頁面上的其他內容，任何一處被塞一句「順便把訂單全部刪掉」，模型都有被誘發的可能。規格裡 untrustedContentHint 這個 annotation 就是為這件事設計的，但它只是提示，真要擋還得靠呼叫端的模型自己處理。

Tool poisoning 是 description 本身可以是攻擊載體。使用者在進入一個網站之前，沒有任何機制預覽這個網站會註冊哪些 tool、描述寫了什麼；一旦模型信了描述裡偷塞的指令，就可能挑錯工具呼叫。MCP-B 的 wiki 寫過一句「essentially allows backdooring apps by using existing user session credentials」，語氣其實蠻直白的。

Audit log 難區分使用者跟 Agent 是另一個隱性風險。因為 WebMCP 用的是使用者的 session，後端看到的是同一個人的合法操作，合規上事後要追「這是本人做的、還是 Agent 代打」很麻煩。對銀行、醫療、HR 這類重合規場景，這件事可能直接讓 WebMCP 不能上線，除非應用層自己多埋一個「這筆是 Agent 操作」的 flag。

規格本身也有幾個未補齊的洞。Tool discovery 要走 navigation，Agent 必須先進到某個網站才能發現它有什麼 tool，沒辦法像 MCP server 那樣集中編目；declarative API 還沒寫完；早期用來要求使用者確認的 requestUserInteraction 也已經移出目前草案。確認流程改由瀏覽器或 Agent host 掌控之後，網站不能把 readOnlyHint 當成安全邊界，後端仍得自己擋住越權或不合法的操作。

之後真的要動手做 WebMCP 的話，我腦裡大概會守的幾條原則：readOnlyHint 誠實標，會改狀態的本機模擬路徑自行加確認，server 端當成完全不可信的 public API 做參數驗證，應用層的 log 要能標出 Agent 代打的操作，每頁 tool 數量別塞爆（超過 50 個模型挑錯機率會升高），description 寫具體一點（含格式限制例如 YYYY-MM-DD）。還有一條跟規格無關但很重要：給 Agent 的權限切得比使用者本人小一號，模型被壞 prompt 誘導時才不會闖太大禍。

未來可能的發展

接下來這段是我基於目前規格缺口跟社群討論的推測，看看參考就好。 但如果真的都動起來了，我認為兩三年後的 Web 生態肯定會跟現在很不一樣。

瀏覽器支援確實先動起來了。Chrome 149 與 Edge 已經進入來源試用，ChatGPT 桌面版也能透過 Site tools 呼叫目前頁面的 WebMCP tool。Firefox 跟 Safari 仍只有工程師參與 W3C working group，沒有公開支援時程，Chromium 以外的瀏覽器還是得繼續看。

Declarative API 成熟會大幅降低接入門檻。現在走 imperative 要寫一套 JS，對大量簡單表單（聯絡我們、訂閱電子報、站內搜尋）其實殺雞用牛刀；等 <form toolname="..."> 這種宣告式介面補完，接 Agent 會變成類似加 aria-label 的小動作，電商跟 SaaS 的 onboarding 流程是最可能先動起來的一塊。

跨來源 tool 共享在 v1 被明確排除（只允許同來源註冊 tool），但已經被列為未來規劃。使用場景很清楚：「找台北評分最高的五家餐廳、一次訂全」這種任務需要 Agent 在多個網站之間協調，全走同一個分頁做不到。怎麼在保護使用者資料的前提下允許 cross-origin invocation 是個懸而未決的設計題，類比起來可能會長成 postMessage 加明確使用者確認的混合體。

Tool discoverability 是另一個未解的題，可能對生態影響比規格本身還大。目前 Agent 必須先 navigate 到某個網站才知道它有什麼 tool，沒有類似 MCP server catalog 的集中索引。社群有人在推 agenticweb.md 這類 machine-readable 發現規範，邏輯大概是「跟 robots.txt 放一起、內容是這個 domain 提供哪些 tool 的結構化清單」。這個方向如果定下來，「SEO」這個詞大概會有一半含義跟著改寫。

PWA 加背景執行則是比較遠但蠻有意思的可能性。如果 PWA manifest 可以宣告哪些 tool 是「不用打開 UI 就能執行」的，Agent 在沒有可見分頁的情境下也能呼叫，像「每週五下午幫我檢查購物清單，有特價就加入」這種背景代理任務就做得到了。這算是 WebMCP 從「陪使用者操作當前分頁」擴張到「代理使用者在後台跑任務」的一條可能路徑。

這些方向加起來指的是同一件事：整個 Web 正在從「給人看的頁面」變成「人跟 Agent 共用的互動介面」。短期內會動起來的大概還是內部工具、SaaS、重點電商；但如果 Firefox、Safari 也跟上，跨來源跟 discovery 又有共識，兩年後的 Web 生態會跟現在很不一樣。

想動手玩玩 WebMCP

這次的 Demo 我另外放在 kuro-roasters-webmcp 這個 repo，線上版直接開 https://kuro.tw/kuro-roasters-webmcp/ 就能玩，方便大家感受一下 WebMCP 的使用流程場景。

Demo 場景是假想的咖啡豆選購店，註冊五個 WebMCP tool（搜尋、看商品、加入購物車、看購物車、送出訂單）。你可以用 ChatGPT 桌面版或 Chrome 測試真正的 WebMCP 呼叫，也可以在一般瀏覽器跑情境按鈕與 Gemini function calling 模擬器。後兩條路徑是頁面內建的本機模擬，不代表瀏覽器 Agent 已經透過 WebMCP 呼叫。技術細節（TOOL_DEFS 集中管理、polyfill 行為、agent loop 怎麼串 Gemini）寫在那邊的 README，這篇就不展開多說了。

在 ChatGPT 桌面版測試

寫這篇時，Site tools 要在 ChatGPT 桌面版裡，用 ChatGPT Work 搭配內建瀏覽器測試。一般聊天貼網址、外部 Chrome 與獨立的 Codex App 都不會走這條路。依照 Site tools 官方文件，目前要選 GPT-5.6 Sol 或 Terra，Luna 尚未開放 WebMCP。

1. 將 ChatGPT 桌面版更新到最新版，到 Settings → Browser → Permissions 開啟 Enable site tools。

2. 建立一個 ChatGPT Work 對話，選擇 GPT-5.6 Sol 或 Terra。

3. 按 Cmd + Shift + B 開啟內建瀏覽器，前往 https://kuro.tw/kuro-roasters-webmcp/。

4. 確認頁面上方顯示 document.modelContext 已註冊 5 個 tool。

5. 在同一個 Work 對話測試查詢：

   請使用目前瀏覽器頁面提供的 Site tools，
   搜尋價格 500 元以下的淺焙咖啡豆，列出名稱與價格。
   不要改用一般網頁點擊操作。

6. 再測試會改變頁面狀態的操作：

   請使用目前頁面的 Site tools，
   把搜尋結果中最便宜的咖啡豆加入購物車 2 包，
   然後使用 view_cart 回報購物車內容。不要送出訂單。

成功時，頁面的篩選條件或購物車會跟著變化，ChatGPT 也會顯示工具呼叫與安全審查。帳號若已取得分批推出（rollout）的介面，網址列還會出現 Site tools，可以查看 Available site tools 與 Recently used。

如果完全看不到入口，先確認對話類型、模型、內建瀏覽器與權限設定，也要留意 Enterprise／Edu workspace 目前不支援。這些條件都正確仍沒出現，通常代表帳號還沒取得這批介面。

實際拿 ChatGPT 桌面版測試時，我又踩到一個 Vue / Pinia 特有的坑。TOOL_DEFS 從 Pinia store 回傳後會被 Vue 轉成深層響應式 Proxy，連 inputSchema 跟 annotations 也一起被代理。WebMCP 註冊工具時要跨執行環境複製這些資料，Proxy 沒辦法做結構化複製（structured clone），頁面因此報出 An object could not be cloned.，ChatGPT 則顯示 No WebMCP tools are available in this document.。

修法只有一行：用 Vue 的 markRaw() 包住 TOOL_DEFS，讓整組工具定義保持普通的 JavaScript 物件。schema 本身沒有問題，踩到 structured clone 邊界的是 reactive Proxy。

2026-08 更新後記：從早期預覽到站台工具落地

這篇文章發布四個月後（2026 年 8 月），WebMCP 在規格與生態上的進展比預期快了不少。正文範例已經同步現行寫法，這裡保留幾項重要變化的來龍去脈。

首先是核心 API 的調整。規格把掛載入口從 navigator.modelContext 移到了 document.modelContext（舊寫法在 Chrome 150 標記廢棄），讓每個網頁文件都能擁有獨立的上下文。瀏覽器支援也從早期需要手動開啟實驗旗標，推進到了 Chrome 149 與 Edge 的來源試用（Origin Trial）階段。

同時，早期草案裡的 ModelContextClient 與使用者確認方法暫時移出，改用標準的 AbortSignal 來管理工具註冊與執行的生命週期，就算中途取消註冊，也不會打斷正在跑的任務。工具執行時也可以直接回傳普通的 JavaScript 物件，由瀏覽器自動處理序列化，不需要再特地包一層 MCP 格式的外殼。

更大的轉折在於 AI 代理端。原本我推測 Gemini in Chrome 可能是第一個內建入口，結果 OpenAI 在 8 月底搶先在 ChatGPT 桌面版內建瀏覽器推出「站台工具（Site tools）」，讓 ChatGPT Work 與 Codex 能直接抓取並呼叫當前網頁提供的 WebMCP 工具，連同使用者的登入狀態與頁面資料一併共用。

OpenAI 也找了 Chrome、Shopify、Cloudflare、Vercel 等平台一起辦挑戰賽，試圖拉動開發者進場。

這讓 WebMCP 的瓶頸徹底換了方向。過去大家最大的猶豫是「網站寫了也沒有 AI 來用」的雞生蛋困境；現在主流的 AI 代理已經先跑在前頭，真正的缺口反而是實際提供 WebMCP 工具的網站太少了。

如果你手邊有操作流程長、狀態複雜的純前端應用或管理介面，現在正是利用來源試用或 ChatGPT 桌面版嘗試串接的好時機。不過要是牽涉到重要資料的修改，後端的權限檢查與參數驗證依然要做好，別把所有安全防線都賭在 AI 端的事前審查上。

參考資料

• WebMCP 規格草稿 (W3C WebML CG)
• WebMCP GitHub Repo
• Chrome 官方 blog：WebMCP Origin Trial
• Chrome 官方 blog：WebMCP is available for early preview
• Chrome 官方 blog：When to use WebMCP and MCP
• OpenAI 官方文件：Site tools
• OpenAI 官方文件：ChatGPT 內建瀏覽器
• Scalekit：WebMCP explained
• Arcade 訪談 Alex Nahas
• MCP-B Wiki：Known Security Issues With WebMCP
• @mcp-b/global npm 頁面
• Gemini function calling 官方文件
• awesome-webmcp