यह सबसे आम तौर पर चुपचाप गलत होता है। आप सेटअप गाइड का पालन करते हैं, क्लाइंट कॉन्फ़िग में JSON ब्लॉक चिपकाते हैं, फिर शुरू करते हैं, और यह काम करता है: टूल सूची दिखती है, कनेक्शन हरा है। फिर आप कल के ऑर्डर के बारे में पूछते हैं और कुछ उपयोगी नहीं मिलता, और वजह भी स्पष्ट नहीं होती।
वजह यह है कि Shopify दो अलग MCP सर्वर देता है, और आसान वाला आपकी दुकान नहीं देख सकता।
दो सर्वर
Shopify ने अप्रैल 2026 में अपना AI Toolkit ओपन सोर्स किया, जिसमें आधिकारिक MCP सर्वर स्टैक, एजेंट स्किल और Claude Code प्लगइन को एक नेमस्पेस में पैक किया गया। उस नेमस्पेस में दो चीज़ें हैं जिन्हें लोग अक्सर एक मान लेते हैं।
Dev MCP स्थानीय रूप से चलता है, लॉगिन नहीं माँगता, और सहायक को Shopify के डेवलपर दस्तावेज़ तथा API स्कीमा देता है। यह Shopify ऐप लिखने वालों के लिए बना है, और उस काम में सचमुच अच्छा है। यह कल के ऑर्डर नहीं पढ़ेगा और न उत्पाद संपादित करेगा, क्योंकि डिज़ाइन के अनुसार यह कभी सक्रिय स्टोर को छूता ही नहीं।
Admin MCP वास्तविक स्टोर डेटा पर काम करता है, और इसे Admin API टोकन चाहिए। यही टोकन पूरा अंतर है, और सेटअप का पूरा श्रम भी।
यदि आप Shopify पर कुछ बना रहे हैं, तो Dev MCP इंस्टॉल करें और आगे पढ़ना छोड़ दें। यह मुफ़्त और आधिकारिक है, और यह लेख इसकी जगह लेने की कोशिश नहीं कर रहा। यदि आप स्टोर चला रहे हैं और उसके बारे में सवाल पूछना चाहते हैं, तो आपको दूसरा वाला चाहिए।
Admin वाला रास्ता वास्तव में आपसे क्या चाहता है
आप अपने स्टोर एडमिन के भीतर एक कस्टम ऐप बनाते हैं, उसे ज़रूरी Admin API एक्सेस स्कोप देते हैं, और उससे मिले टोकन को रखते हैं। ये तीन ऐसे निर्णय हैं जिन्हें लोग अक्सर गलत लेते हैं।
पहला है स्कोप का विस्तार। बहुत कम अनुमति दें, तो विफलता बाद में कॉल के समय आएगी, चैट जवाब के भीतर प्राधिकरण त्रुटि के रूप में, जिसे समझना कठिन होगा। सब कुछ दे दें, तो आपने ऐसा टोकन बना दिया जो आपका पूरा कैटलॉग दोबारा लिख सकता है और लैपटॉप की कॉन्फ़िग फ़ाइल में पड़ा है।
दूसरा है टोकन कहाँ रहता है। JSON कॉन्फ़िग में सादे टेक्स्ट का टोकन वह डिफ़ॉल्ट तरीका है जो अधिकतर गाइड दिखाती हैं, क्योंकि उसका निर्देश सबसे छोटा होता है। उत्पाद प्रकाशित कर सकने वाले क्रेडेंशियल के लिए आप यह तरीका नहीं चुनेंगे।
तीसरा है रोटेशन। जिस वजह से टोकन बनाए गए थे, वह खत्म होने के बाद भी वे बने रहते हैं। सेटअप में कुछ भी आपको याद नहीं दिलाता।
पढ़ने और लिखने का जोखिम एक जैसा नहीं है
यह पूछना कि पिछले सप्ताह कौन-से SKU बिककर खत्म हुए, पढ़ने की कार्रवाई है। यह कम लागत वाली, पलट सकने योग्य है, और जवाब गलत हो तो आप देखकर आगे बढ़ जाते हैं।
कीमत बदलना, उत्पाद विवरण संपादित करना, बिक्री चैनल पर प्रकाशित करना। ये सभी उस सक्रिय स्टोरफ़्रंट पर होते हैं जहाँ ग्राहक अभी खरीदारी कर रहे हैं। प्रोटोकॉल इस अंतर पर कोई नीति नहीं रखता। MCP टूल और उसके आर्ग्युमेंट बताता है; उसमें "यह कार्रवाई पलटी नहीं जा सकती" की अवधारणा नहीं है।
इसका मतलब है कि मंज़ूरी का नियंत्रण क्लाइंट में होना चाहिए। यदि आपका क्लाइंट मॉडल के टूल कॉल निकालते ही उन्हें चला देता है, तो गलत समझे गए निर्देश और बदली हुई कीमतों वाले कैटलॉग के बीच केवल मॉडल का उस दिन सही काम करना खड़ा है। यह ऐसा जोखिम नहीं जिसे कोई जानबूझकर चुने; यह सेटअप गाइड से लोगों को मिल जाता है।
हर दूसरे प्लैटफ़ॉर्म पर भी यही ढाँचा
eBay, Etsy और WooCommerce, सभी के लिए अब समुदाय के बनाए MCP सर्वर हैं, और कहानी लगभग वैसी ही दोहराती है: खुद बनाया हुआ टोकन या की जोड़ा, स्कोप का निर्णय, चालू रखने वाली स्थानीय प्रक्रिया, और ऐसा क्लाइंट जिस पर लिखने के लिए भरोसा करना पड़े। चार प्लैटफ़ॉर्म पर बेचने वाला विक्रेता इस रास्ते पर चार छोटी सेवाएँ चलाने और चार क्रेडेंशियल संभालने लगता है, जो वास्तविक काम है लेकिन किसी ने उसे कार्ययोजना में नहीं रखा था।
इसमें Orkas की जगह
Orkas एक MCP क्लाइंट है, इसलिए ऊपर बताया गया हर सर्वर इसके साथ वैसे ही काम करता है जैसे दूसरे क्लाइंट के साथ। यह अपना Shopify Admin कनेक्टर भी देता है, जो व्यापारी के स्वामित्व वाले Dev Dashboard ऐप पर बना है, और इसकी दो बातें मुख्य हैं।
स्कोप की जाँच जुड़ते समय होती है, कॉल विफल होने पर नहीं। Orkas हर ज़रूरी स्कोप जाँचता है: उत्पाद, ऑर्डर, ग्राहक, इन्वेंटरी, स्थान, ड्राफ़्ट ऑर्डर, रिटर्न, छूट, प्रकाशन और लागू ऑर्डर-पूर्ति स्कोप। पूरी बातचीत खर्च करके पता लगाने से पहले ही वह बताता है कि कौन-सा स्कोप गायब है। क्रेडेंशियल कॉन्फ़िग फ़ाइल में पड़े रहने के बजाय आपके अपने डिवाइस पर एन्क्रिप्टेड रहते हैं।
और लिखने की अनुमति का नियंत्रण क्लाइंट में है, प्रॉम्प्ट में नहीं। जो भी कुछ लिखता, मिटाता, खर्च करता या सक्रिय स्टोर को छूता है, वह अनुमति प्रॉम्प्ट से गुजरता है, और अपरिवर्तनीय कार्रवाइयों के लिए सामान्य कार्रवाइयों से अलग मंज़ूरी होती है। यही कैटलॉग eBay, Etsy, Walmart Marketplace, WooCommerce और Amazon Seller Central के साथ चीनी प्लैटफ़ॉर्म को भी कवर करता है, इसलिए हर स्टोरफ़्रंट के साथ चार सेवाओं वाली समस्या दोबारा नहीं आती।
इसके दायरे में क्या नहीं आता
इनमें से कोई बात Orkas को स्टोर प्रबंधन प्रणाली नहीं बनाती। यह आपके लिए इन्वेंटरी नहीं रखता, ऑर्डर नहीं भेजता या कीमतें दोबारा तय नहीं करता; यदि यही चाहिए, तो ERP बनाए रखें। यह उन छोटे-छोटे एकीकरणों के ढेर की जगह लेता है जिन्हें आपको अपनी दुकान से सवाल पूछने और जवाबों पर कार्रवाई करने के लिए जोड़ना पड़ता। कार्रवाई वाले हिस्से में यह इस धारणा की भी जगह लेता है कि मॉडल का उस दिन सही काम करना पर्याप्त सुरक्षा है।