本篇重點

30 天前我問：

AI 都會看畫面、點網站了，為什麼還需要 WebMCP？

30 天後，我的答案是：網站可以把功能整理成明確的工具，讓 Agent 知道怎麼輸入、怎麼執行，以及怎麼核對結果。

這套工具介面包含名稱、用途、輸入規則與回傳結果。網站仍保留給人操作的頁面，UI 與工具共用同一份服務邏輯。開發者要處理的，是資料格式、狀態同步、權限、錯誤與確認流程。

這篇回顧整個系列留下的功能、實測觀察與設計取捨。實作與操作集中在 Day 05～29；Day 30 收束成果與後續導入方向。

回到 Day 01 的兩條路

UI-only：

User
→ Agent 看畫面
→ 找 DOM / 元件
→ 模擬操作
→ 讀畫面結果

WebMCP：

User
→ Agent
→ Tool Contract
→ Website Business Logic
→ Structured Result

這兩條路不是二選一。

真正的 Agentic Web 很可能是：

能用 Tool 就用 Tool
沒有 Tool 再操作 UI
必要時讓人接手確認

30 天做了什麼？

第一階段：先搞懂它不是什麼

Day 01～04：

Browser Agent vs WebMCP
MCP vs WebMCP
Chrome / Community Draft / 社群專案差異
開發環境與實驗 API

這一段最重要的收穫反而是：不要把 WebMCP 當一個 npm package，也不要把它寫成已完成的 W3C 正式標準。

Chrome 將 WebMCP 定位為提議中的網頁標準；本系列使用的開發環境與 API 版本要一併記錄，移植時核對對應文件。

第二階段：把 Tool Contract 做好

Day 05～10：

registerTool
getTools
executeTool
name / description
inputSchema
Result / Error
Tool Lifecycle
Declarative Form

我最明顯的感受是：

Tool Calling 的 UX 很大一部分其實是 API Design。

Schema 寫得模糊，Agent 就只能猜。

第三階段：從 Demo 進入網站工作流

Day 11～17：

Search
Navigation
Form
Stateful Action
Human-in-the-loop
Goal-oriented Tool Design
Risk Matrix

這一段讓我最確定一件事：

50 個 UI 操作
不應等於
50 個 Agent Tools

Tool 應該反映使用者目標。

第四階段：安全與測試

Day 18～22：

Description A/B
30 Prompt Dataset
Prompt Injection
Origin / Permissions
Cross-origin iframe

這也是 WebMCP 從「很酷 Demo」走向 Production 最難的地方。

Agent 多一個 Tool，不只是多一個功能，也多一個攻擊面。

第五階段：真正接進 PHP / WordPress / WooCommerce

Day 23～27：

最終架構變成：

AI Agent
    ↓
WebMCP Tool
    ↓
JavaScript Adapter
    ↓
WordPress REST API / WooCommerce Store API
    ↓
PHP Business Logic
    ↓
Database / Session / Cart

這證明了我一開始最在意的 PHP 問題：

WebMCP 是 Browser JavaScript API，但不代表後端要用 JavaScript。

這次 WordPress／WooCommerce 的資料與購物車仍由 PHP、REST API 和瀏覽器工作階段處理；WebMCP 的 JavaScript 工具接上既有服務。
工具、服務與 API 分層後，頁面呈現可以改動，文章與商品查詢、購物車計算仍維持同一份邏輯。

圖片 1｜WordPress 外掛將 API、服務、工具與註冊管理分層；UI 與 WebMCP 共用網站的服務邏輯。

第六階段：讓 Agent 執行任務，再逐項驗收

Day 28～29 把文章搜尋、商品查詢、加入購物車、聯絡草稿與結帳預覽串成五題，保留工具名稱、參數、回傳與本輪 JSON。

Day 29 使用人工 UI／Chrome 與 WebMCP Inspector，並提供原版、改版兩種介面。T3 的配對截圖中，兩組都將商品 ID 102 加入兩件，總額為 4980 TWD。改版的欄位與卡片排列改變後，鍵盤搜尋仍依序列出 ID 101、102。

這次實作留下的成果

• 文章：搜尋「測試」後取得文章 ID，再讀全文；示範 ID 9 的全文為「測試內容」。
• 商品：搜尋鍵盤並限制價格，回傳公開商品；ID 101 的價格為 1290 TWD。找不到商品時回傳空清單。
• 購物車：加入、修改與移除同一商品，示範總額依序為 0 → 2580 → 1290 → 0 TWD。
• 工具管理：完整範圍註冊 8 個工具，移除後為 0，再重新註冊回到 8；文章範圍與商店範圍分開。
• 聯絡草稿：四個欄位依使用者資料填入，草稿可修改，回傳 submitted: false。
• 結帳預覽：讀取目前購物車並顯示商品、數量與總額，回傳 orderCreated: false、paid: false。
• 人工 UI 與 Inspector：Day 29 的 T3 都為商品 102、兩件、4980 TWD，頁面購物車與 Inspector 最後回答一致。

這些觀察讓我能從功能輸入一路核對到實際狀態。人工 UI 的操作紀錄與 Inspector 的工具 Trace 分開保存，結果依各自的操作環境呈現。

圖片 2｜人工 UI 將商品 ID 102 加入兩件，購物車目前總額為 4980 TWD。

圖片 3｜WebMCP Inspector 的購物車與最後回答，同樣為商品 ID 102、兩件、4980 TWD。

如果今天真的上正式站，我先開哪 3 類？

1. Public Search

search_posts
search_products

原因：

• Read-only。
• 風險低。
• 成效容易測。
• 查詢條件與回傳結果可以直接核對。

這會是我的第一批 Production Candidate。

2. Public Detail

get_post
get_product

讓 Search 回小結果，Detail 再取完整資料。

這對 Context 控制也有好處。

3. Current Cart Read

get_cart

它雖然 read-only，但含目前 Session 資料，所以要確認隱私與 Cross-origin 暴露範圍。

在正常 WooCommerce 頁面內，我認為有很高實用性。

第二批我會謹慎開

add_to_cart
remove_from_cart
update_cart_item
prepare_contact_message

它們會改狀態，但通常可逆。

正式上線前我會要求：

Idempotency
UI State Sync
Error Handling
Evals
Audit / Telemetry

哪些我暫時不會全自動？

至少：

confirm_checkout
delete_account
publish_post
refund_order
change_password
transfer_money

不是永遠不能做，而是一定要建立：

Preview
→ Explicit User Confirmation
→ Server Validation
→ Execute

而且 Security Eval 要獨立跑。

這 30 天踩到的 10 個坑

1. API 版本要與環境一起記

本系列外掛使用 document.modelContext 註冊工具，移除工具使用 AbortSignal；這兩個做法與 Chrome 的 Imperative API 文件相符。

2. 同名 WebMCP 不一定是同一套

規格、Chrome 實作、Directory、社群 Library 要分清楚。

3. Tool 會跑不等於 Agent 會選

Description 與 Schema 都要測。

4. Schema 太自由，模型就必須猜

能 enum 就 enum，數字就 number，必要欄位才 required。

5. Result 太大也是問題

REST API Response 不是 Agent Result。

6. Tool 太多會增加選擇成本

Goal-oriented，而不是 Button-oriented。

7. Read-only 不代表沒有風險

Order History、Address、Cart 都可能是私人資料。

8. Prompt Injection 不會因為 Tool 很結構化就消失

UGC／External Content 仍是不可信資料。

9. Nonce、工作階段與權限各有用途

這次購物車使用瀏覽器 Cookie 工作階段與 WooCommerce Store API Nonce。Nonce 核對請求，工作階段對應購物車；涉及私人資料或寫入時，後端仍要驗證使用者權限。

10. Evals 不是最後才做

Tool Description、Schema 一改，都可能造成 Regression。

我現在怎麼定義「Agent-ready Website」？

不是：

網站可以被 AI 看懂

而是：

網站能明確告訴 Agent：

我有哪些能力
每個能力需要什麼輸入
會產生什麼結果
哪些資料可信
哪些動作有副作用
哪些需要人確認
目前使用者有什麼權限

這已經比 SEO／Semantic HTML 再多了一層新的 Interface Design。

UI 會消失嗎？

我反而覺得不會。

WebMCP 的 Declarative Form 甚至直接建立在 HTML Form 上；高風險 Action 也更需要 UI 讓人確認真正後果。

所以我比較相信未來是：

UI for humans
+
Tools for agents
+
同一份 Business Logic

而不是：

有 AI 之後網站不用做 UI

接下來最值得觀察什麼？

後續整合時，我會核對以下項目：

• Chrome Origin Trial 的演進。
• Community Group Draft API 變化。
• 其他 Browser 是否跟進。
• Agent 如何做 Tool Discovery／Confirmation。
• WebMCP Evals 工具成熟度。
• Security best practices。
• WordPress／WooCommerce 是否出現原生或社群整合。

所以這 30 天不是「學完 WebMCP」，比較像建立一套之後規格變動時仍知道怎麼判斷的框架。

最後的架構圖

                 ┌────────────────────┐
                 │       User         │
                 └─────────┬──────────┘
                           │
                           ▼
                 ┌────────────────────┐
                 │      AI Agent      │
                 └─────────┬──────────┘
                           │
               ┌───────────┴───────────┐
               │                       │
               ▼                       ▼
      ┌────────────────┐      ┌────────────────┐
      │  Browser / UI  │      │  WebMCP Tools  │
      └───────┬────────┘      └───────┬────────┘
              │                       │
              └───────────┬───────────┘
                          ▼
               ┌────────────────────┐
               │ Website Logic/API  │
               └─────────┬──────────┘
                         ▼
          ┌────────────────────────────┐
          │ WordPress / WooCommerce   │
          │ PHP / Session / Database  │
          └────────────────────────────┘

這份架構把 UI 與工具連到同一份網站服務；文章與商品讀取公開 API，購物車保留瀏覽器工作階段，草稿與預覽把操作結果留在頁面上供人核對。

最後結論

如果 Day 01 的我問：

AI 都會點網頁了，WebMCP 還有必要嗎？

Day 30 的我會回答：

有，但不是每個網站都該立刻全部 WebMCP 化。

最有價值的起點，是那些使用者意圖清楚、目前 UI 操作步驟多、又能被安全包成結構化 Capability 的功能。

對我來說，WebMCP 最有意思的地方不是多一個 Web API，而是它逼網站開發者開始問一個以前很少問的問題：

除了人之外，我的網站要怎麼清楚、安全、可靠地讓 Agent 使用？

這大概就是下一代 Web Interface 很值得探索的地方。

參考資料

• Chrome WebMCP
• Chrome Imperative API
• WebMCP Draft Community Group Report
• WooCommerce Store API
• WordPress REST API

這 30 天留下了一套能查文章、找商品、管理購物車、填草稿與準備預覽的網站工具，也留下逐項核對輸入、回傳與頁面狀態的方法。網站的 AI 介面從這裡開始：先把能力說清楚，再讓每次操作有結果可查。