MCP 讓 AI 應用程式透過共同協定使用外部工具與資料；WebMCP 讓網站把頁面中的功能公開成工具，供瀏覽器代理操作。兩者的差異在於工具如何被提供、在哪裡執行，以及是否需要使用者正在瀏覽的頁面。它們可以搭配使用。
本文整理於 2026 年 10 月 13 日。WebMCP 仍在演進，下文以 Web Machine Learning Community Group 的提案為準；同名套件或其他專案不一定使用相同設計。
MCP 是什麼？讓 AI 接上工具與資料的共同介面
MCP 是 Model Context Protocol 的縮寫。它採用 Host、Client、Server 架構：AI 應用程式扮演 Host，由其中的 Client 呼叫 MCP Server 提供的能力。Server 可以在自己的電腦執行，也可以是遠端服務。
這些能力包含 Tools（可執行的動作）、Resources（提供情境的資料），以及 Prompts（可重用的提示範本）。協定以 JSON-RPC 2.0 定義訊息，標準傳輸方式包含本機的 stdio 與遠端的 Streamable HTTP。詳見 MCP 官方架構文件。
舉個設計情境：團隊可以把「查詢文章清單」「建立草稿」做成 MCP 工具，讓有權限的 AI 助理呼叫。使用者不必先打開 WordPress 編輯畫面，服務端就能處理工作。前提是有人完成相應整合與授權；網站有 API，並不代表它已經支援 MCP。
WebMCP 是什麼？讓網站明確告訴 AI 可以做什麼
WebMCP 的切入點是使用者正在操作的網站。網站開發者可以把搜尋、篩選等功能描述成工具，讓支援的瀏覽器代理知道可用動作與參數，並由頁面中的程式執行。使用者和代理因此能在同一個介面裡協作。詳見 WebMCP 官方專案說明。
例如使用者正在活動報名網站看場次，網站可以提供「依日期查詢場次」工具。代理帶入日期後，頁面利用既有邏輯更新結果，使用者也能看到畫面變化。這是應用情境示例，不代表所有報名網站或瀏覽器都已支援。
Chrome 在 2026 年 2 月的介紹中區分了兩種方向：以 HTML 表單描述標準操作的 Declarative API，以及以 JavaScript 提供較複雜互動的 Imperative API。它的目標是減少代理僅靠 DOM 操作時的歧義。參考 Chrome 官方早期預覽公告。
用一張圖看懂 MCP 與 WebMCP 的架構差異
圖中的差別是整合入口。MCP Server 可以再去呼叫 API 或存取資料；WebMCP 工具也可以透過網站原有流程向後端發出請求。WebMCP 並不表示整套服務都搬到前端，也不表示可以省略後端驗證。
MCP 與 WebMCP 差異比較表
| 比較面向 | MCP | WebMCP |
|---|---|---|
| 整合入口 | AI 應用程式中的 MCP Client | 支援的瀏覽器代理與網頁工具介面 |
| 能力提供者 | 本機或遠端 MCP Server | 網站頁面中的程式 |
| 主要情境 | 資料整合、跨服務流程、後台工作 | 使用者與代理一起操作網站 |
| 需要開啟頁面嗎？ | 協定本身沒有這項要求 | 依賴提供工具的頁面及其生命週期 |
| 介面重點 | 工具、資源與提示範本等協定能力 | 頁面公開的工具及其參數、執行邏輯 |
| 權限來源 | 依服務、傳輸及授權設計決定 | 結合頁面情境，仍須網站端授權檢查 |
| 導入依賴 | 相容的 Client、Server 與協定版本 | 瀏覽器、代理及網站實作的共同支援 |
表格是選型上的概括，實際能力仍取決於實作。MCP 也能包裝瀏覽器操作；WebMCP 也能透過網站後端處理資料，因此不能只用「後端對前端」來判斷全部用途。
WebMCP 是 MCP 的網頁版，或 MCP over HTTP 嗎？
名稱很接近，容易混在一起。MCP 本來就可以使用 HTTP 傳輸；把 MCP Server 放到網址上，並不會因此變成 WebMCP。WebMCP 官方專案特別說明，它與 MCP 共享工具概念，但沒有直接實作 MCP 的 JSON-RPC 協定，而是把能力放進網頁平台介面。參考 官方 README 的 MCP 關係說明。
也因此，既有 MCP Client 不會只因網站加入 WebMCP，就自動能呼叫那些工具。若要串起兩邊，需要相容的瀏覽器代理、橋接機制或相應整合。
以 WordPress 為例：文章管理與編輯協作怎麼選？
以下是架構設計示例，並非 WordPress 安裝後即具備的功能。
批次整理內容：若想讓 AI 查詢文章、產生摘要並建立草稿，可以由 MCP Server 提供範圍明確的工具。這類工作重點是服務整合與可控的權限，通常不需要重現人工點選後台的每一步。
在編輯畫面一起工作：若使用者已開啟文章編輯器，希望代理依當前文章協助檢查或執行操作，WebMCP 是可以評估的介面。工具要清楚描述修改對象與效果，畫面也要讓使用者看得見結果。
兩者並用：可以讓 MCP 負責跨系統蒐集資料，再由頁面工具支援編輯協作。這是可行的系統設計方向，實際可用性仍需逐一確認所用產品與瀏覽器。
導入前，先把權限和「最後一步」設計清楚
工具能被 AI 理解，不代表每次呼叫都正確或已獲授權。MCP 整合需要依官方安全建議處理授權邊界，避免不當的權杖傳遞等問題；WebMCP 草案也討論了提示注入、工具描述誤導及隱私風險。參考 MCP 安全實務與 WebMCP 安全與隱私章節。
我的導入建議是把「查詢」「修改草稿」「公開發佈」拆成不同工具，讓伺服器逐次驗證使用者權限，並保留操作紀錄。公開發佈、付款或刪除等有明顯後果的操作，應在介面清楚呈現影響及必要的使用者確認，不能把工具名稱當作安全保證。
看教學時要留意：WebMCP 的 API 還在變動
截至本文整理日，2026 年 10 月 9 日版本的 WebMCP 文件仍標示為 Draft Community Group Report，並明確說明它不是 W3C Standard，也不在 W3C Standards Track 上。該版草案使用 document.modelContext；較早期範例常見的 navigator.modelContext，不能直接假定適用於所有當前實作。請比對 當前草案及目標瀏覽器實際提供的 API。
Chrome 的早期預覽公告證明這項技術已有實驗入口，但不能據此推論所有穩定版瀏覽器都已預設支援。正式導入時，應先測試功能支援，並保留原本的人工作業流程。
我的選擇方式：先看 AI 要在哪裡完成工作
如果目標是讓 AI 助理整合資料與服務，我會先評估 MCP；如果目標是讓代理與使用者在同一個網站畫面協作，我會評估 WebMCP。需要兩種能力時，再設計兩者之間的銜接。
對網站經營者而言，可以先列出三件最值得交給 AI 協助的事：它們需要什麼資料、是否依賴當前頁面、完成後會造成什麼影響。這三個答案，通常比先選技術名稱更能決定該怎麼做。