जब ब्राउज़र ऑपरेशन MCP को सौंप दिए जाते हैं, तो वर्कफ़्लो कैसे बदलता है और कोड से कौन-से हिस्से हट जाते हैं? यह व्यावहारिक लेख जिम्मेदारियों के बँटवारे, चार आम कॉन्फ़िगरेशन समस्याओं और उन्हें जाँचने के क्रम को समझाता है।
ब्राउज़र ऑटोमेशन के लिए Claude Code इस्तेमाल करते समय सबसे पहले glue code परेशान करता है: ब्राउज़र शुरू करना, proxy जोड़ना, environment बनाना और handles का इंतज़ार करना। इनका business logic से सीधा संबंध नहीं है, फिर भी इन्हें बार-बार लिखना पड़ता है। जब ब्राउज़र ऑपरेशन MCP के जरिए बाहर सौंप दिए जाते हैं, तो यह हिस्सा लगभग कोड से गायब हो जाता है। आप बताते हैं कि क्या करना है और मॉडल तय करता है कि कौन-सा tool चलाना है।
दोनों की जिम्मेदारियाँ कैसे बाँटें
Claude Code command line में काम करने वाला coding assistant है। यह files पढ़ और लिख सकता है, commands चला सकता है और Git के साथ काम कर सकता है। इसकी ताकत code और terminal वाले हिस्से में है। सीधे browser चलाना इसका मजबूत पक्ष नहीं है और यह जिम्मेदारी भी इसकी नहीं होनी चाहिए।
MCP इसी कमी को पूरा करता है। यह browser automation environment की क्षमताओं को tools के एक समूह के रूप में पैक करता है, जिन्हें register करने के बाद मॉडल चला सकता है: environments की सूची देखना, environment बनाना, browser शुरू या बंद करना, screenshot लेना और page content पढ़ना। एक तरफ code और logs संभाले जाते हैं, दूसरी तरफ browser और pages। जिम्मेदारियाँ साफ हों तो समस्या का स्रोत ढूँढना भी आसान होता है।
वर्कफ़्लो कैसे बदलता है
सबसे बड़ा बदलाव यह है कि पूरी chain जल्दी तैयार हो जाती है। पहले flow में बदलाव के लिए script बदलनी पड़ती थी। अब पहले natural language में परीक्षण किया जा सकता है: उपलब्ध environments की सूची दिखाओ, उनमें से दो में login करके screenshot लो और परिणामों का सार बनाओ। जब flow सही चलने लगे, तब उसे स्थायी script में बदला जा सकता है।
वास्तविक projects में आम तौर पर तीन layers साथ काम करती हैं। MCP natural-language instructions संभालता है और exploration व अस्थायी tasks के लिए उपयुक्त है। Local HTTP API bulk actions संभालती है, जैसे एक बार में दर्जनों environments बनाना; यह स्थिर रहती है और retry करना आसान होता है। अधिक सूक्ष्म interaction, जैसे किसी खास state का इंतज़ार करना या page से structured data निकालना, CDP के जरिए browser से सीधे जोड़कर किया जा सकता है। ये तीनों एक-दूसरे के विरोधी नहीं हैं; हर एक workflow के अलग हिस्से को संभालता है।
Environment layer को अलग से संभालना भी इसी चरण में स्पष्ट हुआ। जब environments अलग-अलग scripts में बिखरे हों, तो tasks बढ़ने पर troubleshooting बहुत कठिन हो जाती है। अब environment-level tools से environments को केंद्रीकृत रूप से बनाया, देखा और batch में reclaim किया जाता है, जबकि script को केवल एक environment ID मिलता है। Multi-account स्थिति में PurpleMark जैसी isolation solution इसी layer की जिम्मेदारी लेती है: हर account का environment, session और cache अलग रखती है ताकि execution layer उन्हें ठीक से schedule कर सके।
चार जगहें जहाँ अक्सर समस्या आती है
पहली समस्या है tool का पहचाना न जाना। अधिकतर clients configuration को केवल startup पर पढ़ते हैं, इसलिए register करने के बाद restart न किया जाए तो बदलाव लागू नहीं होता। Configuration file का गलत path भी आम है क्योंकि अलग tools इसे अलग जगह रखते हैं। जाँच का एक सरल तरीका है: service को manually शुरू करें। अगर वह शुरू हो जाती है तो समस्या configuration में है; अगर नहीं, तो environment में।
दूसरी समस्या authentication failure है। सबसे आम कारण यह है कि credentials copy करते समय extra space या newline भी आ गया हो। पहले इसे जाँचें, फिर देखें कि environment variables कैसे पढ़े जा रहे हैं। अलग operating systems और launch methods में परिणाम अलग हो सकते हैं।
तीसरी समस्या local API का न चलना है। कई MCP services इस पर निर्भर करती हैं कि client application खुद चल रही हो। Client बंद हो तो service शुरू नहीं होती या connection timeout हो सकता है। Port usage भी जाँचें; पुराना process ठीक से बंद न हुआ हो तो port उसी के पास रह सकता है। Port number client settings में देखा जा सकता है।
चौथी समस्या concurrent tasks का एक-दूसरे में हस्तक्षेप करना है। एक task अकेले सही चलता है, लेकिन कई साथ चलें तो data mix हो सकता है या login sessions एक-दूसरे को overwrite कर सकती हैं। आम तौर पर इसका कारण कई tasks का एक ही environment साझा करना होता है। यह debugging से ठीक नहीं होता; इसके लिए नियम चाहिए: हर task के लिए अलग environment, और environment creation व reclaim batch API से हो, script के भीतर ad hoc तरीके से नहीं।
डिबगिंग की कुछ आदतें
Instructions में waiting condition साफ लिखें। “Submit button पर click करो” पर्याप्त जानकारी नहीं देता। “Submit button clickable होने तक इंतज़ार करो, फिर click करो” अधिक भरोसेमंद रहता है। क्या करना है यह मॉडल तय कर सकता है, लेकिन कब इंतज़ार करना है यह आपको बताना होगा।
Chain की जाँच read-only tasks से शुरू करें। Environments की सूची देखना, screenshot लेना और page text पढ़ना side effects नहीं पैदा करते, लेकिन authentication, network और service तीनों की जाँच एक साथ हो जाती है। जब तक chain सही न चले, side effects वाले operations न चलाएँ।
Credentials को code में न लिखें। Environment variables या local configuration files इस्तेमाल करें और उन files को ignore list में जोड़ें; team membership बदलने पर credentials rotate करें। अगर local API ने अपनी validation बंद कर रखी है, तो कम से कम यह सुनिश्चित करें कि वह केवल local machine पर listen करे और बाहर से access न हो सके।
आखिरी सीमा यह है: MCP technical chain को जोड़ता है, platform के नियम नहीं बदलता। Integration कितना भी सुचारु हो, task पर लागू सभी terms of service का पालन फिर भी करना होगा।
