安安～我是ChiYu～

昨天才把五支 Tool 的名單定下來，我原本以為今天打開 Inspector，它們就會排隊向我報到。

結果側邊面板一片空白。

沒有名稱、沒有 schema，也沒有任何「恭喜你完成 WebMCP」的綠色勾勾。紙上的 catalog
寫得再漂亮，Chrome 沒看到就是沒看到，這點倒是非常公平。

這個空白也讓今天的問題變得很具體：到底是 Inspector 沒裝好、Chrome flag 沒開、側邊面板
綁錯分頁，還是網站根本沒有在目前 route 註冊 Tool？

所以今天先不急著按 Execute Tool。我要從這張空白面板開始，把瀏覽器環境、目前分頁與網站
註冊狀態一層一層排好，直到 Chrome 真的看見 Tool。

Inspector 是觀察與測試面板，不是 Tool 產生器

本系列使用的擴充功能完整名稱是：

WebMCP - Model Context Tool Inspector

Inspector 會讀取目前分頁公開的 WebMCP Tool，顯示名稱、description、input schema 與安全
提示；開發者也可以手動執行 Tool，或輸入自然語言觀察測試模型如何選擇能力。

但它不會替網站自動產生 Tool。網站仍要自己完成註冊、輸入契約與執行邏輯；Inspector 只是把
瀏覽器實際看到的結果攤開，讓我判斷問題出在環境、觀察對象，還是網站程式。

可以先把分工記成這樣：

網站：定義並註冊 Tool
Chrome：提供 WebMCP 測試能力
Inspector：顯示、手動測試與保存 trace

安裝前先核對完整名稱與前置條件

我從 Chrome Web Store 的 Inspector 頁面
核對完整名稱，不只搜尋 WebMCP。商店裡若出現名稱相近的工具，裝錯一支再回頭查 catalog，
除錯會從第一步就走錯棚。

圖 1：先確認完整名稱、商店頁與測試前置條件，再安裝本系列使用的 Inspector。

撰文當下，商店頁列出的前置條件是 Chrome 150.0.7861.0 以上，並要求啟用
WebMCP for testing。版本與介面都可能更新，因此重播時應以測試當天的商店頁和 Chrome
文件為準，不要把這個版號當成永久常數。

安裝完成後，我開啟：

chrome://extensions/

搜尋 webmcp，確認 Inspector 卡片右下角的開關已啟用。

圖 2：Inspector 已安裝並啟用；擴充功能太多時先用搜尋縮小範圍。

商店頁也提醒，這支擴充功能不是 production 等級的安全邊界，不適合在瀏覽不受信任網站時
使用。我另外開一個測試用 Chrome profile，不把日常登入狀態、瀏覽資料與實驗環境全倒進
同一鍋。

Flag 設成 Enabled 之後，還要重新啟動 Chrome

接著進入：

chrome://flags/#enable-webmcp-testing

將 WebMCP for testing 設為 Enabled，再按 Chrome 提示的 Relaunch。只改選項卻沒有重新
啟動，Inspector 仍可能直接回：

Error: You must run Chrome with the "WebMCP for testing" flag enabled.

圖 3：設為 Enabled 之後仍要 Relaunch，否則新的瀏覽器能力不會套用。

Chrome 的 WebMCP 說明
目前也把這組 flag 定位在 local development。它不是正式網站要求所有使用者自行開啟的設定，
更不能拿來推論所有瀏覽器都已經支援 WebMCP。

Inspector 只看目前分頁，空白有時反而是正確答案

環境準備好後，我先停在一個沒有註冊 WebMCP Tool 的頁面。此時 WebMCP Tools 區域保持
空白：

圖 4：目前分頁沒有公開 Tool，空 catalog 就是正確結果。

側邊面板顯示的是目前分頁，不會因為另一個 tab 開著 AgentReady Events，就隔空把那裡的
Tool 搬過來。這也是我一開始差點誤判的地方：空白不一定是 bug，先確認自己到底站在哪一頁。

接著切回活動詳情頁，等 route 載入完成，再查看 Inspector。這次面板列出了名稱、description、
input schema，以及 read-only、untrusted content 等提示：

圖 5：活動詳情 route 只公開與目前活動有關的 Tool；產品共有五個正式名稱，不代表每頁都要全部出現。

昨天定下來的是整個產品允許存在的五個 Tool 名稱，不是每個 route 的固定清單。詳情頁只看見
兩支相關能力，反而證明 active catalog 有跟著頁面情境收斂。

面板仍然空白時，先別急著改 schema

我會按照下面順序排查：

1. WebMCP for testing 是否為 Enabled，Chrome 是否已 Relaunch。
2. Inspector 是否啟用，側邊面板目前綁定的是否為目標分頁。
3. 頁面是否載入完成，目前 route 與狀態是否本來就應該註冊 Tool。
4. 前三項都成立後，才回到網站的 registry、form attribute 或註冊錯誤。

第一項是瀏覽器環境，第二項是觀察對象，第三、四項才輪到網站程式。若 Inspector 已經明講
flag 沒開，卻先衝去修改 Tool description，最後通常只會得到兩個問題：原本的環境問題，
以及剛剛親手加進去的新 bug。

Execute Tool 與 Send 驗證的是兩件事

Inspector 下方有兩條操作路徑：

• Execute Tool：工程師先指定 Tool，再輸入參數，適合檢查 schema、handler 與 runtime result。
• Send：只輸入自然語言，由測試模型判斷要不要用 Tool、選哪一支，以及參數怎麼填。

手動執行很適合除錯，但選擇 Tool 的人仍然是我。它不能證明 Agent 看懂使用者的話，也不能
證明模型會自行選對。

大後天第一次按下 Send 時，我才會把 Gemini 測試環境、自然語言選擇與完整 trace 放進
驗收。今天先把證據停在瀏覽器 discovery：真實 Chrome 已經看見目前 route 公開的 Tool。

今天只證明 Chrome 看得見，還沒證明 Agent 會用

按照前面定義的證據地圖，今天到的是 E3：Tool 不只存在於原始碼或測試替身，真實 Chrome
也能在目標頁面發現它。

但 Inspector 列出 Tool，不代表執行一定成功；手動執行成功，也不代表模型能從自然語言選中
它。這三件事畫面很接近，證據責任卻不能互相代打。

面板終於不再空白，裡面也出現名稱、description 與 input schema。明天就從這些欄位往回追，
做一張最小的 Declarative form，看看 HTML 怎麼把自己整理成 Tool 契約。