InfoQ 於 8 月 10 日發布了 Cloudflare WebMCP 預覽的報導。Cloudflare 的官方公告日期為 8 月 6 日，並標註於 8 月 10 日更新。這份主要來源描述了 Agent Readiness > WebMCP 下的 1 個控制台開關。啟用後，Cloudflare 在邊緣使用 HTMLRewriter，向每個 HTML 回應注入同源的 /.webmcp/bridge.js 參照。橋接腳本尋找擬議的 document.modelContext 瀏覽器介面，組合已啟用的工具套件，並註冊帶有輸入結構描述的具名工具。Cloudflare 表示，如果瀏覽器沒有該介面，橋接腳本會直接停止，不改變頁面行為。來源伺服器端的應用程式碼無須修改。
這項預覽從 2 個工具套件開始。Cloudflare 表示，Content Credentials 會讀取影像開頭幾個 KB 中的 C2PA 來源中繼資料，但不會以密碼學方式驗證簽章，並回傳 signatureVerified: false。Site MCP Server 工具套件透過 tools/list 發現現有伺服器的工具。它的代理把 tools/call 傳送到同源 /mcp 端點，credentials 設為 same-origin，因此會使用訪客既有的工作階段。Cloudflare 表示，目前每個工具都在訪客的瀏覽器中執行，不會往返 Cloudflare 伺服器。這樣無須把後端 API 金鑰交給代理，但也讓已驗證身分的瀏覽器成為實際的權限邊界：更整潔的介面本身並不能讓會產生後果的操作變得安全。
對代理開發者而言，實質變化是介面合約。Cloudflare 和 InfoQ 對現有循環的描述很直白：視覺式瀏覽器自動化需要消耗 token 來解讀版面，可能誤判控制項，而且經常會在網站修改介面後失效。帶有 JSON 輸入結構描述的具名工具縮小了操作範圍，也明確了預期輸出。同樣重要的是，結構化呼叫可以區分工具缺失、執行錯誤和有效的空結果。用戶端如果悄悄退回擷取，就會重新製造歧義，並可能把呼叫失敗報告成沒有新內容。只有用戶端把這些狀態分開，WebMCP 才能減少這一類脆弱性。
對發布者而言，同一套機制也是控制介面。Cloudflare 允許網站擁有者選擇工具套件，並在日後無須重新部署來源伺服器的情況下啟用更多工具套件。Chrome 文件稱，WebMCP 要求使用 origin-isolated 文件，並且 tools Permissions Policy 預設為 self，除非明確允許，否則會阻止跨來源 iframe 存取。這些是真實的邊界。但網站的選單經過策劃：發布者可以公開一項有用操作，省略另一項，並塑造代理如何理解這項服務。機器可讀不等於完整或中立，而是由來源伺服器控制的協商介面。
不要把它理解為已經在所有瀏覽器中發布的標準。各來源對版本里程碑互相矛盾。Cloudflare 稱 WebMCP 在 Chrome 146 中處於實驗階段。InfoQ 稱 Chrome 145+。Chrome 文件於 8 月 7 日更新，其中稱來源試用從 Chrome 149 開始，本機測試還需要開啟 flag。這些數字不可能都在描述同一種可用性。它們共同支持的結論只有一個：WebMCP 仍處於提案階段，僅限 Chrome，而且可能變更。機器可讀的 Web 在這裡是網站、瀏覽器和代理之間的一份選擇加入合約，不是 HTML 的通用替代品。