Day 13｜第一次按下 Inspector 的 Send，先被 Gemini 429 擋在門外
2026 iThome 鐵人賽 WebMCP Day 13：安安～我是ChiYu～ 前天讓 HTML 表單透過 Declarative API 描述自己，昨天再用 Imperative API 管理動態 Tool 的註冊與解除。Chrome 已經看得到網站能力，今天總算輪到 Inspector 下方那顆 S…
快速導覽 查看本文目錄
本文同步自 2026 iThome 鐵人賽原文 。完整系列可見 iThome 系列頁 。
安安～我是ChiYu～
前天讓 HTML 表單透過 Declarative API 描述自己，昨天再用 Imperative API 管理動態 Tool
的註冊與解除。Chrome 已經看得到網站能力，今天總算輪到 Inspector 下方那顆 Send。
我沒有先從下拉選單指定 Tool，只輸入一句自然語言，想看 Agent 會不會自己選中
search_events。
結果第一個回來的不是活動，也不是 schema error，而是 Gemini API 的 429：
429 RESOURCE_EXHAUSTED
Your prepayment credits are depleted.
這個錯誤甚至還沒走到 WebMCP Tool。網站沒有收到呼叫，search_events 也根本還沒上場。
如果我看到紅字就回頭改 Tool description，等於模型額度用完，工程師卻在旁邊重寫網站契約。
今天真正要拆開的，是 WebMCP、Inspector 與測試模型各自負責哪一段；額度恢復後，再重新按
一次 Send，確認自然語言是否真的走進 Tool。
今天不切新的程式 Tag，改測公開站與 Inspector
昨天的 v3-day-12 用來重播本機 Tool 生命週期。今天程式沒有建立新的里程碑，測試對象
改成完成版活動搜尋頁與 Inspector：
公開網站
→ Chrome 發現目前頁面的 Tool
→ Inspector 把自然語言交給測試模型
→ 模型決定是否呼叫 Tool
→ 網站執行並回傳結果
這條路徑裡有三個角色：
| 角色 | 它負責什麼 | 它不負責什麼 |
|---|---|---|
| WebMCP | 網站如何向瀏覽器公開 Tool | 不提供模型額度，也不替 Agent 選 Tool |
| Inspector | 顯示 catalog、手動執行 Tool、送出自然語言測試 | 不會自動替網站產生能力契約 |
| Gemini API | 讓 Inspector 裡的測試 Agent 理解 Prompt、選擇 Tool | 不是 AgentReady Events 的後端服務 |
因此，沒有 Gemini API Key，網站仍然可以實作 WebMCP；只有要在 Inspector 按 Send 測試
自然語言選擇時，才需要模型憑證。
429 發生在 Tool selection 以前
這次的 RESOURCE_EXHAUSTED 表示模型請求先被額度擋下。trace 裡還沒有
AI calling tool，所以它不能算成 search_events 的失敗案例。
我替 Inspector 建立獨立的測試 Project 與 API Key，不共用正式服務憑證，也不把 Key 放進 網站環境變數、文章、截圖或 Git。接著到 Billing 檢查預付餘額，並把自動加值關閉或限制在 自己能接受的範圍。
圖 1：Billing Account ID 已遮蔽；這裡只核對測試 Project、預付餘額與 Auto-reload 狀態。
Billing 介面、模型價格與限制方式都可能改版，所以我不把當時畫面上的金額寫成通用建議。 這篇只保留三個原則：測試專案獨立、金額保持低額、最壞成本先設邊界。畫面上的 Auto-reload 限制與 Project spend cap 也不是同一件事，設定時要分開確認。
原始 Inspector 對話後來曾被 reset，無法還原當時完整 Prompt 與 Tool 狀態；AI Studio Usage
仍留下一筆 429 TooManyRequests：
圖 2：這筆遙測只能證明模型 API 發生過 429，不能冒充完整的 WebMCP Agent trace。
這個證據限制有點可惜，但至少責任位置已經確認：當時失敗的是模型請求，不是網站 Tool。
額度恢復後，重新用 Send 讓模型自己選
環境恢復後，我回到活動搜尋頁，確認 Inspector catalog 看得到 search_events，按一次 Reset，
再輸入：
幫我找台北、免費，而且適合入門者的活動。
這次沒有從 Tool 下拉選單代選，也沒有先手動填 Input Arguments。成功紀錄必須連續看見：
User prompt
→ AI calling tool "search_events"
→ Tool input
→ Tool result
→ AI result
圖 3：Agent 自行選擇 search_events，帶入台北、免費與入門條件，最後回答也能對回 Tool result。
這份 trace 回答了四件事：
- 模型從自然語言選中了
search_events。 - Tool input 保留
taipei、free與beginner。 - 網站回傳固定活動資料。
- 最後回答以 Tool result 為依據，沒有只靠模型自己猜。
到這裡，這一題可以列為真實 Agent invocation。手動 Execute Tool 做不到這項證明，因為
選擇 Tool 的人仍然是工程師。
一次成功只替這一次呼叫作證
這張成功 trace 的範圍必須維持很窄：
| 已經看到的證據 | 還不能一起宣布的事情 |
|---|---|
| 固定頁面上一次自然語言搜尋成功 | 所有搜尋說法都能成功 |
Agent 選中 search_events | 其餘四支 Tool 都會選對 |
| 三個條件映射正確 | 多步驟順序、寫入與失敗復原都已完成 |
| Tool result 與最後回答一致 | 換模型、瀏覽器或乾淨環境仍會得到相同結果 |
另外還有三個很容易混淆的判讀：
- 429 出現在 Tool selection 以前，不能記成網站 Tool bug。
Execute Tool是 direct control，不能寫成 Agent 自主選擇。- 模型猜出
get_page_content或list_events，不代表網站真的註冊過那些名稱。
除錯時先核對目前 catalog，再讀完整 trace。模型敲了一扇不存在的門，不代表我們要立刻替它 加蓋第六支 Tool。
今天原本只是想按一次 Send，最後卻先補了一堂環境分層。額度問題處理完後，
search_events 終於留下第一份完整自然語言呼叫紀錄。
成功畫面一出現，最容易做的事情就是繼續加功能。明天我先不往外長，而是把五個正式 Tool 名稱、三條 Journey、route 契約與人類停點寫成可驗收的範圍。後面每一次成功或失敗，都必須 回到同一份契約說話。
留言討論
用 GitHub 帳號留言，留言會同步到這個 Blog 的 GitHub Discussions。