WebMCP 與 MCP 都在解決「AI 如何安全使用工具」的問題，但它們面對的場景不同。MCP 讓 AI 應用連接外部資料、服務與工作流程；WebMCP 則讓目前開啟的網頁，把搜尋、篩選、填表等功能直接提供給瀏覽器裡的 AI Agent。若把 MCP 想成 AI 的通用連接埠，WebMCP 更像是網站分頁內的操作介面。
這篇文章會從網站經營與 WordPress 應用角度，說明 WebMCP 是什麼、它和 MCP 差在哪，以及企業應該先導入哪一種。
WebMCP 是什麼？讓網頁主動提供 AI 可用的工具
WebMCP 是一套仍在發展中的瀏覽器 API 提案。網站開發者可以把頁面功能註冊成具名工具，附上功能說明與結構化輸入格式，讓瀏覽器內的 AI Agent 發現並呼叫。現行草案的核心介面是 document.modelContext，網頁可透過 JavaScript 註冊工具及其執行方式。
例如，電商網站可以提供 search_products、compare_products；服務型網站可以提供 find_service、start_consultation。AI 不必只靠截圖、DOM 結構或按鈕文字猜測下一步，而是能使用網站明確公開的功能。
WebMCP Community Group Draft 將它定位為網頁向 AI Agent 提供 JavaScript 工具的介面，也強調人與 Agent 在同一個網站畫面中合作。要注意的是：截至 2026 年 10 月，這份文件明確標示為 Community Group Report，尚不是正式 W3C 標準，也不在 W3C Standards Track。
MCP 是什麼？讓 AI 應用連接外部系統
MCP 是 Model Context Protocol 的縮寫，是 AI 應用連接外部系統的開放標準。AI 客戶端可以透過 MCP 取得工具、資料資源與提示範本，例如讀取資料庫、搜尋文件、管理 GitHub 專案或操作 WordPress 內容。
MCP 的典型架構包含 Host、Client 與 Server。你使用的 AI 應用是 Host；應用裡的 Client 維持與 MCP Server 的連線；Server 則提供可用能力。Server 可以在本機執行，也可以是透過 HTTP 連線的遠端服務。想先了解完整基礎，可閱讀 OrcaBiz 的MCP 是什麼？運作原理、API 差異與 WordPress 應用。
依照 MCP 官方文件，MCP 的作用是以一致方式連接 AI 應用與資料來源、工具及工作流程。它關心的是 AI 客戶端如何發現及呼叫外部能力，不限定功能一定顯示在瀏覽器頁面上。
WebMCP 跟 MCP 的差異比較
| 比較項目 | WebMCP | MCP |
|---|---|---|
| 主要位置 | 目前開啟的網頁與瀏覽器環境 | AI 應用與本機或遠端 MCP Server 之間 |
| 主要使用者 | 瀏覽器內的 AI Agent | ChatGPT、Claude、Codex、IDE 或企業 Agent |
| 提供能力 | 以頁面 JavaScript 為主的工具 | Tools、Resources、Prompts 等協定能力 |
| 狀態來源 | 目前分頁、登入狀態與網頁互動情境 | Server 可存取的外部資料與服務 |
| 常見用途 | 搜尋、篩選、填表、預約流程與頁面操作 | 文件查詢、程式開發、資料庫操作與後台自動化 |
| 傳輸與生命週期 | 由瀏覽器、來源政策與分頁生命週期管理 | 常見為本機 stdio 或遠端 Streamable HTTP |
| 成熟度 | 仍在草案與瀏覽器實驗階段 | 已有廣泛的客戶端與伺服器生態 |
兩者雖然都使用「工具、說明、結構化參數」這套概念，但 WebMCP 並不是把完整 MCP 協定直接塞進瀏覽器。WebMCP 的設計必須處理網頁來源、分頁生命週期、Permissions Policy 與可見介面同步；MCP 則有自己的客戶端／伺服器架構、協定探索與傳輸方式。
WebMCP 與 MCP 可以一起用嗎？
可以，而且實務上很可能會互補。WebMCP 負責讓訪客的 AI Agent 在網站前台使用清楚的操作工具；MCP 負責讓企業 AI、內部系統或內容團隊連接後台資料與工作流程。
- 前台：訪客請 AI 找出符合預算的服務，WebMCP 在目前頁面執行搜尋與篩選。
- 中間層：網站自己的 API 驗證條件、取得公開資料並回傳結構化結果。
- 後台：內容團隊透過 MCP 查詢文章、建立草稿、檢查 SEO 欄位與維護產品資料。
以 WordPress 為例，WebMCP 適合公開「查找服務、搜尋文章、預填詢價」等訪客功能；MCP 適合授權後的「讀取文章、建立草稿、更新欄位」等管理工作。OrcaBiz 的虎鯨網站助理 Vibe 連線教學，就是偏向後者的應用。
企業網站該選 WebMCP 還是 MCP？
選擇時先看任務發生在哪裡，不必急著二選一。
- AI 要操作企業內部資料或後台：先評估 MCP。它適合文件、CRM、WordPress 後台、程式碼與資料庫等受權限控制的來源。
- AI 要協助訪客使用目前網站：評估 WebMCP。它適合商品篩選、複雜表單、預約與站內導覽。
- 只是希望內容容易被搜尋與引用：先做好 SEO、結構化內容、內部連結與可索引性。WebMCP 不是收錄保證，MCP 也不會直接提高排名。
- 網站流程還沒有清楚 API 或權限：先整理資料模型與商業規則。工具介面只能公開已存在且能被安全執行的能力。
若網站同時需要內容管理與前台 Agent 體驗，可以先用 MCP 把內部資料與管理流程整理好，再挑一到三個低風險的前台功能做 WebMCP 原型。這通常比一次公開大量工具更容易測試，也能降低 Agent 選錯工具的機率。
導入 WebMCP 與 MCP 前，要先處理哪些安全問題？
工具變得容易呼叫，不代表權限可以放寬。無論使用哪一種技術，都應把工具描述視為介面說明，把真正的安全檢查寫在執行端。
- 最小權限：查詢工具只給讀取權；修改、發布、刪除與付款另設更嚴格權限。
- 執行時驗證：每次呼叫都重新檢查登入狀態、輸入內容與資源範圍，不能只相信 AI 傳來的參數。
- 保留人工確認：送出表單、下單、付款、預約與處理個資前，應讓使用者看見內容並確認。
- 限制資料暴露：不要把 API Key、管理員憑證或內部資料直接交給前端工具。
- 防範提示注入：網站內容、外部文件與工具回傳值都可能含惡意文字，不能讓它們取代既有授權規則。
Chrome Developers 的 WebMCP 說明也把需要確認的敏感操作、來源權限與工具安全列為重點。正式導入前，應先在測試環境確認工具註冊、錯誤處理、畫面同步及使用者取消流程。
WebMCP 與 MCP 常見問題 FAQ
WebMCP 是 MCP 的瀏覽器版本嗎？
可以用這個說法快速理解，但技術上不完全相同。WebMCP 借用工具與結構化參數等概念，並針對瀏覽器來源、分頁生命週期、網頁狀態與 Permissions Policy 設計；MCP 則是 AI 應用與本機或遠端 Server 之間的完整協定。
網站支援 MCP，就會自動支援 WebMCP 嗎？
不會。既有 MCP Server 不會自動在網頁中註冊工具。網站仍需建立 WebMCP 介面或使用適合的橋接方案，並重新檢查哪些能力可以安全提供給目前分頁中的使用者與 Agent。
導入 WebMCP 會直接提升 SEO 或 AI 搜尋排名嗎？
沒有這項保證。WebMCP 主要改善 Agent 操作網站的可靠性；搜尋收錄與排名仍取決於內容品質、可索引性、網站結構與既有 SEO 訊號。它可以改善使用體驗，但不應被當成排名捷徑。
WordPress 網站現在適合導入 WebMCP 嗎？
適合先做小型原型，例如站內搜尋、服務篩選或讀取公開文章摘要。由於 WebMCP 仍在發展，正式站應確認目標瀏覽器與 Agent 支援情況；付款、會員資料與發布操作應保留人工確認及後端權限驗證。
結語：先看 AI 要在哪裡完成任務
MCP 解決的是 AI 應用如何連接外部系統；WebMCP 解決的是瀏覽器裡的 AI Agent 如何可靠使用目前網站。企業若要管理內容、資料與內部工作流程，MCP 通常是較直接的起點；若希望訪客的 Agent 能搜尋、比較、填表或完成前台流程，再評估 WebMCP。
延伸閱讀可參考 iambigd.tw 的WebMCP 與 Cloudflare 應用整理。無論採用哪一種，先從可回復、可驗證、低風險的工具開始，並把權限與確認機制放在真正執行動作的程式裡。
