WebMCP 是什麼？Cloudflare 讓網站成為 AI Agent 可操作介面

383 瀏覽

2026-10-05 更新

WebMCP 可以把網站原本只能讓人點擊的功能，整理成 AI agent 看得懂、能直接呼叫的工具。你可以把它想成：以前 agent 要看畫面、猜按鈕、填表單；WebMCP 則讓網站主動告訴它「這裡可以搜尋、篩選、開始詢價，但送出前要請使用者確認」。

最近更值得注意的是，Cloudflare 已經推出 WebMCP 的 developer preview。只要網站在 Cloudflare 後面，就能在 Dashboard 開啟 bridge，讓頁面註冊工具給 browser agent 使用，暫時不必改動原站程式。這不是把網站變成聊天機器人，也不是一般的 REST API；它是讓前台網站為 AI agent 準備「可操作介面」的一種新做法。

WebMCP 是什麼？讓網站把操作意圖講清楚

WebMCP 全名是 Web Model Context Protocol。它是一個仍在演進中的瀏覽器 API 草案，讓網頁能以 JavaScript 工具、自然語言描述與結構化輸入格式，向同一個瀏覽器分頁裡的 AI agent 宣告自己能做什麼。規格目前使用的入口是 document.modelContext。

假設一個旅館網站有搜尋地點、勾選早餐、開始訂房、完成訂房四個流程。傳統 browser agent 會看 DOM 或截圖後，嘗試找輸入框、按鈕與篩選器；WebMCP 則可以直接提供 search_location、filter_search_results、start_booking 這些工具，並定義每個工具需要什麼參數。它少掉的是猜測，不是取消網站的商業規則。

傳統 AI 操作網站	WebMCP 操作網站
看畫面、猜按鈕和欄位用途	讀取網站公開的工具名稱、描述與輸入 Schema
版面或 CSS 一改，流程可能失效	工具契約不變時，前台改版不必重教 agent
容易把類似按鈕點錯	直接呼叫明確動作，例如 `search_products`
結果通常要從畫面重新擷取	工具可回傳結構化結果，讓 agent 接著判斷

重點是 WebMCP 的工具在目前瀏覽器分頁裡運作，目標是讓人與 agent 共用網站的上下文與控制權。它不像後端 MCP server 一樣，讓 Claude、Codex 或其他客戶端從外部網路直接連一台伺服器；兩者都借用 MCP 的工具概念，但部署位置與信任邊界不一樣。

WebMCP、MCP、REST API 到底差在哪？

這三個名詞很容易混在一起，但其實各有位置。REST API 是系統對系統的資料與功能介面；MCP server 是讓 AI 客戶端以標準方式發現並呼叫後端工具；WebMCP 則把「目前這個網站分頁能做的事」交給 browser agent。它不是取代 REST API，而是能建立在既有 API 或 MCP server 之上的前台工具層。

技術	主要使用者	最適合的情境
REST API	網站、App、後端服務	資料讀寫、系統串接、Webhook。
MCP server	Claude Code、Codex、企業 agent	讓 AI 操作資料庫、GitHub、WordPress 後台或內部系統。
WebMCP	瀏覽器裡的 AI agent	讓 agent 在你的前台網站可靠地搜尋、篩選、填表與完成流程。

以 WordPress 來說，WordPress MCP 與 Abilities API 比較偏管理端：讓 agent 知道怎麼讀文章、建立內容或執行受權限控制的操作。WebMCP 比較偏客戶端：讓客戶自己的 agent 在網站上找到產品、查詢服務、整理資訊，必要時把使用者帶回真正的確認頁面。

Cloudflare 推出的 WebMCP 功能做了什麼？

Cloudflare 在 2026 年 8 月發布 WebMCP developer preview。它的作法不是要求你先把網站重寫成新框架，而是在 Cloudflare edge 用 HTMLRewriter 對 HTML 回應加入一個同網域 bridge script。支援 WebMCP 的瀏覽器遇到這個 bridge 後，才會將工具註冊到 document.modelContext；不支援的瀏覽器會直接略過，網站照原本方式運作。

目前 preview 的設定位置在 Cloudflare Dashboard 的 Agent Readiness → WebMCP。開啟網域功能後，可選擇工具包（packs）；Cloudflare 表示預設有 Content Credentials 與 Site MCP Server 兩組。前者讓 agent 在瀏覽器本機讀取圖片的 C2PA 內容憑證摘要；後者則把你已經存在、同網域的 MCP server 工具代理成前台 WebMCP 工具。

Cloudflare 的開關是加一座橋，不是自動替網站發明功能。你沒有 MCP server、產品搜尋或報價邏輯時，打開 WebMCP 不會憑空生出「幫我報價」工具。

開啟 Cloudflare WebMCP 後，網站能立刻得到什麼？

它的價值要分兩層看。第一層是 Cloudflare 提供的工具包：例如讓 agent 掃描頁面圖片、讀取 C2PA 內容憑證資料。第二層才是把你自己的 MCP 工具帶進來：若站台已經有 /mcp 之類的同網域 MCP endpoint，bridge 可以透過訪客目前的 session，把既有的 tools/list 與 tools/call 轉成 WebMCP 工具。

內容與素材驗證：讓 agent 看懂哪些圖片帶有內容憑證，適合媒體、作品集或品牌素材盤點。
產品與服務探索：把「搜尋產品、篩選規格、查詢庫存」設為低風險工具，少掉 agent 在 UI 裡亂找的成本。
導流與詢價：可讓 agent 協助填入已取得同意的需求資料，再把最終送出、付款或預約留給使用者確認。
已存在的 MCP 能力前台化：把原本只給後端 agent 用的查詢型工具，在正確權限與範圍下提供給訪客的 browser agent。

這對品牌網站的想像很有意思。未來不只是 Google 或 AI 搜尋引擎「讀得到」你的內容，而是使用者帶著 agent 進站時，也能更準確地完成服務比價、產品篩選或諮詢前整理。這和 WordPress Agent Skills 講的管理端工作流，會逐漸變成一前一後的完整體驗。

給 WordPress 網站的 3 個實際應用場景

1. 服務型網站：先幫客戶整理詢價需求

假設訪客對 agent 說「我想做一個有 SEO 與多語系的企業網站，預算先抓 15 萬」。WebMCP 不該直接把詢價表單送出去，而是可以提供 list_services、check_project_fit、start_consultation 這種查詢與預填工具。agent 整理完需求後，仍回到網站上的確認步驟，讓客戶知道要送出什麼。

2. WooCommerce：讓 agent 篩選，不讓 agent 任意下單

商品站可先暴露 search_products、filter_by_spec、compare_products。這類動作多半是讀取型，風險低、也很好驗證。加入購物車、提交訂單、付款等有後果的操作，則要設計使用者確認、人機協作與真正的帳號權限，不能因為「agent 做得到」就自動放行。

3. 內容站：讓文章不是只有被摘要

內容網站可將站內搜尋、依主題篩選、取得文章摘要、尋找相關教學整理成工具。這比讓 agent 抓整頁 HTML 更能控制脈絡與品牌導流。例如它可以回傳三篇最相關文章與清楚網址，再讓讀者回到原站閱讀完整內容。想把內容架構與 AI 工作流一起做好，可參考 Cloudflare AI Search 教學。

現在適合直接在正式站打開嗎？我的建議是先做測試

目前 WebMCP 仍是 Community Group 草案，Chrome 端也仍在實驗與 Origin Trial 階段；Cloudflare 也明確標示它的功能是 developer preview。這代表概念很值得提早掌握，但不代表所有訪客的瀏覽器與 agent 都已支援，更不代表可以跳過安全設計直接開到正式商業流程。

先盤點三個低風險動作：例如搜尋服務、查產品規格、取得文章列表，不要從付款、刪除或改帳號開始。
每個工具只做一件事：名稱、說明、輸入欄位與回傳結果都要清楚，避免一句「幫我處理」包進太多隱含權限。
所有有後果的行為都要確認：送出表單、預約、下單、付費、更新資料，必須保留可見的人工確認點。
用測試網域驗證：Cloudflare 可用 Browser Run 與 Chrome DevTools WebMCP 面板查看工具是否被正確註冊，再決定是否進正式站。
不要把秘密塞給前台：WebMCP 是前台能力介面，不是把 API Key、管理員權限或內部資料庫查詢直接送到瀏覽器的理由。

Cloudflare Browser Run 也已支援 WebMCP 的工具發現與呼叫，可作為開發驗證環境；不過官方文件仍提醒 Chrome Lab 是實驗性環境，不應當成正式 production workload。先把工具範圍縮小、權限縮小，反而比較快做出可靠的第一版。