Day 10｜什麼是 WebMCP Inspector？從安裝、設定到看見網站 Tool

安安～我是ChiYu～

昨天才把五支 Tool 的名單定下來，今天要把紙上的 catalog 搬進真實 Chrome。不過在打開
面板以前，得先回答一個最基本的問題：WebMCP Inspector 到底是什麼？

WebMCP Inspector 是網站 Tool 的觀察與測試面板

WebMCP Inspector 是一支 Chrome 擴充功能，完整名稱為 WebMCP - Model Context Tool Inspector。它會讀取目前分頁公開的 WebMCP Tool，列出名稱、description、input schema
與安全提示，也能讓開發者手動執行 Tool，或輸入自然語言觀察模型如何選擇 Tool。

它比較像 WebMCP 的開發者工具，不是替網站自動產生 Tool 的魔法按鈕。網站仍要自己完成
Tool 註冊、輸入契約與執行邏輯；Inspector 負責把瀏覽器實際看到的結果攤開來，讓我知道
問題發生在環境、目前分頁，還是網站程式。

角色釐清後，我原本以為只要打開 Inspector，五支 Tool 就會排隊向我報到。

結果面板一片空白。

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

這個空白也讓今天的問題變得很明確。原始碼裡有 Tool、測試替身收得到 Tool，以及真實
瀏覽器能發現 Tool，是三件不同的事。我要先把 Inspector、Chrome flag、目前分頁與
route-aware 註冊逐一排好，才知道問題到底卡在哪一層。

安裝 Inspector 前，先核對完整名稱

Chrome Web Store 裡可能出現名稱相近的工具，因此我先核對這篇使用的完整名稱：

WebMCP - Model Context Tool Inspector

我先從 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，不把日常登入狀態、瀏覽資料與實驗環境
全倒進同一鍋。

啟用 WebMCP for testing 後，必須重新啟動 Chrome

擴充功能裝好，還要打開 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：將 testing flag 設為 Enabled 後，還要 Relaunch 才會套用。

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

Inspector 顯示目前分頁的 catalog，空白可能完全正常

環境準備好後，我從 Chrome 工具列開啟 Inspector 側邊面板。圖示若被收進拼圖選單，可以
先把它釘選起來；接下來會切換好幾次分頁，每次都回選單裡撈它，耐心很快就會先被 dispose。

我先停在一個沒有註冊 WebMCP Tool 的頁面。這時 WebMCP Tools 區域保持空白：

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

這也是我一開始差點誤判的地方。側邊面板顯示的是目前分頁狀態，不會因為另一個 tab 剛好
開著 AgentReady Events，就隔空把那裡的 Tool 搬過來。

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

圖 5：活動詳情 route 公開與目前活動有關的 Tool；五支正式 Tool 不會在每個頁面同時出現。

昨天定下來的是整個產品的五支 Tool，不是要求每個 route 永久展示五支。詳情頁看見兩支
相關 Tool，比一口氣看到完整 catalog 更符合我們做的 route-aware 邊界。

面板仍然空白時，依環境、分頁與註冊狀態逐層檢查

如果目標頁仍然沒有 Tool，我會依照下面順序排查：

1. WebMCP for testing 是否為 Enabled，Chrome 是否已 Relaunch。
2. Inspector 擴充功能是否啟用，側邊面板目前綁定的是否為目標分頁。
3. 頁面是否載入完成，目前 route 與狀態是否本來就應該註冊 Tool。

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

Execute Tool 與 Send 驗證的是兩件不同的事

Inspector 下方有兩條操作路徑：

• Execute Tool：由工程師指定 Tool，再輸入參數執行，適合檢查 schema 與 runtime result。
• Send：輸入自然語言，由 Inspector 使用的模型判斷是否要選 Tool、選哪一支以及帶什麼參數。

手動 Execute Tool 很適合除錯，但選擇 Tool 的人仍然是我。它不能證明 Agent 看懂使用者的
話，也不能證明模型會自行選對。大後天第一次按下 Send 時，才會把 Gemini 測試環境、
自然語言選擇與完整 trace 一起放進驗收。

今天只證明 Chrome 能發現目前頁面的 Tool

按照前幾天定下來的證據地圖，今天的結果到 E3：真實 Chrome 已在目標 route 看見網站公開
的 Tool。這比原始碼與測試替身多走了一層，但還沒有到 Agent discovery／invocation。

Inspector 列出 Tool，不代表執行一定成功；手動執行成功，也不代表模型能從自然語言選中
它。這些界線如果混在一起，一張 catalog 畫面很容易被寫成「Agent 已經會用了」，文章看起來
進度飛快，證據卻留在原地。

面板終於不再空白，裡面卻多出名稱、description 與 input schema。下一個問題也跟著冒出來：
這些內容到底從哪裡產生？明天我會做一張最小的 Declarative form，讓 HTML 自己公開 Tool，
再回到 Inspector 看每個欄位的來源。