Day 01｜網站真的會被 Agent 使用嗎？我先丟了一句自然語言

「幫我找台北、免費，而且適合入門者的活動。」

我把這句話送進 WebMCP Inspector 時，沒有告訴它 Tool 名稱，也沒有先替它填好
參數。幾秒後，trace 裡出現了 search_events，地點、費用和程度也各自落在正確欄位。

最後答案看起來很普通，就是一場「WebMCP 入門工作坊」。真正讓我停下來看的，是回答
前面的過程。

圖 1：左側是活動搜尋頁，右側 Inspector 保存了 User prompt、Tool call、input、Tool result 與 AI result。

這正是我想用 30 天拆開來看的問題：網站已經有按鈕、表單與 API，為什麼還需要另一份
給 Agent 使用的介面？

WebMCP 是什麼？

WebMCP 是一套正在發展中的 Web API，
讓網站把自己的功能公開成 Agent 可以呼叫的 Tool。網站不只留下按鈕文字和 DOM 讓
Agent 猜，而是直接提供任務名稱、自然語言說明、結構化輸入，以及執行後的結果。

以這次搜尋為例，人類看到「地點」「費用」「程度」和「搜尋活動」按鈕，就知道怎麼
操作；Agent 看到的則是比較明確的契約：

Tool name    search_events
用途         依條件搜尋公開活動
input        location、price、level、query
result       活動 ID、名稱、時間、地點與詳情網址

當使用者輸入自然語言，瀏覽器裡的 Agent 可以查看目前分頁提供的 Tool，選擇適合的
能力，再把參數交給網站程式。網站仍然使用原本的 client action、REST API、session
與 server validation；WebMCP 沒有取代它們，只是補上一條不用猜畫面操作的入口。

WebMCP 提供兩種主要做法：Declarative API
替既有 HTML form 加上 Tool 註解，Imperative API
則透過 JavaScript 動態註冊能力。搜尋表單很適合前者；只在活動詳情 route 存在的
get_event_details，就比較需要後者處理註冊與解除。Day 11、12 會各拆一個最小 Lab。

名字裡雖然有 MCP，它也不是要求網站另外架設一個 MCP Server。Tool 活在目前開啟的
頁面與 Document 情境裡；瀏覽器如何把這些 Tool 交給 Agent，規格沒有綁死成單一
協定。這也是它和背景執行、跨網站使用的 MCP Server 不同的地方，Day 6 會再完整比較。

還有一個現況要先說清楚：WebMCP 目前是 W3C Web Machine Learning Community Group
發布的 Draft Community Group Report，不是正式 W3C Standard。Chrome 也仍把它放在
實驗功能中，本機測試需要啟用 WebMCP for testing flag。這個系列會把它當成一項
實驗中的 Web 能力來開發與驗證，不把「能跑」寫成「所有瀏覽器都已支援」。

網頁公開 Tool，也不代表任何聊天機器人都能直接呼叫。中間還需要支援這項能力的
瀏覽器或 Agent Host。本系列使用 Chrome、WebMCP Inspector 與 Inspector 整合的
Gemini 測試 Agent，分別觀察 discovery、手動執行與自然語言 invocation。

我先看它有沒有自己選到 search_events

Inspector 顯示 Agent 送出的參數是：

{
  "location": "taipei",
  "level": "beginner",
  "query": "",
  "price": "free"
}

taipei、free 和 beginner 都不是畫面上的中文原文，而是網站 Tool contract 裡定義
的值。Agent 必須先從目前頁面公開的能力中選出 search_events，再把「台北、免費、
入門者」轉成網站接受的 input。

我先不看最後回答，直接把 prompt 和 input 逐欄對照：

接著我才往下看 Tool result。它回傳一筆活動，包含固定的活動 ID、相對網址、名稱、
開始時間、地點、費用與程度。最後回答裡的「WebMCP 入門工作坊」、台北、免費與入門，
都能在 result 找到來源；詳情連結也沿用網站回傳的 /events/evt-webmcp-intro，不是
模型自己拼了一個看似合理的網址。

這個逐欄核對很重要。Agent 可能選對 Tool，卻偷偷放寬使用者條件；也可能拿到正確
result，最後回答時又改錯日期或補上網站沒提供的資訊。只看到活動名稱正確，很容易
漏掉中間兩種失敗。

如果我是在 Inspector 下方的 Tool 選單手動挑 search_events，再自己貼上這段 JSON，
那只能證明 Tool 可以執行。這次保存的 trace 多了前面那一步：Agent 從自然語言自行
選擇並呼叫 Tool。

網站回傳活動資料後，Agent 才把名稱、日期、地點、費用與詳情連結整理成人看得懂的
回答。這五段必須連在一起，只有最後那段漂亮回答還不夠。

一個成功畫面，其實疊了四件事

我一開始很容易把這張圖簡化成「Agent 會操作網站」。拆開後才發現，裡面至少有四個
不同責任：

AgentReady Events 目前公開五個 Tool：

這些 Tool 不是五顆按鈕的函式版。每一支都要交代任務、輸入、結果，以及執行到哪裡
必須停下來。

圖 2：首頁把五個 Tool、三條使用者 Journey 與人類停點放在同一張畫面。能力公開，不等於權限全部交出去。

我故意先把完成後的樣子攤出來

這張首頁不是 Day 1 當天才做好的版本，而是整個系列完成後的網站。我原本也想從
最小的 schema 或 Hello WebMCP 開始，但如果前十幾天只談 API、測試與註冊方式，
很難看出那些地基最後要組成什麼。

所以第一天先看終點。Day 2 再回到最小可執行版本，逐段把人類流程、Tool contract、
安全邊界與真實 Agent trace 補回來。

圖 3：先看一次完成後的使用方式，再回頭打地基；中段每完成一項能力就留下測試，不把 Agent 實測全部塞到最後。

這 30 天大致會走過四段：

這張成功圖，我只敢下到一個案例

search_events 這次成功，代表在當時保存的版本、頁面、prompt 與 Agent 環境裡，確實
發生過一次自然語言選擇與呼叫。它沒有替另外四支 Tool 自動取得相同結論，也沒有證明
換一個 Chrome profile、模型或日期後一定重現。

我會把這種紀錄當成後面每一題的最小單位：一個明確任務、一支 Tool、一組 input、
一份 result，再加上最後回答。成功與失敗都照原樣留下。

如果你今天只想先看懂一件事，可以回到圖 1，沿著黑色 trace 找出這五段。接下來
Day 2 會把共同版本在本機跑起來；在開始設計 Tool 以前，先確定人類使用的網站、API、
測試與 build 都能由讀者自己重播。