InfoQ ने Cloudflare के WebMCP preview पर अपनी report 10 अगस्त को publish की। Cloudflare का canonical announcement 6 अगस्त का है और 10 अगस्त को updated दिखता है। Primary source Agent Readiness > WebMCP में 1 dashboard switch बताता है। इसे on करने पर Cloudflare edge पर HTMLRewriter से हर HTML response में same-origin /.webmcp/bridge.js reference inject करता है। Bridge proposed browser interface document.modelContext को खोजता है, enabled packs जोड़ता है और input schemas वाले named tools register करता है। अगर browser में यह interface नहीं है, तो Cloudflare के मुताबिक bridge page behavior बदले बिना रुक जाता है। Origin पर application code बदलने की जरूरत नहीं पड़ती।
Preview 2 packs से शुरू होता है। Cloudflare के मुताबिक Content Credentials images से C2PA provenance metadata के शुरुआती कुछ kilobytes पढ़ता है, लेकिन signatures को cryptographically verify नहीं करता और signatureVerified: false लौटाता है। Site MCP Server pack tools/list के जरिए मौजूदा server के tools खोजता है। इसका proxy credentials को same-origin रखकर tools/call को same-origin /mcp endpoint पर भेजता है, इसलिए visitor का existing session इस्तेमाल होता है। Cloudflare कहता है कि अभी हर tool visitor के browser में चलता है और Cloudflare server तक round trip नहीं करता। इससे agent को backend API key नहीं देनी पड़ती। साथ ही authenticated browser एक live authority boundary बनता है: साफ interface अपने आप किसी consequential action को safe नहीं बनाता।
Agent builders के लिए असली बदलाव contract है। Cloudflare और InfoQ मौजूदा loop को साफ बताते हैं: visual browser automation layouts समझने में tokens खर्च करता है, किसी control का मतलब गलत पकड़ सकता है और site का interface बदलने पर अक्सर टूटता है। JSON input schema वाला named tool action और expected output को सीमित करता है। उतना ही जरूरी है कि structured call missing tool, execution error और valid empty result में फर्क कर सकती है। जो client चुपचाप वापस scraping पर चला जाता है, वह ambiguity फिर बना देता है और failed call को कुछ नया न मिलने जैसा report कर सकता है। WebMCP इस तरह की fragility तभी घटाता है जब clients इन states को अलग रखें।
Publishers के लिए यही machinery control surface है। Cloudflare site owner को packs चुनने और origin को दोबारा deploy किए बिना बाद में और packs on करने देता है। Chrome documentation कहता है कि WebMCP के लिए origin-isolated document जरूरी है और tools Permissions Policy default में self होती है, इसलिए explicit permission के बिना cross-origin iframe access block रहता है। ये वास्तविक boundaries हैं। लेकिन site का menu curated है: publisher 1 useful action expose कर सकता है, दूसरा छोड़ सकता है और agent service को कैसे देखेगा यह shape कर सकता है। Machine-readable का मतलब complete या neutral नहीं है। इसका मतलब origin के control में negotiated surface है।
इसे हर browser में shipping standard नहीं समझना चाहिए। Sources milestone versions पर एक दूसरे से टकराते हैं। Cloudflare WebMCP को Chrome 146 में experimental कहता है। InfoQ Chrome 145+ कहता है। 7 अगस्त को updated Chrome documentation कहता है कि उसका origin trial Chrome 149 से शुरू होता है और local testing के लिए flag चाहिए। ये numbers एक ही availability को नहीं बता सकते। Sources मिलकर सिर्फ इतना support करते हैं कि WebMCP अभी proposed, Chrome-only और बदलाव के अधीन है। Machine-readable web यहां site, browser और agent के बीच opt-in contract के रूप में आ रहा है, HTML के universal replacement के रूप में नहीं।