WebMCP 是什麼？用途、原理與 MCP 差異

WebMCP（Web Model Context Protocol）是一項網頁標準提案，讓網站把「查詢空位、填寫表單、建立訂位」等功能，整理成 AI 代理可以理解與呼叫的工具。網站會說明工具能做什麼、需要哪些資料，再由支援這套能力的代理協助使用者操作。

對經營網站的人來說，這代表可以更明確地告訴 AI 該如何使用網站。對使用者來說，則有機會在保留原本網頁的情況下，讓助理代辦部分工作。下面用一次餐廳訂位，說明它的原理、與 MCP 的差異，以及現在適不適合開始做。

WebMCP 解決什麼問題？讓網站說清楚能做的事

假設你打開餐廳網站，請 AI：「幫我找星期五晚上七點、四個人的座位。」一般瀏覽器代理可能需要讀取畫面、網頁結構或無障礙資訊，再找日期、人數與查詢按鈕，逐步操作。

如果網站提供 WebMCP 工具，就能直接表明：「這個工具負責查詢空位，需要日期、時間與人數。」代理可以依這份說明傳入資料，減少自行判斷按鈕用途與操作路徑的工作。這是Chrome 文件介紹的核心用途。

這裡的「工具」，可以理解成網站開放的一項具體功能。人仍然可以看網頁、改欄位、確認結果；AI 則多了一個使用同一網站功能的入口。它也不會憑空替餐廳建立訂位系統，網站原本就要有相應的服務與處理邏輯。

工商時間

如果你想要更系統化、更輕鬆的學好 SEO 與 AI SEO，歡迎參考我與知識衛星合作的 SEO 線上課程：《SEO 排名攻略學》、《AI SEO 流量變革》。

透過《SEO 排名攻略學》獲得穩定的 SEO 流量與實戰經驗。
再搭配《AI SEO 流量變革》看懂 AI 搜尋趨勢，搶佔 AI 搜尋紅利。

用一次餐廳訂位，看懂 WebMCP 如何運作

接下來是一個假想餐廳的教學情境，工具名稱與回傳內容都是示意。重點是看清楚：使用者提出需求、代理選用工具、網站執行功能，這幾件事由不同角色完成。

第一步：網站先公開 WebMCP 工具

餐廳可以提供「查詢空位」與「建立訂位」兩個工具，分別寫清楚用途與必填資料。查詢工具需要日期、時間、人數；訂位工具則可能還需要姓名與聯絡方式。

這些資料要求稱為「輸入規格」，作用是告訴代理每個欄位該放什麼。正式規格與Chrome 的工具註冊文件，都以工具名稱、描述與輸入規格來表達能力。

第二步：代理取得工具，帶入使用者的需求

支援 WebMCP 的代理在使用者造訪網站時取得可用工具，再把「星期五、晚上七點、四個人」對應到查詢欄位。若使用者只說「幫我訂星期五」，卻沒有交代人數，助理應先問清楚，再往下進行。

真正查詢餐廳資料的是網站程式。它可以沿用既有系統，回傳「七點已滿、七點半還有四人座」之類的結果。WebMCP 專案的流程圖也說明，動作由網站自己的程式執行，並同步更新網頁狀態。

第三步：確認訂位內容，再核對網站結果

查到空位與完成訂位是兩件事。使用者同意七點半後，才進入建立訂位的階段；若有訂金或取消費用，也應先讓使用者看清楚。開發者需要在這類重要動作中安排適當的確認。

執行後，助理還要依網站回傳的結果，交代訂位是否成立、時間與人數。假如網站回報失敗，就不能只因工具已被呼叫，便說「幫你訂好了」。這也是評估一個流程是否可用時，值得實際測試的地方。

WebMCP 的兩種做法：HTML 表單與 JavaScript

網站開發者可以從現有表單開始，也可以用程式註冊較有彈性的工具。對非工程背景的讀者而言，先掌握兩種做法各自適合什麼功能，就足以和開發者討論。

宣告式 API：替現有表單補上用途說明

宣告式 API（Declarative API）是在 HTML 表單加上工具名稱與描述，讓瀏覽器把表單轉成可供代理使用的工具，欄位則對應輸入資料。餐廳若已有日期、人數與聯絡資料欄位，就可以評估這種做法。

代理填好欄位後，可以保留由使用者手動送出的流程；自動送出則需要另行設定。Chrome 宣告式 API 文件有區分這兩種選擇，因此「加入 WebMCP」不等於「表單一律自動送出」。

命令式 API：用 JavaScript 定義動態工具

命令式 API（Imperative API）由開發者用 JavaScript 註冊工具，寫好用途、輸入規格與執行動作。像餐廳需要先查可用時段、再依結果更新網頁，就可以評估把這些程式邏輯提供成工具。

這種做法提供更多彈性，也需要開發者處理資料驗證、錯誤與畫面狀態。WebMCP 提供的是代理使用功能的介面；餐廳仍要自行處理名額、重複訂位等商業規則。

MCP、WebMCP 與瀏覽器自動化差在哪？

MCP（Model Context Protocol）是讓 AI 應用連接外部工具與資料的開放協議。餐廳可以透過 MCP 提供訂位服務，讓具備相應整合與權限的助理使用；這類整合不必以使用者正開著餐廳網頁為前提。

WebMCP 則把重心放在當前網頁。使用者已經開啟餐廳網站，代理可以利用網頁提供的工具，配合眼前的操作狀態協助完成工作。離開原頁或關閉分頁後，原頁工具便不再提供使用；這不表示已成立的訂位也會跟著取消。

Chrome 的比較文件明確指出，兩者服務不同需求，WebMCP 並非 MCP 的延伸或替代方案。若還想分清楚 MCP 與網站既有 API 的分工，可以接著看MCP vs API 比較。

一般瀏覽器自動化則是透過頁面資訊與操作介面完成任務，例如找欄位、填日期、按查詢。網站沒有提供工具時，代理仍可能用這種方式操作；有工具時，也可以搭配使用。WebMCP 專案說明也保留了這種共存方式。

工商時間

如果你想要更系統化、更輕鬆的學好 SEO 與 AI SEO，歡迎參考我與知識衛星合作的 SEO 線上課程：《SEO 排名攻略學》、《AI SEO 流量變革》。

透過《SEO 排名攻略學》獲得穩定的 SEO 流量與實戰經驗。
再搭配《AI SEO 流量變革》看懂 AI 搜尋趨勢，搶佔 AI 搜尋紅利。

現在能用嗎？哪些網站適合先試？

WebMCP 仍在發展與試驗中。Chrome 已從 149 版提供 origin trial，讓開發者參與限時試驗、蒐集實際使用回饋；本機開發也可透過測試旗標啟用。這些入口可參考Chrome 的試驗公告與本機測試說明。

有試驗入口，不代表所有瀏覽器與 AI 助理都已支援。網站要先提供工具，使用者的瀏覽器與代理也要有相容能力。此外，規格草案的狀態說明明列，它尚不是 W3C 正式標準，也不在 W3C 標準制定軌道上。

如果你負責網站，可以依目前的需求決定下一步：

• 主要是文章、品牌與服務介紹：先把內容、表單與一般使用體驗做好，持續觀察，不必為了新名詞立刻改造全站。
• 有明確、重複的查詢流程：可和開發者挑一項功能試做，例如只查餐廳空位，測試日期、人數與滿位時能否正確處理。
• 要建立訂位、付款或修改資料：把登入權限、確認內容、失敗回應與結果核對一起設計，再評估擴大使用。

WebMCP 也不保證 AI 永遠理解正確。Chrome 的工具安全文件提醒，代理仍可能受惡意文字指令影響。重要動作需要適當確認；工具標示「唯讀」也只是協助判斷的訊號，不能取代網站本身的權限與資料保護。

結語：先挑一件值得交給 AI 的事

理解 WebMCP，可以先回到餐廳訂位：網站把可用功能說清楚，代理依需求使用工具，人仍能參與確認，最後以網站結果判斷是否完成。比起一次開放所有操作，先挑一件範圍清楚、容易核對的工作，更容易知道它對你的網站有沒有幫助。

如果你的下一個問題是「整個網站要怎麼讓 AI 更容易瀏覽與操作」，可以接著閱讀AI 友善網站與 Agentic Browsing 介紹，一起理解工具介面、無障礙與版面穩定的分工。