WebMCP 是什麼？讓網站告訴 AI 代理可以怎麼操作的標準提案

WebMCP（Web Model Context Protocol）是一項網頁標準提案，目的只有一句話：讓網站用結構化的方式，把「查詢、填表、預約、下單」這些功能宣告成 AI 代理可以直接呼叫的工具，代理因此用不著猜按鈕的用途、模擬人手點擊。它在 2026 年 6 月 9 日隨Chrome 官方的 origin trial 公告進入實測階段，Chrome 149 起可登記試用；規格本身由 W3C 底下的 Web Machine Learning Community Group 以草案形式發布，2026 年 10 月 20 日版的規格草案明文聲明它還在社群報告階段，仍非 W3C 正式標準。對經營網站的人，這兩個身份要一起記：規格方向已經吸引 Google 與 Microsoft 的工程師共同編修、Chrome 已開放實測，但介面細節仍可能變動，導入前把「可丟棄」設成前提。

它想解決的問題很好懂。AI 代理走進網站時，看見的只是文件物件模型（DOM）裡的一堆按鈕與欄位，它得推測哪個按鈕送出查詢、哪個欄位填人數，再一步步模擬點擊；猜錯一步，任務就失敗。Chrome 官方文件把這種「模擬真人滑鼠點擊與文字輸入」的操作稱為 actuation，並直指它的弱點：步驟多、每一步都開放給代理自行解讀。WebMCP 提供另一條路，網站主動聲明每個功能的用途與參數，代理照規格呼叫，正確率與可預期性都提高。全名裡的 Web 點出它的作用範圍：這是綁在網頁這一側的協定，工具由頁面提供、在使用者的分頁裡執行，與那些跑在應用程式後端的工具協定分屬兩個世界。

這篇以Chrome 官方文件與規格草案為本，查證時間為 2026 年 10 月 21 日。文中沒有實機導入紀錄，示意情境都會標明；規格仍在草案與試驗階段，動手前請以官方頁面當天內容為準。

快速重點：WebMCP 讓網站把功能宣告成工具，AI 代理從「模擬點擊」換成「結構化呼叫」。它與 MCP 是前後場分工、可以並用；工具只在分頁開著時有效；安全靠三個語意標記加信任邊界，唯讀標記只是訊號。想試的人從 Chrome flag 的本機測試起步，純內容站不必急。

從「模擬點擊」到「網站自己報上功能」

先把兩種操作方式擺在一起看。一種是代理讀完畫面後自己判斷：日期欄在哪、人數用下拉選單還是輸入框、送出前要不要勾同意，每個判斷都是一次出錯機會，版面一改，昨天的操作路徑可能整條報廢。另一種是網站預先把功能講清楚：這裡有一個叫 check_availability 的工具，需要日期、時段、人數三個參數，回傳可用時段清單。代理拿到的是規格，猜測消失了。

官方文件用一組對照圖說明這件事：左邊是代理掃描 DOM 推測用途，右邊是代理呼叫工具。它給 WebMCP 的定位是提供「互動規則」，橋接網頁應用與代理，提升效率、可靠度與任務完成率。工具會在網頁上以使用者看得到的方式執行，人能盯著流程走完，這對信任與品牌體驗都是保護。

支撐這套機制的三根柱子，出自官方文件的整理。Discovery（發現）：頁面以標準方式向代理註冊工具，例如 checkout 或 filter_results 這類名稱，代理知道這個站能做哪些事。JSON Schema（輸入輸出定義）：每個工具的參數與預期回傳都有明確型別定義，降低誤解與幻覺。State（狀態）：網站與代理共用當前頁面脈絡，代理知道此刻有哪些資源可以動。三件事合起來，把「網站功能怎麼用」從代理的推測題變成網站的聲明題。

工具本身長什麼樣？無論用哪種實作路線，一個工具都由三個部分組成：名稱（name）、描述（description）、輸入規格（inputSchema）。名稱給代理引用，描述講清楚這個工具做什麼、何時該用，輸入規格用 JSON Schema 定義每個參數的型別與必要性。這套結構與 MCP 的工具定義同一個哲學，官方比較文件也明說 WebMCP 是「受 MCP 啟發」的 API 組，為瀏覽器量身打造，省略了 resources 這類伺服器端概念。

有一條界線要先畫清楚：WebMCP 憑空長不出功能。網站本來就要有對應的服務邏輯，訂位系統、訂單查詢、表單後端，樣樣都得存在；WebMCP 做的事是把既有功能包裝成代理可用的介面。把它當作「幫網站加上原本沒有的能力」會期待錯方向，它是介面層的標準，該做的事是翻新說明書。

一次完整流程：以電商訂單查詢與退貨為例（示意）

以下用一個假想的電商情境走完整流程，工具名稱與回傳內容皆為示意，重點在看清角色分工：使用者提出需求、代理選用工具、網站執行功能，三件事由三方完成，缺一不可。

第一步，網站註冊工具。訂單頁提供兩個工具：get_order_status 負責查訂單狀態，參數是訂單編號與時間範圍；create_return_request 負責建立退貨申請，參數多一個退貨原因。兩個工具的描述各寫清楚用途與回傳內容，例如「查詢指定期間的訂單，回傳訂單編號、出貨狀態與目前位置」。這些描述會進入代理的脈絡，寫得含糊，代理就選錯工具或填錯參數。

第二步，代理取得工具清單。支援 WebMCP 的瀏覽器代理在使用者造訪網站時，讀取頁面註冊的工具。注意關鍵性質：工具跟著分頁的生命週期走，分頁關掉、使用者離開網站，工具就消失，代理無法在站外呼叫他們。這是官方文件明列的設計，也是 WebMCP 與 MCP 最直觀的差別之一。

第三步，對話帶入參數。使用者對代理說「幫我看上週那張訂單到哪了」，代理把口語對應到 get_order_status 的參數：時間範圍填上週、訂單編號若沒給就先用時間查。使用者漏講的資訊，代理應該回頭問，硬猜亂填只會把錯誤往後送。

第四步，網站執行、畫面可見。真正去查資料庫的是網站自己的程式，查詢結果反映在頁面上，使用者看得到整段過程。命令式 API 的 executeTool 呼叫會回傳執行結果，若工具觸發了頁面導覽則回傳 null，這些細節官方文件都有定義，開發時照規格處理即可。

第五步，確認後再送出。查到訂單與完成退貨是兩件事：前者唯讀，後者改變狀態。退貨這類不可逆動作，官方建議工具加上 consequentialHint 標記，讓代理或瀏覽器在執行前先向使用者確認；官方安全指南另提出 requestUserInteraction() 的設計，讓工具執行途中非同步請求使用者輸入，這個方法目前還沒寫進規格草案的介面定義，屬指南層級的建議。人留在決策迴圈裡，代理做的是遞刀，扣板機的還是人。

失敗分支要單獨設計，多數示範只演成功路徑，真實網站的價值都在失敗處理。查無訂單時，工具回傳該說「此時間範圍內沒有訂單，要不要改查上個月」，讓代理有下一步可走；退貨資格不符時，回傳該寫明原因（超過期限、已使用過折抵），代理才能轉述給使用者，免得使用者面對一句語焉不詳的失敗。錯誤訊息的讀者有兩位：代理讀它決定怎麼續行，使用者盯著畫面讀它決定要不要換方法，兩邊都要看得懂，工具才算堪用。

流程裡還有一個容易誤解的角色問題：代理從頭到尾沒有拿到網站的資料庫權限。它拿到的是工具清單與輸入規格，執行時把參數交給網站程式，由網站用自己的邏輯查詢、驗證、回傳。既有的一切商業規則（庫存上限、會員等級、黑名單檢查）能不能照常生效，取決於工具執行走的是不是同一套邏輯：宣告式工具就是表單送出，天生沿用既有流程；命令式工具的執行函式是另一條程式路徑，實作時要記得重用既有的驗證與授權，別為工具另開側門。WebMCP 換掉的只有「介面怎麼被使用」這一層，後端的權責一吋都沒讓。

兩種把功能變工具的方法：表單加註解，或 JavaScript 註冊

宣告式 API：在既有表單上加屬性

宣告式 API走的是「把已經存在的表單升級成工具」路線。在 form 元素加上 toolname 與 tooldescription 兩個屬性，表單就註冊成一個工具，欄位變成工具參數；瀏覽器負責把這些元素轉譯成代理讀得懂的結構化表示。代理呼叫工具時，瀏覽器把表單帶入焦點並填入欄位，表單在使用者眼前保持可見。送出預設仍由使用者按下送出鈕完成；若要工具呼叫時自動送出，可以在表單加上 toolautosubmit 屬性，兩種模式官方文件都有說明。拿掉 toolname 或 tooldescription 任一個，工具就取消註冊。

欄位層也有對應的屬性：toolparamdescription 用來描述單一欄位的用途，幫代理把參數放對位置；沒寫時瀏覽器退而使用欄位的 label 文字，再退一步用 aria-description。官方文件給的例子是一張客服表單，toolname 叫 createSupportRequest，下拉選單用 toolparamdescription 說明「決定這件請求送到哪個團隊」，瀏覽器轉出的 JSON 結構裡，每個欄位的型別與描述都清清楚楚。

這條路的甜頭是成本：不用寫新程式，既有表單加幾個屬性就能上線，改版拿掉屬性就退場，特別適合先小規模驗證。代價是彈性受限，它本質上依附在表單的送出行為上，涉及多步驟狀態轉移的複雜流程裝不進去。

命令式 API：用 JavaScript 註冊動態工具

命令式 API透過 document.modelContext 介面註冊工具。呼叫 registerTool 時一樣給名稱、描述與 inputSchema，再附上一個 execute 回呼函式，工具被呼叫時就執行它。官方範例裡有控制披薩配料層的 toggle_layer、查訂單狀態的 get_order_status，輸入規格用 JSON Schema 定出列舉值，代理只能從中選擇，亂填的空間被壓縮。

測試面官方也給了工具：getTools() 列出頁面上已註冊的工具，executeTool() 帶入參數手動執行，等於在自家頁面上扮演一次代理，驗證工具行為。Chrome DevTools 能對 WebMCP 工具除錯，檢查瀏覽器如何解析 JSON Schema；官方另提供一支範例代理擴充功能，用自然語言 inspect、monitor、execute 工具，開發者不必先有自己的代理就能驗收。框架生態已有動靜，Angular 提供實驗性支援，TypeScript 型別也有官方文件推薦的 npm 套件可用。

選擇的判準可以一句話講完：功能已經是一張表單、送出後就完成，用宣告式；功能需要狀態管理、多步互動或動態產生參數，用命令式。兩者可以在同一個網站並存，兩條路線官方文件都有示範站：zaMaker 披薩訂製與旅遊示範走命令式，Le Petit Bistro 餐廳示範走宣告式。

工具要怎麼寫，代理才會用對

註冊工具的程式碼不難，難的是把工具寫到代理「選得對、填得準」。這段拆官方範例裡三個值得抄的設計。

第一個是列舉值收緊輸入。官方的 get_order_status 範例把 timeframe 參數定成 oneOf 列舉：today、yesterday、last_7_days、last_30_days、last_6_months，每個值還帶人類可讀的 title。使用者說「最近七天的訂單」，代理把這句話對應到列舉裡的 last_7_days，自由發揮的空間被規格吃掉。反面教材是把時間交給開放字串，代理可能填「上周」「last week」「最近」，後端就要自己收拾同一種意思的五種寫法。能用列舉就用列舉，這是輸入設計的第一原則。

第二個是描述寫「做什麼與回什麼」，兩個都要。toggle_layer 的描述寫「控制披薩的配料層（醬汁、起司），動作用 add、remove 或 toggle」，一句話講完能力、範圍與合法動作；get_order_status 的描述寫「查詢指定期間的訂單，回傳訂單編號、出貨狀態與位置」，連回傳內容都先講清楚。代理選工具靠描述比對意圖，描述只寫「查訂單」三個字，代理在查物流、查發票、查退款三個相似工具之間就只能擲硬幣。官方的字數預算（描述五百字元內）不是要你寫滿，是要你把字元花在「何時該用我、我會回什麼」這兩件事上。

第三個是執行結果寫成可續行的句子。toggle_layer 的 execute 回呼回傳「Performed toggle on layer: sauce-layer」這種帶動作與對象的訊息，代理拿到後能直接向使用者覆述結果。回傳「ok」或錯誤代碼，代理就得自行腦補，覆述走音的責任最後還是算在網站頭上。把每個工具的回傳當成一句要被轉述的話來寫，是成本最低的品質投資。

命名上官方範例兩種風格並存：駝峰的 createSupportRequest、蛇形的 get_order_status 都有，規格對名稱只設字元與長度規則（ASCII 英數字、底線、連字號與點，128 字元內），沒有規定風格。本文的建議是挑一種風格全站統一：名稱是給程式引用的識別碼，穩定壓過優雅；描述是給模型讀的說明書，用自然語言寫清楚，準確壓過精簡。兩者角色有別，別互相搶工作。

WebMCP 與 MCP 的分工：前場與後場，各守一邊

「WebMCP 會不會取代 MCP」是Chrome 的官方比較文件開宗明義回答的問題，答案是不會，這個問題本身出自誤解。兩者不必二選一：WebMCP 既非 MCP 的延伸、也非替代，服務的需求不同。MCP 連接的是代理與外部系統（資料來源、工具、工作流），走 JSON-RPC，透過各語言 SDK 實作，任何平台、任何時間都能用；WebMCP 只作用在使用者眼前開著的網頁，瀏覽器扮演網站與代理之間的通訊者。官方給的類比是客服體系：MCP 像隨時待命的客服中心，WebMCP 像站在店內的專家，客人就在店裡時，店內專家反應最快、最懂現場。

幾個維度攤開來看更清楚。生命週期上，MCP 伺服器常駐，WebMCP 工具綁定分頁、頁面開著才存在。連線範圍上，MCP 跨桌面、行動、雲端，WebMCP 限於瀏覽器代理環境。介面互動上，MCP 無頭運行、在代理自己的介面裡渲染你的應用；WebMCP 貼著瀏覽器與 DOM，使用者的網站還是主場，代理是客人。發現方式上，MCP 靠各代理自己的註冊流程，WebMCP 的工具在使用者造訪期間由頁面直接註冊。典型用途一欄，MCP 做背景 API 動作，WebMCP 在即時網頁上導覽與操作。

還有一個維度官方特別點名：介面的主客關係。用 MCP 把服務接給代理時，你的應用介面要在代理的介面框架裡渲染，配合對方的版面限制，等於另蓋一套程式；WebMCP 讓代理走進你既有的網站，讀得到只在活著的分頁裡存在的 session 資料、Cookie 與 DOM。官方的講法很傳神：前者是你的應用當代理家裡的客人，後者是代理來你的平台作客。對已經投資大量前端工程與品牌體驗的網站，這個差別直接決定改造的深度。

分工的實務圖像是分層合作：核心邏輯、資料查詢、背景任務交給 MCP 伺服器，讓服務跨平台常在；網站前端的即時互動交給 WebMCP，使用者在站上時代理手腳最快。想在應用端視角深入 MCP 的 Host、Client、Server 架構與 token 成本，站上的MCP 運作原理專文有完整拆解；本篇聚焦網站端這一側。

對網站經營者，這個分工其實是好消息。多數網站根本沒有自己的 MCP 伺服器，也未必需要；WebMCP 把門檻降到「在自家頁面上宣告」，前端工程師就能處理，後端可以保持原樣。等任務複雜到需要跨站、離線、背景執行，再評估 MCP 也不遲，兩者並用正是官方建議的型態。

讀懂層與操作層：WebMCP 在網站代理化工程裡的位置

把鏡頭拉遠，網站面對代理的準備工作可以分兩層。讀懂層處理「代理拿不拿得到、讀不讀得懂內容」：關鍵事實靜態可達、語意標記正確、表單可及性完備，這些是地基，讓網站被讀懂、被操作的基礎工程有完整的診斷方法。操作層處理「代理能不能把任務做完」：WebMCP 正是這一層的新選項，把功能的用法講成機器可讀的規格。

順序不該顛倒。讀懂層沒清乾淨之前就上工具宣告，等於說明書寫得精美、倉庫門卻打不開；代理拿到工具清單，頁面本身的內容與流程照樣卡。實務上兩層互補：多數網站先修讀懂層的舊帳（無 label 的按鈕、互動後才載入的價格），有明確查詢或預約流程的頁面再疊上 WebMCP 工具，投資順序由任務價值決定。

它與 llms.txt 類倡議的差別也在這裡：llms.txt 描述的是「這個站有什麼內容」，屬於內容索引層；WebMCP 宣告的是「這個站能做什麼動作」，屬於行為介面層。一個幫代理找資料，一個幫代理做事，兩者不互斥，也都不該被當成排名武器，這點後面會再談。

誰在呼叫工具：代理的兩種形態，與它繼承的鑰匙

講了半天「代理」，值得停下來把這個角色拆開。能呼叫 WebMCP 工具的代理，官方文件的界定是在瀏覽器裡運行的代理，包含以擴充功能形態運行的代理。對照目前市場，這對應兩類產品：瀏覽器內建的代理（Chrome 自家的代理能力，或直接讀取 WebMCP 工具的其他內建助理），以及掛在使用者瀏覽器上的代理擴充功能。共同點是他們都活在使用者的瀏覽環境裡，看得見使用者眼前那個分頁。

桌面助理、雲端代理那類在瀏覽器外運行的產品，通常拿不到 WebMCP 工具，因為工具的生命週期綁在分頁上，接觸點在瀏覽器這一側。規格留有轉接的空間：它明言瀏覽器可自由決定怎麼把工具交給代理，走 MCP 或其他函式呼叫機制都行，官方範例的代理擴充功能就搭配一支瀏覽器外的 Node 伺服器運作；但前提都是瀏覽器在場，工具本身不出分頁。這條界線對導入決策有實際意義：你宣告的工具，主要服務對象是「陪使用者逛網站」的那層代理；要讓能力跨出瀏覽器、不受分頁生命週期限制，通常仍是 MCP 伺服器的案子，兩份需求、兩種工程。

身分繼承是理解代理威力的鑰匙，也是理解風險的鑰匙。代理以使用者的身分進站，帶著既有登入狀態，所以它能做使用者能做的事：查自己的訂單、用自己的優惠。網站的會員分級、權限矩陣、個人化體驗因此沿用同一套身分，不必為代理另建一套帳號邏輯；但得以沿用不等於自動保證，工具與畫面操作走的是不同程式路徑，工具執行若沒有接回既有的驗證與授權，落差就會從這裡冒出來。反過來說，代理誤動作時影響的也是真實帳戶，確認機制的價值因此更高。規格草案把這類風險的責任畫給四方：網站作者、代理供應商、瀏覽器、終端使用者，各自的防線要各自守住，沒有一方能替其他方買單。

安全這關：三個注入向量、三個語意標記、一條信任邊界

WebMCP 讓代理用正規介面操作網站，同時也把提示注入（prompt injection）的攻擊面攤開。規格草案的安全章節把它分成三個向量：工具詮釋資料注入（惡意網站在工具名稱、描述、參數描述裡夾帶指令，誤導代理後續行為）、輸出注入（工具回傳值裡藏指令，影響代理接下來的動作）、工具實作本身成為攻擊目標（提供高價值功能的網站反被惡意代理盯上；規格註明攻擊面未必因此擴大，但工具呼叫與介面操作走的是不同程式路徑，驗證邏輯若有落差就會冒出可利用的漏洞）。官方安全指南直說：模型端沒有保證能擋下注入的機制，攻擊可重現、數量在增加；網站端能做的，是把自己這側的防線先畫好。

網站端能用的工具是三個語意標記，都寫在官方的工具安全指南。untrustedContentHint 標明工具會回傳使用者生成內容或外部資料，提醒代理提高警覺；consequentialHint 設為 true 表示高風險或不可逆動作，讓代理或瀏覽器先向使用者要確認；readOnlyHint 標示工具不改變狀態，幫代理判斷何時可以少問一句。要緊的是規格草案同時講明：這些是判斷訊號，惡意網站可以省略或偽造它們，防堵注入最終是代理端安全模型的責任，規格無法強制。換句話說，標記幫好網站講清楚好意圖，防不了壞網站說謊。

風險治理的方法論也有出處可循。規格草案的安全章節表明會借重 MCP 已累積的風險評估與緩解經驗來發展 WebMCP 的對策，畢竟兩者的工具描述、輸入輸出結構同源，攻擊手法也會互相移植。站在網站角度，這意味著 MCP 生態已累積的提示注入案例庫與防護建議，多半可以直接拿來檢視自家工具的設計，安全評估不必從零開始。

跨源暴露要手動開門。registerTool 的 exposedTo 選項可以把工具開放給指定清單內的來源，預設情況下其他網站與跨源 iframe 看不到你的工具；Permissions Policy 的 tools 預設為 self，跨源 iframe 要用 allow="tools" 才能啟用。官方的提醒很實際：唯讀工具也會洩露使用者偏好，開放名單只放你願意直接分享那份資料的對象。

前一段談過代理繼承使用者身分，安全設計要順著這個事實落三件事：敏感操作一律設確認關卡（consequentialHint 標記，加上指南提出的 requestUserInteraction() 確認設計）；資料庫層級的權限控制照舊，工具執行務必接回既有驗證，該擋的照擋；工具輸出只回任務需要的最小欄位，順手的整批回傳等於把資料最小化原則拆掉。

寫工具描述也有保鮮期觀念。官方建議的字數預算：工具描述五百字元內、參數描述一百五十字元內、工具名與參數名三十字元內、單次工具輸出一點五千字元內；簡潔的描述與輸出能避免撞上代理端的防護上限。官方也註明這組數字會隨生態回饋調整，未來可能進入規格。安全指南的註記裡還有一個提醒：Chrome 擴充功能可以用 content scripts 查詢並執行 WebMCP 工具，具備 host_permission 的擴充功能本來就能改頁面，安裝擴充功能的信任決策在使用者手上。

現在能用嗎：試用管道、現實限制與生態進度

管道有兩條。正式試驗走 origin trial：Chrome 149 起可登記，這類計畫限時提供實驗性平台功能的早期存取，可能伴隨用量上限，目的是收集回饋、回饋後續迭代；登記方式與規範以 Chrome 的 origin trial 說明頁為準，公告並未載明結束期程，別把試用窗口當長期承諾。本機測試走 flag：在 chrome://flags/#enable-webmcp-testing 打開 Enabled、重新啟動瀏覽器，就能在自家網站上開發驗證，不必登記。

現實限制官方列了三條，都值得抄進評估表。第一，這套 API 主要為本機瀏覽器工作流設計，預設有人在迴圈裡看著畫面，headless 環境雖可能運作，官方立場保守。第二，高度複雜的介面要付重構成本：網站夠複雜時，可能得整理應用程式狀態與 JavaScript 才能乾淨地暴露工具。第三，工具可發現性受限：代理必須直接造訪網站才知道有工具可呼叫，沒有全網工具目錄這種東西。

生態進度兩邊都在動。規格側，草案由 Web Machine Learning Community Group 持續修訂，編輯群含 Google 與 Microsoft 的工程師，Chrome 團隊明言目標是做出任何具代理能力的瀏覽器都能實作的 API。代理側，瀏覽器內建代理之外，OpenAI 的 Codex 已在內建瀏覽器提供 Site tools，走的就是 WebMCP 路線，讓網站提供結構化呼叫、省掉模擬點擊，細節與模型門檻在Codex 內建瀏覽器的 Site tools一文有整理。Google 也在 I/O 2026 把「為代理世代準備網站」列入議程，方向一致。

時程判斷上有一個誠實的答案：不知道何時轉正。草案階段的 API 介面會變，Chrome 的試驗數據會影響規格走向，今天寫的程式碼明天可能要調整。把 WebMCP 專案當實驗投資，用漸進增強（progressive enhancement）的姿態疊在既有網站上，進可攻退可守，是官方文件自己也建議的姿態。

三個常見誤解，先拆掉再談導入

誤解一：宣告了工具，代理就一定會用。工具清單是網站遞出的說明書，用不用、何時用，決定權在代理與其背後的模型。描述寫得清楚、參數設計收緊，代理選用的機率才高；把工具丟上線就等著任務湧入，多半等來的是安靜。這也是為什麼工具設計值得當產品工作做，而非工程附加題。

誤解二：WebMCP 工具等於對外開 API。兩者差在三個地方：工具只在分頁開著時有效，關頁即消失，API 伺服器全年無休；工具在使用者眼前執行，API 在背景跑；工具綁使用者的瀏覽器身分，API 靠金鑰與授權。把它當 API 的輕量版來規劃，會錯估它的適用範圍與風險模型，最該類比的對象是「網站功能多開一個使用介面」：同一個使用者身分、同一套權限，只要工具執行接的是既有邏輯，行為就與真人點擊同一套。

誤解三：標了唯讀就安全。readOnlyHint 是寫給代理的判斷訊號，幫它決定何時少問一句，認證意味是零：惡意網站可以謊標、省略，代理端也可能誤讀。真正的防線在網站自己的授權設計與資料最小化，標記是潤滑劑，鎖頭永遠在伺服器那一側。其餘兩個標記同理：consequentialHint 提高確認機率，untrustedContentHint 提醒代理提防回傳內容，三者都是降低誤判的輔助，非替代任何一道實質控制。

對 SEO 與流量的實際影響：三件先講清楚的事

第一件，目前沒有證據顯示 WebMCP 會影響搜尋排名，也沒有證據顯示支援它會換到 AI 搜尋的推薦流量。它目前不在搜尋引擎檢索與索引的必要條件裡，官方從頭到尾談的是任務完成率，從未掛保證任何流量效果。把「上 WebMCP」寫進 SEO KPI 是錯誤歸因，規格設計的目的在操作層，與內容層的能見度是兩件事。

第二件，它改變的東西更根本：當代理能替使用者完成任務，「網站被逛」與「網站被用」的差距會拉大。流量報表看得到的瀏覽行為，與報表未必完整呈現的代理操作行為，未來在成交路徑上的占比可能逐步移動。讓任務在自家網站走完，對保留交易主導權的價值，高於任何單次的排名變化。這個趨勢也回頭強化讀懂層工程的重要性，內容讀不懂，工具再漂亮也沒人來呼叫。

第三件，優先順序按站型分流。純內容站（文章、評論、知識）沒有可宣告的操作流程，急著湊工具只是工程表演，先把內容的機器可讀性做滿才是正辦。有明確查詢或預約流程的站（訂位、報名、庫存查詢）最適合先試，挑一個高頻、低風險、參數清楚的流程做試點。交易與帳戶類網站收益最大、責任也最大，確認機制、失敗處理與信任邊界都要先設計好，再開第一個工具。

導入評估：一張分階段檢查表

評估不用發想，照下面四階段走，每一階段有明確的出口條件，做完再進下一階段。

幾個細節能少走彎路。工具描述照字數預算寫，寧短勿長；參數用列舉值限制範圍，開放字串就等於把把關責任交回給代理；每個工具都想一遍失敗長什麼樣（查無資料、額滿、資格不符），回傳要能引導下一步，錯誤訊息寫給代理讀，也要寫給看著畫面的人讀。改版時記得工具的存續綁在頁面元素上，表單重構的那個 sprint，工具宣告要跟著搬。

成本量級先抓對，預算才不會編錯。下面是依典型複雜度推估的示意區間，用意是抓數量級，不是報價。宣告式路線的投入以「屬性」計，一張表單加三到五個屬性，熟悉前端的工程師通常半天到一天可以驗完一個單純流程；命令式路線以「功能」計，每個工具要寫輸入規格、執行邏輯與錯誤分支，並納入既有的測試體系，一個像樣的工具通常以天計。兩者都還要加上持續成本：描述要隨功能演進維護、試用期間的回報要排人處理。用一個單純流程試點來推估，落在一位工程師一至兩週的量級屬合理預期，實際成本隨流程複雜度與站體架構浮動；拿這個量級對照該流程的交易價值，值不值得做通常當下就有答案。

試用期間的回報渠道官方已備好：對 API 設計的意見提到 WebMCP explainer 的 GitHub 議題、對 Chrome 實作的問題回 Chromium bug 系統，origin trial 的參與者也被明確邀請回報使用經驗。把遇到的失敗案例回報出去有雙重意義，一方面規格會因實據調整，另一方面你回報的邊界案例往往正是官方文件還沒寫到的區段，等於用最低成本拿到與規格團隊的溝通管道。

收在一個判斷上。WebMCP 值得關注的理由，在於它把「網站要怎麼被 AI 使用」這個問題，從各家代理的黑箱猜測變成網站可以掌握的公開規格；它不值得焦慮的理由，在於現階段沒有任何已證實的排名或流量紅利。看懂分工、修好讀懂層、用最小成本試一個工具，其餘交給規格演進的速度。標準的戰爭讓瀏覽器廠去打，網站這邊的工作向來同一件：把自己的功能講清楚，對人如此，對代理也如此。