जेव्हा एआय एजंट वेबसाइटला भेट देतात, तेव्हा ते मूलतः एक पर्यटक असतात जे स्थानिक भाषा बोलत नाहीत. LangChain, Claude Code, किंवा वाढत्या लोकप्रिय OpenClaw फ्रेमवर्कवर बनवलेले असो, एजंटची भूमिका कोणती बटणे दाबायची याचा अंदाज लावण्यापुरती मर्यादित आहे: रॉ HTML स्क्रॅप करणे, मल्टीमीडिया फॉर्मचे स्क्रीनशॉट काढणे आणि शोध बार कुठे आहे हे शोधण्यासाठी हजारो टोकन बर्न करणे.
ते युग संपले असेल. या आठवड्याच्या सुरुवातीला, Google टीमने Chrome लाँच केले WebMCP – वेब फॉर्म कॉन्टेक्स्ट प्रोटोकॉल – क्रोम 146 कॅनरी मध्ये प्रारंभिक पूर्वावलोकन म्हणून. वेबएमसीपी, जे गुगल आणि मायक्रोसॉफ्टच्या अभियंत्यांनी संयुक्तपणे विकसित केले आणि W3C च्या माध्यमातून उष्मायन केले. मशीन लर्निंग वेब समुदाय गटहे एक प्रस्तावित वेब मानक आहे जे कोणत्याही वेबसाइटला नवीन ब्राउझर API: navigator.modelContext द्वारे एआय एजंटना संरचित, थेट कॉल करण्यायोग्य साधने उघड करण्यास अनुमती देते.
एंटरप्राइझ आयटीचे परिणाम लक्षणीय आहेत. त्यांचे वेब ॲप्लिकेशन AI प्लॅटफॉर्मशी जोडण्यासाठी Python किंवा Node.js मध्ये वेगळे बॅक-एंड MCP सर्व्हर तयार आणि देखरेख करण्याऐवजी, डेव्हलपमेंट टीम आता विद्यमान क्लायंट-साइड JavaScript लॉजिकला एजंट-वाचनीय साधनांमध्ये एकत्रित करू शकतात – एकल पृष्ठ पुन्हा डिझाइन न करता.
एआय एजंट इंटरनेटवर महागडे आणि नाजूक पर्यटक आहेत
वेब एजंट परस्परसंवादाच्या (ब्राउझर प्रॉक्सी) सध्याच्या पद्धतींसह किंमत आणि विश्वासार्हता समस्या ज्यांनी त्यांना मोठ्या प्रमाणावर तैनात केले आहे त्यांना चांगले समजले आहे. दोन प्रचलित पद्धती – व्हिज्युअल स्क्रीन स्क्रॅपिंग आणि DOM विश्लेषण – मूलभूत कमतरतांमुळे ग्रस्त आहेत जे थेट एंटरप्राइझ बजेटवर परिणाम करतात.
स्क्रीनशॉट-आधारित पद्धती वापरून, एजंट मल्टीमीडिया मॉडेल्सना (जसे की क्लॉड आणि जेमिनी) प्रतिमा पास करतात आणि आशा करते की मॉडेल केवळ स्क्रीनवर काय आहे हेच नव्हे तर बटणे, फॉर्म फील्ड आणि परस्परसंवादी घटक कुठे आहेत हे देखील निर्धारित करू शकतात. प्रत्येक प्रतिमा हजारो टोकन वापरते आणि दीर्घ विलंब असू शकते. DOM-आधारित पध्दती वापरून, एजंट कच्चा HTML आणि JavaScript घेतात—एक परकीय भाषा आहे जी विविध टॅग, CSS नियम आणि स्ट्रक्चरल टॅग्जने भरलेली आहे जी हातातील कार्याशी संबंधित नाही परंतु तरीही संदर्भ विंडो स्पेस आणि अनुमान खर्च वापरतात.
दोन्ही प्रकरणांमध्ये, एजंट वेबसाइट कशासाठी डिझाइन केली गेली होती (मानवी डोळा) आणि मॉडेलला कशाची आवश्यकता आहे (उपलब्ध क्रियांबद्दलचा संरचित डेटा) यांच्यात भाषांतर करतो. मनुष्याने काही सेकंदात पूर्ण केलेल्या उत्पादनाचा शोध घेण्यासाठी डझनभर अनुक्रमिक एजंट परस्परसंवादाची आवश्यकता असू शकते—फिल्टरवर क्लिक करणे, पृष्ठे स्क्रोल करणे, परिणामांचे विश्लेषण करणे—त्यापैकी प्रत्येक एक अनुमान कॉल आहे जो विलंबता आणि खर्च जोडतो.
WebMCP कसे कार्य करते: दोन API, एक मानक
WebMCP दोन समाकलित API प्रस्तावित करते जे वेबसाइट्स आणि AI एजंट्स दरम्यान पूल म्हणून काम करतात.
द व्याख्या API हे मानक क्रिया हाताळते ज्या थेट विद्यमान HTML फॉर्ममध्ये परिभाषित केल्या जाऊ शकतात. ज्या संस्थांचे उत्पादन आधीपासूनच सुव्यवस्थित मॉडेल आहेत त्यांच्यासाठी, या मार्गासाठी किमान अतिरिक्त कार्य आवश्यक आहे; विद्यमान फॉर्म टॅगमध्ये साधनांची नावे आणि वर्णन जोडून, विकासक हे फॉर्म एजंटद्वारे कॉल करण्यायोग्य बनवू शकतात. तुमचे HTML फॉर्म आधीच स्वच्छ आणि व्यवस्थित असल्यास, तुम्ही कदाचित 80% मार्गावर असाल.
द अत्यावश्यक API हे अधिक जटिल डायनॅमिक परस्परसंवाद हाताळते ज्यासाठी JavaScript अंमलबजावणी आवश्यक आहे. येथेच डेव्हलपर अधिक समृद्ध टूल स्कीमा परिभाषित करतात – ओपनएआय किंवा अँथ्रोपिक एपीआय एंडपॉईंटला पाठवलेल्या टूलच्या व्याख्यांप्रमाणेच, परंतु ब्राउझरमध्ये पूर्णपणे क्लायंट-साइड चालू आहे. RegisterTool() द्वारे, वेबसाइट संपूर्ण पॅरामीटर मॅपिंग आणि नैसर्गिक भाषेच्या वर्णनांसह searchProducts(क्वेरी, फिल्टर) किंवा ऑर्डरप्रिंट्स (कॉपी, पृष्ठ_आकार) सारखी कार्ये उघड करू शकते.
मुख्य कल्पना अशी आहे की WebMCP द्वारे एकल टूल कॉल डझनभर ब्राउझर वापर परस्परसंवाद बदलू शकतो. शोधउत्पादन साधनाची नोंदणी करणारी ई-कॉमर्स साइट एजंटला एकच संरचित फंक्शन कॉल करण्याची आणि संरचित JSON परिणाम प्राप्त करण्यास अनुमती देते, एजंटला ड्रॉप-डाउन फिल्टर मेनू क्लिक करणे, पृष्ठांकित परिणामांमधून स्क्रोल करणे आणि प्रत्येक पृष्ठाचा स्क्रीनशॉट घेणे आवश्यक नाही.
फाउंडेशन केस: खर्च, विश्वसनीयता आणि ड्रेजिंगचा नाजूक शेवट
AI उपयोजनांचे मूल्यमापन करणाऱ्या IT निर्णयकर्त्यांसाठी, WebMCP एकाच वेळी तीन सततच्या भेद्यतेला संबोधित करते.
खर्चात कपात हा सर्वात तात्काळ परिमाण करण्यायोग्य फायदा आहे. स्क्रीनशॉट सीक्वेन्स, मल्टीमॉडल इन्फेरेन्स कॉल्स आणि पुनरावृत्ती DOM एकल स्ट्रक्चर्ड टूल कॉल्ससह पार्सिंग करून, संस्था टोकन वापरामध्ये लक्षणीय घट होण्याची अपेक्षा करू शकतात.
विश्वासार्हता हे अधिक चांगले होते कारण एजंट यापुढे पृष्ठ संरचनेचा अंदाज लावत नाहीत. जेव्हा एखादी वेबसाइट स्पष्टपणे विजेट करार प्रकाशित करते – "ही फंक्शन्स आहेत ज्यांना मी सपोर्ट करतो, हे त्यांचे पॅरामीटर्स आहेत आणि ते याकडे परत येतात" – विषय निश्चितपणे कार्य करतो, अनुमानाने नाही. UI बदलांमुळे, डायनॅमिक सामग्री लोडिंगमुळे किंवा नोंदणीकृत साधनाद्वारे कव्हर केलेल्या कोणत्याही परस्परसंवादाचे अस्पष्ट घटक ओळखणे यामुळे अयशस्वी परस्परसंवाद मोठ्या प्रमाणात काढून टाकले जातात.
विकासाचा वेग हे वेग वाढवते कारण वेब टीम स्वतंत्र बॅक-एंड इन्फ्रास्ट्रक्चर तयार करण्याऐवजी समोरच्या बाजूला विद्यमान JavaScript चा फायदा घेऊ शकतात. स्पेसिफिकेशन यावर जोर देते की वापरकर्ता पृष्ठाच्या UI द्वारे पूर्ण करू शकणारे कोणतेही कार्य पृष्ठावरील JavaScript कोडचा पुन्हा वापर करून साधन बनवले जाऊ शकते. कार्यसंघांना नवीन सर्व्हर फ्रेमवर्क शिकण्याची किंवा प्रॉक्सी क्लायंटसाठी स्वतंत्र API पृष्ठभाग राखण्याची आवश्यकता नाही.
लूपमधील माणसे डिझाइननुसार असतात, विचार न करता
एक महत्त्वपूर्ण वास्तुशास्त्रीय निर्णय आहे जो WebMCP ला पूर्णपणे स्वतंत्र प्रॉक्सी मॉडेलपासून वेगळे करतो ज्याने अलीकडील मथळ्यांवर प्रभुत्व मिळवले आहे. मानक स्पष्टपणे सहयोगी, मानवी वर्कफ्लोच्या आसपास डिझाइन केलेले आहे – पर्यवेक्षित ऑटोमेशन नाही.
खुशाल सागर, क्रोममधील कर्मचारी सॉफ्टवेअर अभियंता यांच्या मते, WebMCP तपशील या तत्त्वज्ञानाचे समर्थन करणारे तीन स्तंभ परिभाषित करतात.
-
संदर्भ: सर्व डेटा एजंटना वापरकर्ता काय करत आहे हे समजून घेणे आवश्यक आहे, ज्यामध्ये सध्या स्क्रीनवर दृश्यमान नसलेल्या सामग्रीचा समावेश आहे.
-
क्षमता: एजंट वापरकर्त्याच्या वतीने प्रश्नांची उत्तरे देण्यापासून फॉर्म भरण्यापर्यंतच्या कृती करू शकतो.
-
समन्वय: जेव्हा एजंटला स्वतंत्रपणे सोडवता येत नसलेल्या परिस्थितीचा सामना करावा लागतो तेव्हा वापरकर्ता आणि एजंट यांच्यातील हँडओव्हर प्रक्रियेवर नियंत्रण ठेवणे.
Google आणि Microsoft मधील विशिष्ट लेखक हे एका खरेदीच्या परिस्थितीसह स्पष्ट करतात: माया नावाच्या वापरकर्त्याने तिच्या AI सहाय्यकाला लग्नासाठी पर्यावरणास अनुकूल ड्रेस शोधण्यात मदतीसाठी विचारले. एजंट विक्रेत्यांना सुचवतो, कपड्याच्या साइटवर ब्राउझर उघडतो आणि हे पृष्ठ WebMCP टूल्स जसे की getDresses() आणि showDresses() प्रदर्शित करतो हे कळते. जेव्हा मायाचे पॅरामीटर्स साइटच्या मूलभूत फिल्टरपेक्षा जास्त असतात, तेव्हा एजंट उत्पादन डेटा आणण्यासाठी त्या साधनांना कॉल करतो आणि फिल्टर करण्यासाठी स्वतःचे तर्कशास्त्र वापरतो "योग्य कॉकटेल पोशाख," ते नंतर फक्त संबंधित परिणामांसह पृष्ठ अद्यतनित करण्यासाठी showDresses() ला कॉल करते. हे मानवी चव आणि एजंट क्षमतांचे एक प्रवाही लूप आहे, जे WebMCP सक्षम करण्यासाठी डिझाइन केलेले सहयोगी ब्राउझिंगचे नेमके प्रकार आहे.
हेडलेस ब्राउझिंगसाठी हे मानक नाही. द स्पेसिफिकेशन स्पष्टपणे नमूद करते हेडलेस आणि पूर्णपणे स्वायत्त परिस्थिती ही उद्दिष्टे नाहीत. या वापर प्रकरणांसाठी, लेखक Google च्या एजंट-टू-एजंट (A2A) प्रोटोकॉलसारख्या विद्यमान प्रोटोकॉलकडे निर्देश करतात. WebMCP हे ब्राउझर बद्दल आहे – जिथे वापरकर्ता उपस्थित असतो, पाहतो आणि सहयोग करतो.
हा MCP चा पर्याय नाही तर त्याला पूरक आहे
संकल्पनात्मक वंश आणि त्याच्या नावाचा भाग सामायिक करूनही WebMCP हे अँथ्रोपिकच्या मॉडेल कॉन्टेक्स्ट प्रोटोकॉलची जागा नाही. MCP क्लायंट सर्व्हरशी संवाद साधण्यासाठी वापरत असलेल्या JSON-RPC तपशीलाचे पालन करत नाही. जेथे MCP बॅक-एंड प्रोटोकॉल म्हणून AI प्लॅटफॉर्मला सेवा प्रदात्यांना होस्ट केलेल्या सर्व्हरद्वारे जोडते, तेथे WebMCP ब्राउझरमध्ये पूर्णपणे क्लायंट-साइड ऑपरेट करते.
नाते एकात्म आहे. ट्रॅव्हल कंपनी चॅटजीपीटी किंवा क्लॉड सारख्या AI प्लॅटफॉर्मसह थेट API एकत्रीकरणासाठी बॅक-एंड MCP सर्व्हर राखू शकते, त्याच वेळी ग्राहकांच्या वेबसाइटवर WebMCP टूल्सची अंमलबजावणी करते जेणेकरून ब्राउझर-आधारित एजंट वापरकर्त्याच्या सक्रिय सत्राच्या संदर्भात त्याच्या बुकिंग प्रवाहाशी संवाद साधू शकतील. दोन मानके संघर्षाशिवाय भिन्न परस्परसंवाद शैली देतात.
प्रकल्प अभियंत्यांसाठी हा फरक महत्त्वाचा आहे. बॅक-एंड MCP एकत्रीकरण सेवा-टू-सेवा ऑटोमेशनसाठी योग्य आहे जेथे ब्राउझर UI ची आवश्यकता नाही. जेव्हा वापरकर्ता उपस्थित असतो तेव्हा WebMCP योग्य असते आणि सामायिक व्हिज्युअल संदर्भातील परस्परसंवादाचा फायदा होतो – जे बहुसंख्य ग्राहक-मुखी वेब परस्परसंवादांचे वर्णन करते ज्यांची संस्था काळजी घेते.
पुढे काय येते: विज्ञानापासून मानकापर्यंत
WebMCP सध्या Chrome 146 Canary मागे उपलब्ध आहे "चाचणीसाठी WebMCP" chrome://flags वर ध्वजांकित करा. विकासक सामील होऊ शकतात Chrome अर्ली पूर्वावलोकन कार्यक्रम दस्तऐवजीकरण आणि डेमोमध्ये प्रवेश करण्यासाठी. इतर ब्राउझरने अद्याप अंमलबजावणी टाइमलाइन घोषित करणे बाकी आहे, जरी मायक्रोसॉफ्टचे तपशीलाचे सक्रिय ऑथरिंग सूचित करते की एजला समर्थन मिळण्याची शक्यता आहे.
इंडस्ट्री पर्यवेक्षकांना 2026 च्या मध्य-ते-उशीरापर्यंत अधिकृत ब्राउझर घोषणा अपेक्षित आहेत, ज्यामध्ये Google क्लाउड नेक्स्ट आणि Google I/O हे व्यापक रोलआउट घोषणांसाठी संभाव्य ठिकाणे आहेत. विनिर्देश W3C मधील सामुदायिक उष्मायनापासून औपचारिक मसुद्याकडे जात आहे – एक प्रक्रिया जी ऐतिहासिकदृष्ट्या महिने घेते परंतु गंभीर संस्थात्मक बांधिलकी दर्शवते.
सागरने केलेली तुलना बोधप्रद आहे: WebMCP चे AI एजंट वेबशी संवाद साधण्यासाठी USB-C बनण्याचे उद्दिष्ट आहे. सानुकूल स्क्रॅपिंग स्ट्रॅटेजी आणि ठिसूळ ऑटोमेशन स्क्रिप्ट्सच्या सध्याच्या गुंतागुंतीच्या जागी कोणताही एजंट प्लग करू शकतो असा एक एकीकृत इंटरफेस.
हा दृष्टीकोन साध्य करणे ब्राउझर विक्रेते आणि वेब डेव्हलपर्सद्वारे त्याचा अवलंब करण्यावर अवलंबून आहे. परंतु Google आणि Microsoft च्या सामायिक शिपिंग कोडसह, संस्थात्मक मचान प्रदान करणारे W3C, आणि Chrome 146 आधीच विज्ञानाच्या मागे लागू होत आहे, WebMCP ने कोणत्याही वेब मानकांना तोंड देणारा सर्वात कठीण अडथळा दूर केला आहे: प्रस्तावाकडून कार्यरत कार्यक्रमाकडे जाणे.
