WebMCP 是什麼？跟 MCP 差在哪？台灣電商先別急著動工

我最近在看一個 WebMCP 的官方示範網站，一個線上預約的 demo，程式碼寫得很乾淨。我順手把它的程式碼，跟 W3C 的規格原文擺在一起對照。

然後就對不上了。

demo 裡註冊工具的入口寫的是 navigator.modelContext.registerTool()，規格現在寫的卻是 document.modelContext.registerTool()。這不是誰手滑打錯字。規格自己把入口從 navigator 搬到了 document，而 Chrome 150 已經把舊的那個標記成 deprecated（即將淘汰），未來版本會直接移除。

一個 2025 年 8 月才首次發布的草案，幾個月內改掉了自己的名字。

所以你現在 Google 得到的 WebMCP 教學，不少還在教一個已經被改掉的寫法。

先別急著問「要不要接」

我知道你看到這裡在想什麼：「所以我是不是又落後了？要不要叫工程師趕快接一下？」

如果你問我，這是錯的問題。

看一下這份規格現在的體檢報告：狀態標示是 experimental（實驗性），截至 2026 年 8 月底，倉庫裡躺著大約 108 個 open issues（未解決的討論），Chrome 從 149 版開始才開放 origin trial（來源試用），本機想測還得手動去開 chrome://flags/#enable-webmcp-testing 這個旗標。規格文件自己開宗明義寫著：這是 Draft Community Group Report，不是 W3C 標準，也還沒進標準軌道。推手是微軟和 Google，掛在 Web Machine Learning 社群組底下。

翻成白話：WebMCP 還不是瀏覽器預設就能用的功能。 現階段它適合拿去 origin trial 或測試站踩踩看，不適合當成正式環境的依賴。

做過百貨專櫃的都知道，櫃位一改陳列，熟客就找不到原本那排貨。這幾年看規格草案，我養成一個習慣：先看它改過幾次名字。改名字代表底層的想法還在動，而底層還在動的東西，你花錢接上去，改的成本是你自己吸收。

錯的問題會讓你把預算丟進一個還在改的規格。對的問題只有一個：這件事裡面，哪一部分不會變？我現在只投那一塊。

WebMCP 是什麼？

用一句話講：WebMCP 是一個瀏覽器端的標準草案，讓網頁主動把「我這頁能做哪些事」宣告成結構化的工具，AI agent 直接呼叫，不用再去猜你的畫面。

以前 agent 要幫你在一個網頁上訂位，它得截圖、讀 DOM（網頁的元素結構）、猜哪個輸入框是日期、猜哪顆按鈕才是真的送出。現在網頁直接給它一份契約：這個工具叫 bookSlot，需要日期、時間、姓名、email，格式長這樣，跑完會回你什麼。

每個工具有名稱、說明、JSON Schema 定義的參數、annotations（標註，例如 readOnlyHint 告訴 agent 這個動作只讀不寫），還有實際執行的函式。這個描述形狀刻意貼著 server 端的 MCP 工具長，但它不是把 MCP 直接搬進瀏覽器：執行位置、生命週期、協定層都不一樣。

寫法有兩種。一種是用 JavaScript 呼叫 registerTool()。另一種更簡單，直接在 HTML 的 <form> 上加幾個屬性，像 toolname、tooldescription、toolautosubmit，各欄位再補上 toolparamdescription，完全不用寫 JS。

瀏覽器或擴充功能會把註冊好的工具收集起來，連同頁面網址、標題、來源權限範圍一起交給使用者的 agent。使用者還是在流程裡，該授權該確認的一樣要按。

這就像從「讓客人自己在賣場貨架間亂找」，進化到「直接遞一張菜單過去」。貨架重新陳列，客人就迷路；菜單上的品項不變，店裡裝潢改幾次都不影響點餐。

WebMCP 跟 MCP 差在哪？三個差別

這是最多人搞混的地方，名字只差兩個字母。

► 差別一：位置。 MCP 在 server 端，連的是你的資料庫、API、後台系統。WebMCP 在瀏覽器端，連的是使用者現在正開著的那一個頁面。

► 差別二：生命週期。 MCP 是 persistent（持續存在）的，Google 官方的說法是讓資料和動作「anywhere, anytime」都能用。WebMCP 是 ephemeral（短暫的），綁在那個分頁上，使用者一關頁面就沒了。

► 差別三：控制權。 MCP 你自己開一台 server 就有了，主導權在你手上。WebMCP 要瀏覽器支援、使用者授權、你的站台有註冊工具，三方到齊才成立。少一邊都不算數。對租平台開店的台灣品牌來說，第三邊還不在你手上。

我自己是這樣記的：MCP 像打給總公司的訂貨專線，你人在不在店裡都能打，隨時有效。WebMCP 像你已經坐在這家店裡，桌上那顆服務鈴，只在你這一桌、這個當下有效，起身走人就沒了。

那它們會打架嗎？不會。Chrome 官方文件講得很直接：partners, not opponents（是夥伴，不是對手）。官方建議的分工是核心商業邏輯、資料取得、背景任務走 MCP，WebMCP 只負責使用者當下那一頁的情境層。

這個邏輯我們之前聊過類似的：開了 MCP server 就等於做完了嗎？Linear 為什麼還要自己做原生 agent 那篇講的就是同一件事，通道打開不等於體驗做好。

台灣電商該怎麼辦？先看你的站台是不是你的

台灣讀者要先過一關：這個站台，你到底能不能改。

很多英文教學預設你改得動自己的 HTML，想加什麼屬性就加什麼屬性。台灣很多人不是這樣。

► 第一，先分清你是哪一種處境。 你是開店平台的房客（用 SaaS 開店系統）、marketplace 的攤商（蝦皮、momo、PChome），還是自己有站的站主？這三種的動作完全不一樣。

► 第二，如果你是房客，這是平台 roadmap 題，不是工程題。 就算平台開放你改佈景或塞腳本，核心表單和結帳流程通常還是碰不到，而那才是 agent 想呼叫的地方。你要做的是打電話問你的平台窗口：有沒有在追這份規格？會不會支援表單標註？roadmap 上排在哪？別急著找工程師報價，報了也動不了。

► 第三，marketplace 的攤商更現實一點。 你的商品頁本來就不是你的，agent 進來看到的是平台的頁面結構，不是你的。這題你連問的對象都沒有，先放著。

► 第四，不管哪個標準最後贏，這件事現在做都不虧：把「哪些動作值得被 agent 呼叫」列成一張表。 欄位就六個：動作名稱、需要哪些參數、成功回什麼、失敗回什麼、需要什麼權限、資料從哪來。先挑三個流程填填看，例如查訂單狀態、查可預約時段、查庫存。WebMCP 要用這張表，MCP 要用這張表，以後冒出來的第三個標準也要用這張表。填它花的是腦袋，不是工程時數。

► 第五，ship 了不等於被找到。 下面這個例子不是 WebMCP，是另一份叫 Agentic Resource Discovery（讓 agent 找到你的能力清單）的規格，但它講的道理一模一樣。工程師 Suganthan 在他的實作紀錄裡寫了一個很值得記下來的坑：他把能力清單檔案放上線，也通過了官方驗證，結果官方驗證工具第一次跑回來是 403。原因是那個工具用 Python 標準函式庫發請求，user-agent 是 Python-urllib，被 Cloudflare 的 managed bot rules 在邊緣直接擋掉。同一個檔案，瀏覽器 200、ClaudeBot 和 GPTBot 200、curl 200、空 user-agent 也 200，唯獨規格自己的官方驗證工具吃 403。

台灣站台為了擋刷單、擋惡意爬蟲，WAF 和防爬蟲規則通常開得比國外還兇。你猜這件事會不會發生在你身上？

再補一個。同一份規格的 11 家發起公司，在發布三天後，主網域上幾乎都沒有真的部署那個檔案，多數回 404 或 403。新聞稿只代表共識開始形成，不代表平台已經部署。你的採用判斷要看的是平台有沒有給你可測的東西，不是誰簽了名。

► 第六，預約型生意比純電商更早吃到紅利。 你注意到沒有，那個 demo 做的是 booking，不是購物車。餐廳訂位、醫美諮詢、課程報名，這類動作天生就有清楚的契約：時間、人數、姓名、聯絡方式，跑完就結束。台灣電商的「加入購物車到結帳」綁死金流、物流、發票、超商取貨，那遠遠不只是一個 form。誰先被 agent 操作，順序很清楚。

標準會一直疊上來

如果你想先把 server 端那條路走順，站上有兩篇可以接著看：MCP stateless vs stateful 差在哪講的是部署決策，MCP stateless 新規格解讀講的則是規格變動會怎麼讓你的舊連線變成技術債，跟今天這篇 deprecated 的故事是同一個劇本。想直接動手跑一次的，GA4 MCP Server 安裝教學是門檻最低的入口。

這年頭就是規格、規格、規格。一層疊一層，而且每一層攤開來看，其實都只是一個小檔案、幾個屬性。

真正稀缺的從來不是接規格的工程時數。

是想清楚你的站台對 agent 來說，到底能做什麼。

協作聲明與免責

這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 [來源名稱](URL) 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。

內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。