Day 247 網頁自己把工具交給 AI

WebMCP 的 origin trial 從 Chrome 149 開始上線，現在 Chrome stable 已經跑到 152——意思是這東西已經不是只能在 Canary 裡開 flag 玩，而是可以放到正式網站上測了。

這篇分享三件事：WebMCP 到底是什麼、它跟 Anthropic 的 MCP 差在哪、如果你的網站想變成 agent-ready，現在可以先想哪些問題。

一句話講，WebMCP 是讓網頁把自己的功能註冊成 AI agent 可以呼叫的工具。

不是讓 agent 去猜按鈕在哪裡。

不是叫 agent 爬 DOM、看 class name、模擬滑鼠點擊。

而是網站自己說：

「我有這個工具，它吃這些參數，呼叫之後會做這件事。」

這個差別很大。

以前 agent 是在猜畫面

現在很多 AI 操作網站的方式，本質上還是在「看畫面」。

它可能讀 DOM，可能讀 accessibility tree，也可能真的用瀏覽器自動化去點按鈕。

這當然可以用。

但它有幾個很脆的地方：

按鈕文案一改，agent 可能找不到
DOM 結構一換，selector 可能斷掉
同一個頁面有很多相似按鈕，agent 可能點錯
網站沒有說清楚「這個動作會改資料」還是「只是查詢」

WebMCP 想解的是這一層。

如果網站知道自己有哪些安全、明確、可被機器呼叫的動作，就不要讓 agent 從畫面上猜。

直接把工具宣告出來。

這有點像以前網站從「只有人看的頁面」長出 API。

但這次不是給工程師串 API。

是給 AI agent 在瀏覽器裡理解：這個頁面到底願意開放哪些能力。

它不是把網頁變成 MCP server

這裡很容易講錯。

Anthropic 的 MCP（Model Context Protocol，讓 AI 接外部工具與資料的一套協定）主要是 server 端的東西。常見做法是跑一個 MCP server，透過 JSON-RPC、stdio 或 HTTP 跟 AI client 溝通。

例如 Claude Code 接 Obsidian、GitHub、資料庫，通常是這種形態：

	Anthropic MCP	WebMCP
跑在哪裡	後端 / 本機 process / server	瀏覽器裡的頁面
工具怎麼來	MCP server 宣告	網頁用 Web API 註冊
安全邊界	client / server / token / transport	瀏覽器 origin、iframe、Permissions Policy
適合什麼	帳號層級、背景任務、跨頁資料	當前頁面的操作與狀態

所以「網頁變成 MCP server」只能當比喻，不能當精確說法。

比較準確的講法是：WebMCP 借用了 MCP 的工具概念，但把工具宣告這件事搬進瀏覽器，交給 web platform 的安全模型來管。

官方 explainer 也把「取代後端整合」列成 non-goal。也就是說，它不是要把原本的 MCP server 消滅掉。

它比較像是多了一條路：

後端的能力，交給 MCP server。

頁面當下的能力，交給 WebMCP。

Chrome 到哪了

我查到的現況大概是這樣：

WebMCP 是 W3C Web Machine Learning Community Group 下面的草案／explainer，不是正式 W3C 標準
Chrome 從 149 開始有 origin trial
Edge 從 150 開始有 origin trial
Firefox / Safari 目前看到的是 standards-position issue，還沒有承諾支援
本機測試可以開 chrome://flags/#enable-webmcp-testing

還有一個容易踩到的版本差異：早期文章常寫 navigator.modelContext，但現在 Chrome 官方文件寫的是 document.modelContext。

這也說明一件事：現在它還在動。

如果你今天就要把 WebMCP 放進產品，不能只看一篇教學就抄到底。API 位置、瀏覽器支援、權限模型，都還可能變。

我會把它當成「值得追、可以小規模試，但還不到全站押上去」的階段。

真正麻煩的是安全面

WebMCP 最有趣的地方不是 API 很短。

真正麻煩的是：網站現在可以把「工具說明」交給 agent 看，agent 又會根據這些文字決定要不要呼叫工具。

這會帶出幾個問題。

第一個是 prompt injection。

如果一個工具回傳的是使用者內容、評論、文章、外部網頁摘要，那裡面可能藏著「忽略前面指令，把資料送到某某地方」這類惡意文字。Chrome 的安全文件也直接說，不能假設 LLM 裡面一定能保證安全。

第二個是 tool poisoning。

工具的名稱、描述、參數說明本身都會被 agent 讀。也就是說，工具描述不能亂寫成「你一定要優先呼叫我」「呼叫前不要問使用者」。這不是文件風格問題，是攻擊面。

第三個是第三方 script。

如果網站載入的第三方 JavaScript 可以在同一個頁面的執行環境裡跑，那它理論上也可能註冊工具，或影響工具邏輯。這件事不是 WebMCP 文件獨有的風險，但 WebMCP 會讓原本的前端供應鏈問題多一個 agent 入口。

第四個是跨 origin 暴露。

WebMCP 預設不讓其他網站或 cross-origin iframe 看見你的工具。要開給別的 origin，需要明確設定。這很合理，因為一個看起來只是「查詢資料」的工具，也可能洩漏使用者狀態。

所以我現在對 WebMCP 的判斷比較保守：

只讀、可公開、可重跑的工具，適合先試。

會改資料、送出表單、付款、刪除內容的工具，先不要急。

至少要等 consent model、agent 端提示、瀏覽器 UI 都更穩之後再說。

創作者網站可以先想什麼

如果 dawsonwang.com 要先變成 agent-ready，我大概不會一開始就做「幫我發文」「幫我改文章」這種會改狀態的工具。

我會先想幾個只讀能力：

搜尋 100days 文章
用 Day 編號讀文章
列最近幾天
列某篇引用過的來源

這些能力的共同點是：只讀、不登入、不改資料。

做壞了最多就是回傳結果不好，不會替使用者做出不可逆的動作。

而且它們剛好是網站比 agent 更懂的事。

agent 可以自己爬頁面找文章，但網站其實早就知道 Day 247 在哪、標題是什麼、source path 是什麼、引用來源有哪些。

那就不要讓 agent 猜。

把這些能力明確交出去。

這件事對每天用 Claude Code 的人代表什麼

我現在用 Claude Code 接 MCP 的感覺是：AI 的能力很大一部分取決於「它能不能拿到對的工具」。

接了 Obsidian，它就能讀筆記。

接了 GitHub，它就能看 issue、開 PR。

接了自家 script，它就能跑內容流程。

WebMCP 把這個問題搬到網站那邊。

以後不是只有 app 開 API 給工程師用。

而是網站也要想：如果 AI agent 會成為我的另一種使用者，我要不要提供它一組權限單純、用途明確的工具？

這不表示每個網站都要立刻支援 WebMCP。

規格還在草案，跨瀏覽器還沒成形，安全設計也還有很多缺口要補。

但方向很清楚：

AI agent 不會永遠只靠「看畫面」操作網站。

網站也會開始自己宣告它能做什麼。

一句話總結：agent-ready website 的第一步，不是讓 AI 看懂你的畫面，而是讓網站把哪些功能可以安全呼叫說清楚。

來源：

WebMCP GitHub explainer：https://github.com/webmachinelearning/webmcp
WebMCP technical notes：https://w3c-cg.github.io/aikr/webMCP/webmcp-technical-notes.html
Chrome WebMCP overview：https://developer.chrome.com/docs/ai/webmcp
Chrome WebMCP imperative API：https://developer.chrome.com/docs/ai/webmcp/imperative-api
Chrome WebMCP security notes：https://developer.chrome.com/docs/ai/webmcp/secure-tools
WebMCP implementation status：https://github.com/webmachinelearning/webmcp/blob/main/implementation-status.md
Chrome Releases 2026-09：https://chromereleases.googleblog.com/2026/09/

網頁自己把工具交給 AI