我第一次看到 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 還在很早的階段，我不會把它說成下一個所有網站必裝的標準。不過它提出的問題很值得注意：當網站使用者不再只有人，前端要怎麼提供一個既清楚又安全的入口？
一個簡單情境
假設旅遊網站有日期選擇器、房型卡片和好幾層 modal。畫面操作型 agent 得先理解 DOM，再模擬點擊。若網站提供 searchRooms 工具，參數明確寫著入住日、退房日和人數，agent 可以直接送出結構化資料，網站也能回傳固定格式的房型。
但到了 bookRoom 就不能照樣全自動。搜尋是低風險讀取，訂房會產生費用，應該讓使用者看到最後金額並再次確認。WebMCP 真正需要設計的，不只工具 schema，還包括哪些步驟可以代勞、哪些一定要把控制權交回人。
如果真的要替網站加工具，我會先從唯讀、可重試的操作開始，並且替每次呼叫留下 audit log。等團隊看得懂 agent 會怎麼選參數，再碰會寫入資料的功能。把現有 API 全部原樣曝光通常不是捷徑，因為給內部程式用的參數，不一定適合讓模型自行判斷。
錯誤訊息也會變成介面的一部分。只回傳 400 Bad Request，人和 agent 都不知道怎麼修；指出日期範圍、允許值和是否可重試，才能讓下一步安全而可預期。