OpenChrome - Chrome ब्राउज़र के लिए parallel automation MCP server
(github.com/shaun0927)Playwright एक उपयोगी web automation tool है, जो तब काम आता है जब आप किसी तरह crawling करना चाहते हों
या production environment में E2E testing करना चाहते हों,
और browser में click जैसी actions को नियंत्रित करना हो।
यह 2020 में रिलीज़ हुआ था,
और आज भी ज़्यादातर developers इसी tool का इस्तेमाल करते हैं।
लेकिन सिर्फ एक session चालू करने पर भी RAM खपत 2GB से ज़्यादा हो जाती है, और यह भारी, धीमा तथा अक्सर टूटने वाला है।
AI के दौर में इस tool में innovation की ज़रूरत है,
खासकर ऐसे browser automation tool की, जो parallel tasks में भी स्थिरता से चल सके।
अब हम न तो खुद QA करना चाहते हैं, न ही साइटों में भटकना।
OpenChrome इसी समस्या को हल करने की इच्छा से शुरू हुआ प्रोजेक्ट है।
यह एक MCP server है जो तेज़, स्मार्ट browser parallel automation हासिल करता है।
हाल के समय में यह मेरे निजी काम में सबसे ज़्यादा इस्तेमाल होने वाले tools में से एक भी है।
यह Chrome browser login का उपयोग करता है,
और अगर आप कई accounts इस्तेमाल करते हैं, तो काम देते समय किस account का उपयोग करना है यह बता सकते हैं।
डिफ़ॉल्ट रूप से यह पहले से login किए हुए Chrome browser के आधार पर काम करता है।
20 से अधिक browsers में parallel काम संभव है, और RAM उपयोग को लगभग 300MB तक घटा दिया गया है। यह Chrome login की स्थिति में काम करता है और व्यावहारिक रूप से Bot detection को पूरी तरह निष्प्रभावी बना देता है। Openclaw के साथ integration भी संभव है.
उपयोग के उदाहरण नीचे दिए गए हैं।
"Twitter के 20 प्रसिद्ध लोगों की नवीनतम posts को oc से crawl करके लाओ।"
(claude code के आधार पर benchmark: 3 मिनट 30 सेकंड — इसमें अधिकांश समय LLM inference में लगता है)
असल में Playwright की पुरानी समस्या है बेकार की "LLM भटकन"।
आप login जैसे काम का निर्देश दें, तब भी यह काफ़ी देर तक साइट में इधर-उधर खोजबीन करता रहता है, अलग-अलग चीज़ें आज़माता है,
और आखिर में 30 मिनट से ज़्यादा समय लेकर विफल होने की सूचना दे देता है।
Openchrome इसे अनुमान-आधारित तरीके से नहीं, बल्कि Guided तरीके से हल करता है।
यह सीधे Chrome में login करता है, और link देने पर तुरंत उसी link पर पहुँच जाता है।
यह screenshots को न्यूनतम रखता है और button जैसी चीज़ों की position तेज़ी से पकड़ लेता है।
अगर काम में समस्या आती है, तो यह पिछली बातों को याद रखकर वही गलती दोहराता नहीं है।
MCP server होने की वजह से इसे मौजूदा Playwright के बदले किसी भी environment में तुरंत इस्तेमाल किया जा सकता है।
MAC-claude code development, Windows, Linux जैसे अन्य operating systems के साथ-साथ
codex cli, cursor आदि में भी यह काम करता है।
इंस्टॉलेशन:
npx openchrome-mcp setup
बहुत जटिल और ज़्यादा resource लेने वाली बड़े पैमाने की production stability के लिए अभी अतिरिक्त verification की ज़रूरत है।
अगर आपके पास feedback या suggestions हों, तो GitHub Issues में पोस्ट करें, मैं उन्हें तुरंत शामिल करूँगा।
धन्यवाद।
13 टिप्पणियां
क्या इसका मतलब है कि मौजूदा E2E solution का उपयोग किए बिना, AI सीधे test code को manage और execute करेगा?
अगर मौजूदा Playwright अपनी संरचित methodology के साथ वेबसाइट तक पहुँचते हुए tokens ज़्यादा खर्च करता था,
तो openchrome को आप ऐसे concept के रूप में समझ सकते हैं जो LLM-friendly तरीके से काम करता है, जिससे LLM सीधे वेबसाइट के व्यवहार के नियंत्रण में तेज़ी से शामिल हो सके। e2e solution को सीधे चलाया जा सकता है।
उदाहरण के लिए, Google login की ज़रूरत वाले production environment में admin account से लॉग-इन की हुई स्थिति में QA काम कराया जा सकता है। स्क्रोल करवाना, edge cases पर अपने-आप क्लिक करवाना वगैरह—आप जो ज़्यादातर काम सोच रहे हैं, वे सब संभव हैं। ऐसा इसलिए है क्योंकि इसमें Playwright को अपने-आप बेवकूफ़ी भरे autonomous काम करने के लिए छोड़ नहीं दिया जाता, बल्कि LLM तुरंत-तुरंत दखल देकर व्यवहार को नियंत्रित करता है।
अगर सिर्फ token usage देखें, तो क्या structured तरीका E2E test cases को LLM के हस्तक्षेप के बिना चलाना है, इसलिए वह और कम नहीं होगा?
Test methodology में TC के अलावा QA द्वारा स्वायत्त रूप से testing करना भी शामिल है,
तो अगर उस हिस्से के बारे में यह माना जाए कि वह efficient है, तो क्या वह ठीक रहेगा?
अगर थोड़ा और तकनीकी जवाब दूँ, तो
मौजूदा Playwright MCP नीचे दिए गए 3-स्तरीय abstraction पर काम करता है:
LLM → MCP server → Playwright Node.js server → CDP/Juggler → browser
वहीं OpenChrome नीचे दिए गए 1-स्तरीय abstraction पर काम करता है:
LLM → MCP server → CDP → browser
abstraction layer जितनी कम हों, उतनी ही speed बेहतर होती है और control अधिक सटीक होता है.
Playwright एक general-purpose tool है, जबकि OpenChrome specialized tool का उपयोग करता है.
अगर इसे गणित के सवाल से तुलना करें, तो 20 पंक्तियों वाले समाधान को 4 पंक्तियों में संक्षिप्त कर देने जैसा समझ सकते हैं.
Playwright accessibility tree नाम की text-based विधि से feedback लेता है,
(सिद्धांत रूप में यह बेहतर है, लेकिन ज़्यादातर साइटों पर इसके टूटने की यही वजह है)
इसलिए context समझने की इसकी क्षमता काफी सीमित रहती है.
इसलिए जिन साइटों में accessibility अच्छी तरह implement की गई है (जैसे Google जैसे प्रसिद्ध domain), वहाँ Playwright अब भी उपयोगी है,
लेकिन अधिकांश साइटों या production में OpenChrome कहीं बेहतर है.
साथ ही, "tool design की density" और "LLM के गलती करने के अवसरों को कम करना" ही आखिरकार वास्तविक प्रदर्शन तय करते हैं,
इसलिए मुझे लगता है कि सैद्धांतिक प्रदर्शन नहीं, बल्कि real-world task के आधार पर मापना सही है.
धन्यवाद। लगता है मैंने मूल लेख को पर्याप्त ध्यान से नहीं पढ़ा था।
मैंने इस बात को नज़रअंदाज़ कर दिया कि यह production environment को ध्यान में रखकर बनाया गया था।
मैं भी इसे ज़रूर इस्तेमाल करके देखूँगा।
गलत सवाल का भी धैर्यपूर्वक जवाब देने के लिए धन्यवाद~
नहीं, यह एक अच्छा सवाल है, धन्यवाद। समझाते समय मेरी भी अपनी समझ और साफ़ हो गई।
यह निश्चित रूप से तेज़ और अच्छा है.
लेकिन alert पॉप अप होते ही रुक जाता है.
इस हिस्से को हम जल्दी सुधारेंगे।
Chrome DevTools MCP के साथ तुलना भी जानने की जिज्ञासा है!
जब मैंने इसे इस्तेमाल किया था, तो मुझे याद है कि chrome devtools mcp की तुलना में Playwright ही बेहतर लगा था, लेकिन आगे चलकर मैं benchmark जोड़कर देखूंगा।
chrome devtools mcpमें large context की चेतावनी नहीं आती, लेकिन परफ़ॉर्मेंस काफ़ी मिलती-जुलती लगी थी, इसलिए मैं यही इस्तेमाल कर रहा था! बेंचमार्क के नतीजों का इंतज़ार है :Dओह, क्या token usage भी कम हो जाता है? धन्यवाद!!
आप जितनी कम बेकार की कोशिशें करेंगे, उतना ही token की खपत भी कम होगी।