文章目錄
我第一次看到 agent 在網站上慢慢找按鈕、點錯 modal，覺得有點好笑，又有點熟悉——它很像第一次使用產品、但完全不敢問問題的人。WebMCP 讓我感興趣的地方，不是又多一個 AI 名詞，而是前端可能真的要開始服務一種「看得到 DOM，卻不知道送出代表什麼」的新使用者。
現在的 AI agent 要操作網站，常常得像人一樣找按鈕、讀文字再點擊。只要畫面改版或按鈕名稱改掉，自動操作就可能失敗。
WebMCP 的想法，是讓網站主動告訴 agent 自己提供哪些操作，例如「搜尋商品」、「加入購物車」或「查詢訂單」。Agent 不必完全靠猜畫面，就能取得比較清楚的工具名稱和參數。
這不代表網站可以跳過 API，也不代表 agent 能自由操作一切。登入、授權、付款確認和使用者同意仍然很重要。它比較像是在原本給人看的 UI 之外，再提供一份給 agent 理解的操作說明。
和讓 AI 直接點畫面有什麼差別？#
瀏覽器自動化通常看到的是按鈕文字和 DOM。它可以很通用，但「送出」到底是送出留言、建立訂單還是刪除帳號，要靠上下文猜。WebMCP 則讓網站用明確的工具名稱、參數和回傳結果描述操作，概念上比較靠近 API。
但 API 是給程式整合，WebMCP 更在意 agent 如何發現和使用能力。網站可以保留原本的人類介面，同時告訴 agent 哪些操作是正式支援的，不必讓它在頁面上到處找 selector。
前端多了一個需要設計的介面#
以前前端常同時照顧視覺和無障礙樹，未來可能還要想 agent 看到的工具描述。名稱太模糊，AI 會選錯；參數沒有清楚限制，也可能送出危險操作。像付款、刪除資料這種行為，更不能因為 agent 呼叫工具就省略最後確認。
WebMCP 還在很早的階段，我不會把它說成下一個所有網站必裝的標準。不過它提出的問題很值得注意：當網站使用者不再只有人，前端要怎麼提供一個既清楚又安全的入口？
前端實際上可以怎麼做？#
WebMCP 是讓網頁提供功能給 agent 呼叫的瀏覽器 API。以搜尋空房為例，前端原本就有搜尋按鈕和查詢函式，現在可以把這個函式接到 WebMCP，登記成一個工具。
登記時，除了取名 searchRooms，還要寫上「依日期和人數查詢空房」的用途說明，以及必填參數和格式。Agent 靠這些資訊判斷怎麼使用，不是只看函式名稱猜功能。
當使用者請 agent 查空房，它就填入日期和人數、呼叫工具，再由網站執行原本的查詢並回傳結果。前端主要是替現有功能多開一個入口；仍需支援 WebMCP 的瀏覽器與 agent，原本的按鈕也繼續保留。