Day 09｜網站該公開哪些 WebMCP Tool？從操作盤點到五支正式能力

本文同步自 2026 iThome 鐵人賽原文 。完整系列可見 iThome 系列頁 。

安安～我是ChiYu～

昨天才把 click_blue_search_button 請出 catalog，我差點又用同一套方法，把剩下的按鈕 全部包成 Tool。

我先把網站上看得到的操作列出來：展開篩選器、切換頁籤、查看詳情、收藏、關閉 dialog、 送出報名、準備取消、確認取消。清單愈寫愈長，看起來很有進度，實際上比較像是在替 DOM 做戶口名簿。

昨天留下的 search_events 能成立，是因為「搜尋活動」本身就是使用者會提出的任務。至於 「展開篩選器」和「按下藍色按鈕」，只是目前這版 UI 完成任務的方式。把兩者混在一起， Agent 就得先學會網站的操作零件，再猜這些零件怎麼拼成使用者真正想做的事。

活動網站剛好很適合拿來做這次取捨。同一個產品裡有唯讀查詢、可以復原的收藏，也有會占用 名額的報名與影響既有權益的取消。它不需要硬塞付款、後台或第六支 Tool，就已經能讓我們 看見不同程度的風險。

Chrome 的 WebMCP 最佳實務 建議先規劃 Tool strategy，避免功能重疊，並在能力不再可用時解除註冊。每支 Tool 都會占用 Agent 的 context；規格沒有替 catalog 設定固定上限，不代表我們可以把所有按鈕都搬進去。

我把候選操作放進同一張矩陣，先看完整任務，再看它是否值得成為 Tool：

圖 1：保留的是使用者想完成的任務；淘汰的是目前 UI 恰好採用的操作步驟。

用五個問題判斷候選操作是否值得成為 Tool

使用者會說「幫我找台北的入門活動」，不會說「打開左側篩選器、選第三個下拉選單，再按 藍色按鈕」。後面那串只是這一版畫面的操作說明。

因此每個候選能力，我都先問下面五個問題：

拿「關閉 dialog」和「收藏活動」相比就很清楚。前者只在特定畫面狀態下有意義，dialog 換個 版型，這支 Tool 可能立刻失業；後者有明確結果，也能讓使用者 Undo。兩顆都是按鈕，但只有 其中一顆承接了完整任務。

五支 Tool 分別承接查詢、收藏、報名與取消

篩選後，我把產品層的 catalog 收斂成五支 Tool：

這裡的 R0～R3 是本系列用來討論風險與人類停點的標籤，不是 WebMCP 官方認證等級。R0 是 唯讀操作，R1 會改變可復原狀態；到了 R2、R3，操作開始碰到名額或既有權益，Agent 能做的 事情就必須停在「準備完成」。

五支 Tool 最後組成三條 Journey：

搜尋 → 詳情 → 收藏
準備報名 → 人類送出
準備取消 → 人類確認

你會發現清單裡沒有 submit_registration，也沒有 cancel_registration。Agent 可以整理 資料、打開表單、說明影響，但最後一次 POST 或取消 mutation 必須留給人類。我刻意把這個 控制點留在人類手上。

這裡列的是整個產品允許出現的五個名稱，不代表每個頁面都會看見相同 Tool，也不代表 同名 Tool 在不同 route 一定使用同一份 input schema。真正公開給 Agent 的 active catalog， 仍要回到目前頁面與狀態判斷。

展開篩選器、切換頁籤與關閉 dialog 繼續留在人類 UI

有些操作對人類很好用，卻沒有必要升級成 Tool：

「不做 Tool」不等於刪掉功能。人類 UI 繼續保留適合滑鼠、鍵盤與視覺判斷的互動；Agent 拿到的則是較穩定、能被驗證的任務介面。兩邊使用同一套產品能力，入口不必長得一模一樣。

把搜尋拆成五支 UI Tool，只會增加狀態與稽核噪音

如果我真的照按鈕做 catalog，一次搜尋可能會變成：

open_filter_panel
select_free_price
select_beginner_level
click_search_button
open_first_card

原本一次 search_events 能完成的工作，現在要連續呼叫五支 Tool。Agent 還得記住面板有沒有 打開、欄位是否已選取、第一張卡是不是剛才那一場。UI 只要換個排序，最後一步就可能打開 不同活動。

稽核紀錄也會跟著變模糊。一筆 search_events 很容易看懂使用者要求了什麼；五筆 UI 操作 只告訴我們 Agent 動過哪些零件，卻不一定說得清楚它想完成哪個任務。這種設計只是替 Browser Automation 的步驟換上 Tool 名稱，能力邊界並沒有因此變好。

產品只有五個 Tool 名稱，但每個 route 的 active catalog 不一樣

最終實作不是讓五支 Tool 每頁常駐，也不是搜尋完成後才臨時新增下一支 Tool。它採用的是 「產品名稱固定、目前 route 決定實際契約」：

/events 上的三支 Tool 會一起存在，是為了讓 Agent 能在同一頁完成 search_events → get_event_details → save_event。但一起存在不代表可以跳步： save_event 仍會檢查目前畫面顯示的活動是否和輸入 ID 相同。Agent 若沒有先取得並顯示詳情， 收藏就應該被拒絕。

同名的 get_event_details 也有兩種明確契約。列表頁需要 event_id；詳情頁則由 route 綁定目前活動，只接受空物件。這比在同一份 schema 裡把 event_id 寫成選填，再期待模型 判斷何時該省略更容易測，也少了一個傳入 null 的模糊空間。

專案再用 APPROVED_TOOL_NAMES 凍結產品層的五個正式名稱，測試也明確拒絕加入第六支 finalization Tool。包含 catalog 與相關契約的聚焦測試共 11 項通過，但這份結果仍是 E2 harness：它證明程式與契約一致，還不能替真實 Chrome 宣布發現成功。

今天，我沒有替網站增加任何新功能，反而把候選清單刪到只剩五支。刪完之後，每支 Tool 都能回答「使用者到底想完成什麼」，不同 route 的 input 與狀態前提也有了清楚位置。

紙上的 catalog 已經定案，下一個問題很直接：Chrome 看得到嗎？明天我會安裝 WebMCP Inspector、啟用 testing flag，先從一片空白的側邊面板開始查起。