पहले N टूल को M मॉडल से जोड़ने के लिए N×M एडेप्टर लेयर लिखनी पड़ती थीं। MCP टूल पक्ष और मॉडल पक्ष को अलग करता है, ताकि दोनों को प्रोटोकॉल केवल एक बार लागू करना पड़े। यह लेख उसके डिज़ाइन विकल्प, ब्राउज़र एनवायरनमेंट और पेज ऐक्शन की अमूर्तता, और अब भी अनसुलझे हिस्सों को समझाता है।
जब किसी Agent को वास्तव में काम करना होता है, तो वह अक्सर अंत में ब्राउज़र पर ही आता है: लॉगिन करना, पोस्ट करना, डेटा लेना या फ़ॉर्म भरना। तकनीकी कठिनाई यह नहीं है कि वह क्लिक कर सकता है या नहीं, बल्कि ब्राउज़र को Agent के हवाले करने की इंटीग्रेशन लागत है।
N×M एडेप्टर का जाल
मान लें कि बाज़ार में N टूल और M मॉडल हैं। टूल प्रदाता को हर मॉडल के लिए अलग इंटीग्रेशन कोड लिखना पड़ता है, और मॉडल पक्ष को हर टूल के लिए अलग एडेप्टर लेयर बनानी पड़ती है। दोनों पक्ष अपनी-अपनी परतों का रखरखाव करते हैं, इसलिए कुल संख्या N×M हो जाती है।
समस्या यह है कि यह गुणा है। एक नया टूल जोड़ना केवल एक अतिरिक्त काम नहीं है; उस टूल को हर मॉडल से अलग-अलग जोड़ना पड़ता है। उल्टा, मॉडल का संस्करण बदलने पर पहले से जुड़े टूल को भी दोबारा सत्यापित करना पड़ सकता है। कोई क्षमता कितनी भी अच्छी हो, किसी खास मॉडल के लिए एडेप्टर न हो तो उसका उपयोग नहीं हो सकता—टूल वितरण की कड़ी में अटक जाता है।
शुरुआत में सभी को अपना-अपना इंटीग्रेशन लिखना पड़ता था। वही काम—एनवायरनमेंट की सूची बनाना, ब्राउज़र शुरू करना, पेज पढ़ना—कॉलर बदलते ही फिर से लिखना पड़ता था, और लॉजिक भी अक्सर अलग होता था: कोई प्रतीक्षा क्लाइंट में रखता था, कोई सर्वर में।
प्रोटोकॉल दोनों पक्षों को अलग करता है
MCP (Model Context Protocol) 2024 के अंत में सार्वजनिक हुआ। इसका तरीका टूल खोज और टूल कॉल को मानक फ़ॉर्मेट में परिभाषित करना है: क्या उपलब्ध कराया जाए, पैरामीटर कैसे बताए जाएँ और किस संरचना में परिणाम लौटे—ये सब प्रोटोकॉल में तय होते हैं।
आर्किटेक्चर फिर ऐसा हो जाता है कि Agent एक MCP Client से जुड़ता है, Client प्रोटोकॉल के अनुसार कई MCP Server से जुड़ता है, और असली क्षमताएँ Server के पीछे रहती हैं। इम्प्लीमेंटेशन की मात्रा N×M से घटकर N+M हो जाती है: मॉडल पक्ष क्लाइंट एक बार बनाता है और टूल पक्ष सर्वर एक बार।
भूमिकाएँ केवल तीन हैं। Host वह एप्लिकेशन है जिसमें मॉडल चलता है और जो क्लाइंट शुरू करता है। Client प्रोटोकॉल क्लाइंट का इम्प्लीमेंटेशन है, आम तौर पर हर Server के लिए एक। Server टूल प्रदाता लिखता है और क्षमताओं को मानकीकृत टूल के रूप में उपलब्ध कराता है।
फिलहाल संचार के दो तरीके हैं। लोकल मोड मानक इनपुट और आउटपुट का उपयोग करता है, जहाँ क्लाइंट और सर्वर एक ही मशीन पर होते हैं; रास्ता छोटा और कॉन्फ़िगरेशन कम होने से ऑटोमेशन में यह आम है। रिमोट मोड HTTP या WebSocket का उपयोग करता है और वितरित डिप्लॉयमेंट के लिए उपयुक्त है, लेकिन इसमें प्रमाणीकरण और नेटवर्क सीमाओं पर अलग से ध्यान देना पड़ता है।
ब्राउज़र में तीन परतें उपलब्ध होती हैं
ब्राउज़र एनवायरनमेंट को प्रोटोकॉल से जोड़ने पर उपलब्ध क्षमताएँ मोटे तौर पर तीन परतों में आती हैं।
सबसे ऊपर एनवायरनमेंट है: खाते के एनवायरनमेंट की सूची बनाना, कॉन्फ़िगरेशन के आधार पर नया बनाना, किसी खास एनवायरनमेंट को शुरू करना, नेटवर्क egress जोड़ना और काम पूरा होने पर बंद करना। पहले ये काम अलग-अलग विक्रेताओं की API में बिखरे रहते थे; अब ये ऐसे टूल बन जाते हैं जिन्हें मॉडल खोज और कॉल कर सकता है। शुरू करने के बाद आम तौर पर कोई डिबगिंग endpoint लौटता है, जैसे पोर्ट या WebSocket address, जिसे Selenium या Puppeteer जैसे ड्राइवर को दिया जा सकता है।
बीच की परत पेज है: पता खोलना, DOM या accessibility tree पढ़ना, टैब बदलना और स्क्रीनशॉट लेना।
सबसे नीचे ऐक्शन हैं: क्लिक करना, टाइप करना, स्क्रॉल करना, किसी शर्त के पूरा होने तक प्रतीक्षा करना और पॉप-अप संभालना।
मुख्य बदलाव ऐक्शन की संख्या में नहीं है। एनवायरनमेंट ऐसी कोड इकाई से बदलकर ऐसा संसाधन बन जाता है जिसे Agent खुद चुन और उपयोग कर सकता है। आपको केवल लक्ष्य स्पष्ट करना होता है; Agent तय कर सकता है कि नया एनवायरनमेंट बनाए या मौजूदा का पुनः उपयोग करे, और टूल किस क्रम में कॉल करे। कई एनवायरनमेंट समानांतर चलने पर यह और स्पष्ट होता है: शेड्यूलिंग स्क्रिप्ट में hard-code होने के बजाय prompt में रहती है।
जो अभी भी हल नहीं हुआ है
प्रोटोकॉल कनेक्शन की समस्या हल करता है, शुद्धता की नहीं। कुछ बातें आसानी से नज़रअंदाज़ हो सकती हैं।
टूल विवरण की गुणवत्ता कॉल के परिणाम तय करती है। पैरामीटर गलत हों या गलत टूल चुना जाए, तो प्रोटोकॉल मदद नहीं कर सकता। टूल बढ़ने पर उनके विवरण भी context लेते हैं, इसलिए संख्या और granularity के बीच संतुलन चाहिए। granularity बहुत मोटी हो तो मॉडल को पता नहीं चलता कि एक टूल कितने काम कर सकता है; बहुत बारीक हो तो context पहले भर जाता है।
अनुमतियाँ और ऑडिट अभी शुरुआती चरण में हैं। कई Server लोकल, single-machine रूप में चलते हैं, शुरू होते ही पर्याप्त अधिकार रखते हैं और उनमें fine-grained authorization तथा call records की कमी होती है। रिमोट मोड में पहले तय करना पड़ता है कि कौन जुड़ सकता है और क्या देख सकता है।
पेज की अस्थिरता भी खत्म नहीं होती। एलिमेंट न मिलना, लोडिंग का अनिश्चित क्रम, लॉगिन सेशन का समाप्त होना और CAPTCHA जैसी स्थितियों में अब भी प्रतीक्षा, पुनः प्रयास और fallback logic चाहिए। प्रोटोकॉल केवल प्रवेश बिंदु को मानकीकृत करता है।
इकोसिस्टम की परिपक्वता भी समान नहीं है। अलग-अलग Server के supported resource types, return structures और error codes पूरी तरह एक जैसे नहीं हैं। कई Server जोड़कर एक task बनाने पर orchestration logic अक्सर अभी भी खुद लिखना पड़ता है। प्रोटोकॉल भी लगातार विकसित हो रहा है, इसलिए versions के व्यवहार में अंतर पर ध्यान देना जरूरी है।
एक और सीमा स्पष्ट रहनी चाहिए: प्रोटोकॉल यह तय करता है कि मॉडल टूल कैसे कॉल करता है, यह नहीं कि task स्वयं नियमों के अनुरूप है या नहीं। डेटा संग्रह अधिकृत है या नहीं, खाते का उपयोग वैध उद्देश्य के लिए है या नहीं, और प्लेटफ़ॉर्म नियमों का उल्लंघन हो रहा है या नहीं—ये स्वतंत्र निर्णय हैं और कनेक्शन कितनी आसानी से चलता है, उससे अलग हैं।
कई एनवायरनमेंट वाले परिदृश्यों में उनके बीच isolation और network egress, timezone तथा language settings का समन्वय अक्सर इंटीग्रेशन के तरीके से अधिक परिणामों को प्रभावित करता है। environment-isolation layer पर PurpleMark ऐसे interface देता है जिनसे AI टूल एनवायरनमेंट बना, शुरू और नेटवर्क कॉन्फ़िगर कर सकते हैं, और एक ही client से scheduling की जा सकती है।
यह सामग्री केवल तकनीकी सिद्धांत समझाने के लिए है। संबंधित प्रोटोकॉल और टूल का उपयोग लागू कानूनों और नियमों के अनुसार करें।
