AI ब्राउज़र ऑटोमेशन के लिए "MCP-B प्रोटोकॉल"

• MCP-B : ब्राउज़र-नेटिव AI ऑटोमेशन प्रोटोकॉल
• पारंपरिक स्क्रीन कैप्चर और क्लिक-आधारित तरीके के बजाय, वेबसाइट के API तक सीधे पहुंचकर AI को 1,000 गुना तेज़ और अधिक सटीक ऑटोमेशन करने में सक्षम बनाने वाला ब्राउज़र कॉन्टेक्स्ट प्रोटोकॉल
• लगभग 50 लाइनों के कोड जोड़ने भर से, अलग OAuth, API key या जटिल सेटअप के बिना साइट के अंदर मौजूद authentication जानकारी के साथ तुरंत AI इंटीग्रेशन संभव
• ब्राउज़र सेशन और मौजूदा authentication system का उपयोग करके, नए authentication या permission सेटिंग्स के बिना तुरंत काम करता है, और हर web app की API security policy का पूरा सम्मान करता है
• एक्सटेंशन के जरिए AI assistant कई tabs और apps के बीच जाकर सीधे data query और tasks execute कर सकता है, जिससे मौजूदा ऑटोमेशन की तुलना में performance (कुछ ms में execution) और reliability में भारी सुधार होता है
• Structured API access होने के कारण UI बदलाव, screenshot errors और जटिल selector management जैसी समस्याओं से मुक्ति मिलती है। इंस्टॉल और उपयोग दोनों बहुत सरल हैं

---

MCP-B अवलोकन

• MCP-B(Machine Context Protocol for Browsers) ब्राउज़र के लिए एक model context protocol है, जो AI-आधारित terminal automation जैसी शैली में ब्राउज़र environment को control और interact करने के लिए एक standard प्रदान करता है
• यह प्रोटोकॉल ब्राउज़र और AI engine के बीच communication को स्पष्ट रूप से परिभाषित करता है, जिससे विभिन्न automation और model interactions को structured बनाया जाता है

मौजूदा तरीकों से अंतर

• पारंपरिक ब्राउज़र ऑटोमेशन: screenshot analysis, element click, UI बदलावों के प्रति संवेदनशील, धीमा और अस्थिर (प्रति task 10~20 सेकंड, $4~5 लागत)
• मौजूदा MCP तरीका: API key और जटिल authentication की जरूरत, शुरुआती setup का barrier ऊंचा
• MCP-B: ब्राउज़र सेशन का उपयोग, API तक सीधी पहुंच, जटिल authentication या सेटिंग्स के बिना तुरंत काम

मुख्य सिद्धांत और संरचना

• Tab-आधारित MCP server: हर web app अपना TypeScript-आधारित MCP server चलाता है (in-memory transport, मौजूदा cookie/JWT authentication का पुन: उपयोग)
• MCP-B extension: Chrome/Edge/Firefox extension (content script, tab server के साथ postMessage से communication), सभी tabs के tools और APIs को एक जगह इंटीग्रेट करता है
• AI assistant integration: Native Bridge और विभिन्न clients (Claude Desktop, Cursor IDE आदि) में MCP-B के जरिए ब्राउज़र ऑटोमेशन संभव

उपयोग और डिप्लॉयमेंट का तरीका

• डेवलपर्स: 1) package install 2) MCP server code जोड़ना 3) deployment पूरा → अलग API key, OAuth या जटिल सेटअप की जरूरत नहीं
• यूज़र: extension install करने के बाद तुरंत उपयोग, सिर्फ AI settings से तत्काल ऑटोमेशन

वास्तविक फायदे

• Authentication: मौजूदा वेबसाइट login और session information का सीधा उपयोग, OAuth 2.1/अलग authentication की जरूरत नहीं
• Performance: direct API calls से ms-स्तर पर tasks पूरे (मौजूदा तरीकों की तुलना में 10,000 गुना सुधार)
• Security: application के अंदर काम करता है, और मौजूदा access control व permission policies का पूरा पालन करता है
• Scalability: कई web apps, tabs और AI tools को MCP-B के जरिए एकीकृत रूप से मैनेज किया जा सकता है
• Setup: लगभग 50 लाइनों के कोड से ऑटोमेशन के लिए तैयारी पूरी

तुलना सारांश

तरीका	authentication और सेटअप	काम करने का तरीका	performance और reliability
मौजूदा ऑटोमेशन	जटिल authentication, API key	स्क्रीन स्क्रैपिंग, क्लिक	धीमा और अस्थिर (10~20 सेकंड)
मौजूदा MCP	API key, OAuth की जरूरत	API access	शुरुआती barrier ऊंचा
MCP-B	कोई सेटअप नहीं, ब्राउज़र सेशन का उपयोग	direct API call	ms-स्तर, बहुत तेज़/स्थिर

निष्कर्ष: अगली पीढ़ी का ब्राउज़र-आधारित AI ऑटोमेशन

• MCP-B ब्राउज़र environment के लिए optimized AI automation protocol है, जो authentication, security, scalability और performance हर पहलू में अभिनव है
• अतिरिक्त authentication या जटिल सेटअप के बिना, सिर्फ ब्राउज़र-आधारित direct API calls से बड़े पैमाने पर AI ऑटोमेशन लागू किया जा सकता है
• MIT license, community-केंद्रित, सभी प्रमुख ब्राउज़रों का समर्थन

[shindalsoo]

MCP-B तकनीक का मुख्य विज़न कुछ इस तरह समझा जा सकता है।
"Chrome extension नाम के एक विश्वसनीय माध्यम के जरिए, browser पहले से सुरक्षित रूप से प्रबंधित कर रहा user information (cookie, session, authentication आदि) का उपयोग करके,
web page पर developer द्वारा पहले से परिभाषित किए गए 'tools' को AI chat window से natural language commands के जरिए कॉल और नियंत्रित किया जाएगा।"

लेकिन मुझे लगता है कि "इसके फैलने की गुंजाइश कम दिखती है", और इसके कारण मुझे इस प्रकार लगते हैं।

1. उपयोगकर्ता प्रतिरोध: यह सबसे बड़ी बाधा है। उपयोगकर्ताओं में अपनी browser information तक पहुंच रखने वाले extension को install करने को लेकर स्वाभाविक हिचकिचाहट और security concerns होते हैं। अगर यह तकनीक देने वाली सुविधा उन चिंताओं से कहीं अधिक प्रभावशाली न हो, तो उपयोगकर्ता installation को लेकर हिचकिचाएंगे।
2. web developers पर बोझ: वेबसाइट developers को मौजूदा API बनाने के अलावा MCP-B के लिए अलग से 'tools' परिभाषित और प्रबंधित करने का अतिरिक्त बोझ उठाना होगा। यदि इस तकनीक के व्यापक adoption से मिलने वाला लाभ बड़ा नहीं है, तो developers शायद यूं ही दोगुना प्रयास नहीं करना चाहेंगे।
3. security issues में जिम्मेदारी का सवाल: यदि इस तकनीक के जरिए कोई security incident होता है, तो जिम्मेदारी वेबसाइट developer की है, extension developer की है, या AI model provider की है—यह अस्पष्ट हो सकता है। ऐसी जटिलता कंपनियों को इस तकनीक को अपनाने से हतोत्साहित करती है।
4. केंद्रीकृत platform का अभाव: फिलहाल ऐसा कोई standardized directory या platform नहीं है जो बताए कि "कौन-सी वेबसाइट कौन-से tools प्रदान करती है"। उपयोगकर्ताओं के लिए वेबसाइट पर जाने से पहले यह जानना मुश्किल है कि वे कौन-सी AI capabilities इस्तेमाल कर सकते हैं।

निष्कर्षतः,
MCP-B का विचार अपने आप में तकनीकी रूप से बहुत रोचक और innovative है, लेकिन यह शायद उपयोगकर्ताओं और developers दोनों को इस बुनियादी सवाल का स्पष्ट जवाब नहीं दे पाता: "आखिर यह तरीका ही क्यों इस्तेमाल किया जाए?" मौजूदा API तरीके की तुलना में मिलने वाले फायदे स्पष्ट नहीं हैं, जबकि security concerns और development complexity जैसे नुकसान साफ दिखाई देते हैं।

इसलिए फिलहाल यह तकनीक कुछ उत्साही लोगों या विशेष उद्देश्य वाले developers के बीच प्रयोगात्मक रूप से इस्तेमाल हो सकती है, लेकिन पूरे web ecosystem में व्यापक रूप से फैलने के लिए इसके सामने काफी मुश्किलें दिखती हैं।

[GN⁺]

Hacker News टिप्पणियाँ

• अनुमान: यह RSS जैसी ही राह पर चलेगा। कंपनियाँ आम तौर पर यह पसंद नहीं करतीं कि यूज़र खुद नियंत्रित करें कि उनके डेटा का उपयोग कैसे हो

  • REST API के साथ भी यही हुआ। एक समय 'API-first' डिज़ाइन के दौर में उम्मीद थी कि यह service automation और integration का भविष्य होगा। लेकिन बिज़नेस ने जल्दी समझ लिया कि ऐसी क्षमता देना उनके revenue model के लिए ख़तरा है, इसलिए दिशा जल्दी बदल गई। आखिरकार उन्हें फिर याद आया कि सारा पैसा इसी में है कि यूज़र के पास ऐसी शक्तियाँ न हों

  • मुझे नहीं लगता कि RSS असफल हुआ; बल्कि यह बहुत बड़ी सफलता थी। Google Reader के बंद होने के बाद भी दूसरे reader पर जाकर 20 साल से ज़्यादा समय से RSS feeds बिना किसी समस्या के बढ़िया चल रही हैं। बहुत कम साइटें मिली हैं जो RSS support नहीं करतीं

  • ज़्यादातर वेबसाइटें अब भी RSS support करती हैं, और कुछ में तो page पर दिखे बिना भी feed default रूप से मौजूद होती है। भले ही कुछ साइटें पूरा article न दें, फिर भी update notification या automation trigger के रूप में इसकी काफ़ी value है। RSS अब भी बहुत उपयोगी और जीवित है, लगभग microwave जैसी चीज़—बस होती ही है

  • बाज़ार की संरचना बदल गई है और अब बड़ी कंपनियाँ content से ज़्यादा 'intelligence layer' पर ध्यान दे रही हैं। content धीरे-धीरे commodity बनता जा रहा है। Google को ads बेचते रहने के लिए यूज़र की नज़र, उनका attention, और उन्हें बाँधने वाली smart technology अपने पास रखनी होती है। Google RSS नहीं चाहता था क्योंकि RSS, Google Search को bypass कर सकता था

  • जब AI में इंसानों की तरह click और scroll करने की क्षमता आ जाएगी, तब एक और endless competition शुरू होगा

• Github project का contribution history काफ़ी दिलचस्प है (सीधे link का हवाला दिया गया)। MiguelsPizza ने 3 commits किए, Claude ने 2, लेकिन Claude के code changes लगभग हावी करने वाले हैं

  • extension को अस्थायी रूप से private करने और git history को adjust करने की वजह से वास्तविक history से थोड़ा फर्क है। फिर भी यह सच है कि कुल code का लगभग 85% Claude ने लिखा

  • आगे चलकर ऐसे pattern (AI द्वारा बहुत बड़े code contributions) और ज़्यादा दिखेंगे

  • Claude का commit graph काफ़ी अनोखा है। ऐसा दिखता है जैसे Claude Code सीधे commit कर रहा हो, लेकिन वास्तव में ऐसा लगभग नहीं होता। claude profile भी देखें

  • असली commit list देखें तो सब कुछ MiguelsPizza / Alex Nahas के नाम से है (link)। कुछ अजीब सा लगता है

• ब्लॉग से उद्धृत हिस्से का ज़िक्र करते हुए MCP की authentication समस्या पर चर्चा की गई। OAuth2.1 लंबी अवधि में ठीक लगती है, लेकिन यूज़र की ओर से काम करने वाले agents के लिए authentication को फिर से नए सिरे से गढ़ना पड़ रहा है। multi-tenant apps में data leakage का जोखिम अब भी अनसुलझा है

  • model के blast radius और जिस data तक उसकी पहुँच है उसे सीमित करना MCP का बड़ा फ़ायदा हो सकता है। multi-tenant apps के client-side API पहले से यूज़र scope तक सीमित होंगे, ऐसी उम्मीद है, इसलिए अगर model को वही दिया जाए तो नुकसान बहुत बड़ा नहीं होगा। Amazon की internal auth system और OAuth2.1 के compatibility issues का भी ज़िक्र है (Amazon में auth अलग है)

  • उत्सुकता है कि क्या OAuth2.1 की कुछ चीज़ें पहले से RFC 8693 के delegation vs. impersonation में कवर होती हैं

  • model आखिरकार उसी scope तक पहुँच सकता है जितनी यूज़र की है, इसलिए मज़बूत security implementation की ज़िम्मेदारी वेबसाइट admin की ही है

  • मुझे नहीं लगता कि OAuth ठीक से लागू न किए गए Amazon का उदाहरण ही मुख्य मुद्दा है। यूज़र permission scope से बाहर backdoor जैसी access बहुत ख़तरनाक है। अगर MCP app की सारी गतिविधियाँ यूज़र access जैसी ही category में log हों, तो compliance से जुड़े कई issues उठ सकते हैं। इस नज़रिए से यह बहुत दिलचस्प है, लेकिन security के लिहाज़ से यह bypass के रूप में समस्या पैदा कर सकता है

• यह विचार रखा गया कि अगर Swagger(OpenAPI) spec public हो और केवल एक generic swagger mcp client हो, तो क्या लगभग यह सब implementation बदला नहीं जा सकता? शायद यूज़र खुद manually authentication session खोल दे। सुझाव था कि अगर Claude prompt/settings से API key अच्छी तरह समझ ले और swagger आधारित API client इस्तेमाल करे, तो क्या वह लगभग वही बात नहीं होगी

  • MCP आने पर सबके दिमाग में सबसे पहले यही तरीका आया था। लेकिन व्यवहार में यह ठीक से काम नहीं करता, क्योंकि tools बहुत ज़्यादा हैं। फिर भी इस क्षेत्र में दिलचस्प कोशिशें जारी हैं

  • prompt में API key न डालने की चेतावनी भी दी गई

  • अगर Claude Code को CLAUDE.md में सिर्फ swagger.json का link दे दिया जाए, तो API testing वाकई बहुत सुविधाजनक हो जाती है

  • इसे ख़ुद आज़माने के लिए प्रोत्साहित किया गया

• ठीक से समझ नहीं आ रहा कि target user कौन है। frontend testing में UI बहुत बदल जाए और test टूट जाएँ, तो वह उल्टा उपयोगी हो सकता है। बाकी automation के लिए तो असली API देना बेहतर लगता है

  • crawlers और VLM से दूध ख़रीदने जैसे काम करने वाले लोग ही वास्तविक यूज़र हैं

• "Home Depot में table बनाने जाना शायद और मुश्किल होगा" वाली उपमा पर सवाल उठाया गया कि Home Depot में तो लकड़ी की भरमार होती है

  • Home Depot में तैयार table भी बिकते हैं

  • Home Depot में बेहतर precision tools ही नहीं, experts भी होते हैं, इसलिए शायद काम और आसान हो जाए

  • मज़ाक में कहा गया कि 'लकड़ी तो है, लेकिन उसे तुम्हें अपनी कल्पना से table बनाना होगा'

  • बताया गया कि इस टिप्पणी के बाद उस वाक्य को संशोधित कर दिया गया

• मैंने MCP ख़ुद इस्तेमाल नहीं किया, लेकिन disabled लोगों के नज़रिए से browser और smartphone automation में accessibility के लिए MCP का बड़ा उपयोग दिखता है। हालाँकि ऐसी तकनीक का दुरुपयोग malicious users कर सकते हैं, इसलिए संदेह है कि major web/app platforms इसे वास्तव में अपनाएँगे या नहीं। जिज्ञासा है कि क्या accessibility सुधार के लिए इसके वास्तविक इस्तेमाल के उदाहरण हैं

  • पूछा गया कि accessibility tools का दुरुपयोग और अधिक ठोस रूप में कैसे किया जा सकता है

• MCP-B के open source होने पर आभार जताया गया। ज़्यादातर काम browser में ही होते हैं, लेकिन MCP की धारणा थोड़ी अलग है क्योंकि इसमें AI client काम करता है। मूल सवाल यह है कि MCP-B, web app के JS API को सीधे LLM server से जोड़कर इस्तेमाल करने से वास्तव में कैसे अलग है। क्या आखिरकार दोनों एक ही चीज़ हैं, या इसके पीछे कोई बड़ा चित्र है

  • जवाब में समझाया गया कि मूल अंतर यह है: MCP-B में वेबसाइट owner को अलग से AI chat feature implement या maintain करने की ज़रूरत नहीं होती; standard protocol के ज़रिए यूज़र अपनी पसंद के model को साइट के अलग-अलग tools से जोड़कर इस्तेमाल कर सकता है

• homepage पढ़कर बात साफ़ नहीं हुई और यह Selenium के browser version जैसा लगा, इसलिए सवाल पूछा गया

  • कुछ हद तक मिलता-जुलता है, लेकिन पूरी तरह अलग है। Playwright या Selenium browser automation frameworks हैं, और Playwright-MCP server में agent automation के लिए Playwright का इस्तेमाल कर सकता है। दूसरी ओर, MCP-B वेबसाइट के अंदर MCP server रखता है, और browser extension या JS injection के ज़रिए MCP-B client चलाता है। Playwright सीधे screen parse करता है, जबकि MCP-B standardized function calling approach है। ब्लॉग के code example देखने की सलाह दी गई

• अनुमान लगाया गया कि जब free LLM users के लिए MCP के ज़रिए browser automation शुरू होगा, तो एक ऐसी दुनिया आएगी जहाँ free models से भी Captcha माँगा जाएगा। समस्या यह है कि Captcha, LLM पर ज़्यादा असरदार नहीं है, इसलिए अंततः ऐसा अजीब robot war युग आ सकता है जिसमें LLMs, automation LLMs की पहुँच रोकने के लिए आपस में लड़ें

  • ऐसी कहानियों का अंत अक्सर इस तरह होता है कि robots समझ जाते हैं कि उनका लक्ष्य एक ही है, और फिर वे सहयोग करने लगते हैं