कई पोस्ट में दावा किया गया कि AI एजेंट्स के लिए CLI सस्ता है, और इसके बाद MCP को मरा हुआ घोषित कर दिया गया। यह लेख असली टोकन आँकड़ों, सुरक्षा से जुड़े समझौतों और उन मामलों को समझाता है जिनमें हर तरीका बेहतर साबित होता है, ताकि आप अपने प्रोजेक्ट के लिए सही तरीका चुन सकें।
मार्च 2026 में Perplexity के CTO, Denis Yarats ने कहा कि उनकी कंपनी आंतरिक रूप से MCP से दूर जा रही है और उसकी जगह सादे APIs और कमांड लाइन टूल्स पर निर्भर हो रही है। इस पर एक पोस्ट वायरल हो गई, और कुछ ही दिनों में हर जगह फ़ैसला सुनाई देने लगा: MCP मर चुका है। डेवलपर्स ने ऐसे स्क्रीनशॉट शेयर किए जिनमें टूल्स की सूची उनके कॉन्टेक्स्ट विंडो को खा रही थी, और जवाबों में ऐसे एक-लाइन शेल कमांड भरे थे जो बहुत कम जगह में वही काम कर रहे थे।
फिर कुछ अजीब हुआ। प्रोटोकॉल मरा नहीं। वह नए सर्वर जोड़ता रहा, AI की सबसे बड़ी कंपनियों का समर्थन पाता रहा, और अब Linux Foundation की देखरेख में है। तो सच क्या है?
यह लेख शोर और आँकड़ों को अलग करता है। आप देखेंगे कि MCP वास्तव में क्या करता है, टोकन की शिकायतें कहाँ जायज़ हैं, कोडिंग एजेंट्स को CLI इतना स्वाभाविक क्यों लगता है, और कहाँ टर्मिनल काम ही नहीं कर सकता। बीच में आपके आज काम आने वाली एक निर्णय तालिका है, और PicassoIA के अपने MCP कनेक्टर और REST API के साथ दोनों तरीके आज़माने पर एक छोटा खंड भी।
💡 छोटा जवाब: MCP मरा नहीं है, पर उसे इस्तेमाल करने का आलसी तरीका ज़रूर मर रहा है। शुरू में सौ टूल डेफ़िनिशन लोड करना एक डिज़ाइन की समस्या है, प्रोटोकॉल की नहीं।
हर कोई यही क्यों पूछ रहा है
वह पोस्ट जिसने शुरुआत की
चिंगारी एक छोटे बयान से उठी, जिसका असर लंबा रहा। Perplexity के CTO ने कहा कि कंपनी अपने आंतरिक टूलिंग के लिए MCP छोड़ रही है और सीधे APIs व CLIs की ओर लौट रही है। हफ़्तों के भीतर "MCP is dead" और "MCP vs CLI" जैसे शीर्षकों वाले ब्लॉग पोस्ट आए, और बहस दो खेमों में बँट गई।
इनमें से कोई भी पोस्ट आधिकारिक फ़ैसला नहीं थी। वे राय थीं, और उनमें से कई के पीछे असली बेंचमार्क थे, जो दिखाते थे कि जब एजेंट प्रोटोकॉल सर्वर लोड करने के बजाय कमांड चलाता है, तो टोकन की बड़ी बचत होती है। शिकायतें जायज़ थीं। लेकिन यह दावा कि पूरा प्रोटोकॉल खत्म हो चुका है, सबूतों से कहीं बड़ा था।
जो आँकड़े घूमे, वे चौंकाने वाले थे। एक ब्राउज़र ऑटोमेशन तुलना के अनुसार MCP स्नैपशॉट के ज़रिए एक प्रोडक्ट पेज पढ़ने में लगभग 52,000 टोकन लगे, जबकि कुछ लक्षित कमांड लाइन क्वेरी में लगभग 1,200 टोकन। एक और बेंचमार्क में, जिसमें Microsoft की एडमिन टूल से डिवाइसों की सूची बनाई गई थी, CLI के साथ लगभग 35 गुना कम टोकन दर्ज हुए। ऐसे आँकड़ों को दिशा-सूचक मानें, क्योंकि ये सर्वर, काम और क्लाइंट पर निर्भर करते हैं। लेकिन दिशा पर बहस करना मुश्किल है: फूला हुआ सर्वर महँगा पड़ता है।
आलोचक असल में क्या कहते हैं
गरमागरम राय हटा दें तो चार शिकायतें बचती हैं:
कॉन्टेक्स्ट का फूलना: एजेंट कुछ उपयोगी करने से पहले हर टूल का नाम, विवरण और JSON स्कीमा लोड कर लेता है।
डेटा के चक्कर: बड़े नतीजे मॉडल से होकर गुज़रते हैं, भले ही एजेंट को सिर्फ़ एक फ़ील्ड चाहिए हो।
सेटअप की परेशानी: हर सर्वर को अपना इंस्टॉल, कॉन्फ़िग और क्रेडेंशियल चाहिए।
परिचित बिल्ट-इन तरीका: मॉडलों ने git, curl, grep और docker को अनगिनत उदाहरणों में देखा है, इसलिए वे बिना अतिरिक्त निर्देश के इन्हें सही तरीके से कॉल करते हैं।
हर बिंदु कुछ सेटअप में सच है। इनमें से कोई भी साझा प्रोटोकॉल के विचार की खामी नहीं है।
कॉन्टेक्स्ट मुफ़्त नहीं है। टूल विवरणों पर खर्च हर टोकन ऐसा टोकन है जो आपके कोड, आपके दस्तावेज़ों या बातचीत पर खर्च नहीं हो सकता। लंबे प्रॉम्प्ट हर कॉल पर पैसे भी लेते हैं, और बहुत बड़े कॉन्टेक्स्ट के बीच में दबी बातों को मॉडल अक्सर भूल जाते हैं। इसीलिए टोकन वाली दलील उन लोगों पर सबसे ज़्यादा असर करती है जो दिन भर एजेंट चलाते हैं।
MCP असल में क्या करता है
एक कनेक्टर, दिमाग नहीं
Anthropic ने नवंबर 2024 में Model Context Protocol पेश किया, ताकि AI एप्लिकेशन बाहरी टूल्स और डेटा तक एक साझा तरीके से पहुँच सकें। इसे एजेंट्स के लिए USB-C की तरह समझें। बिना मानक के, हर AI ऐप को हर सेवा के लिए अलग प्लगइन चाहिए, और इंटीग्रेशन की संख्या तेज़ी से बढ़ती है।
क्लाइंट (AI ऐप) स्थानीय पाइप या HTTP के ज़रिए सर्वर (इंटीग्रेशन) से बात करता है। सर्वर टूल्स, रिसोर्सेज़ और प्रॉम्प्ट्स का विज्ञापन करता है, और क्लाइंट मॉडल को इन्हें कॉल करने देता है। पूरा विचार यही है: एक प्लग का आकार, कई डिवाइस।
तीन बिल्डिंग ब्लॉक रोज़मर्रा की ज़रूरतों से मेल खाते हैं। टूल कोई कार्रवाई करता है, जैसे इश्यू बनाना या इमेज जनरेट करना। रिसोर्स पढ़ने योग्य डेटा दिखाता है, जैसे कोई फ़ाइल या डेटाबेस की पंक्ति। प्रॉम्प्ट एक दोबारा इस्तेमाल होने वाला टेम्पलेट है जिसे उपयोगकर्ता चला सकता है, जैसे "इस पull request की समीक्षा करें"। ज़्यादातर असली सर्वर लगभग पूरी तरह टूल्स पर निर्भर हैं, और टोकन लागत भी यहीं जमा होती है।
अब इसका समर्थन कौन करता है
9 दिसंबर 2025 को Anthropic ने MCP को Linux Foundation को दान कर दिया, नए Agentic AI Foundation के संस्थापक प्रोजेक्ट के रूप में। इसे Block और OpenAI के साथ मिलकर स्थापित किया गया, और Google, Microsoft, Amazon Web Services, Cloudflare और Bloomberg का समर्थन मिला। जो प्रोटोकॉल खत्म हो चुके होते हैं, उन्हें आमतौर पर इस तरह का तटस्थ घर और इतने प्रतिस्पर्धियों की एक मेज़ नहीं मिलती।
तो उपयोगी सवाल यह नहीं कि MCP बचेगा या नहीं। सवाल यह है कि लोग उसे कैसे कॉल करें।
टोकन लागत की समस्या
टूल डेफ़िनिशन कॉन्टेक्स्ट खा जाते हैं
यहाँ आलोचकों के पास मज़बूत तर्क है। रिपोर्टों के अनुसार आधिकारिक GitHub MCP सर्वर का टूल विवरण एजेंट के कुछ भी करने से पहले लगभग 50,000 टोकन लेता है। वही वर्कफ़्लो कमांड लाइन के ज़रिए सिखाने वाली एक छोटी स्किल फ़ाइल लगभग 200 टोकन की बताई गई है। यह दो ऑर्डर ऑफ़ मैग्नीट्यूड का फ़र्क है, और यह उस जगह से लिया जाता है जिसकी आपके मॉडल को असली काम के लिए ज़रूरत है।
नतीजे मॉडल से होकर गुज़रते हैं
दूसरी लागत वर्कफ़्लो के बीच में छिपी होती है। अगर कोई एजेंट एक सिस्टम से लंबा ट्रांसक्रिप्ट लेकर दूसरे में चिपकाता है, तो हर शब्द मॉडल से दो बार गुज़रता है। एक घंटे की मीटिंग का ट्रांसक्रिप्ट दस हज़ार या उससे ज़्यादा टोकन का हो सकता है, इसलिए उसे दो बार भेजने का मतलब है उसकी दोगुनी कीमत, जबकि मॉडल को उसे पढ़ने की ज़रूरत ही नहीं थी।
4 नवंबर 2025 की MCP के साथ कोड एक्ज़ीक्यूशन पर अपनी इंजीनियरिंग पोस्ट में Anthropic ने एक Google Drive से Salesforce वर्कफ़्लो का वर्णन किया, जो लगभग 150,000 टोकन से घटकर लगभग 2,000 पर आ गया, यानी लगभग 98.7% की बचत। एजेंट ने टेक्स्ट को कोड के ज़रिए आगे बढ़ाया, इसलिए मॉडल ने सिर्फ़ एक छोटी पुष्टि देखी।
इसे ध्यान से पढ़ें। समाधान तब भी MCP ही था। बस एजेंट ने उसे एक-एक टूल कॉल के बजाय कोड के ज़रिए कॉल किया।
तरीका
शुरुआती कॉन्टेक्स्ट
सबसे अच्छा किसमें
कमज़ोर पक्ष
सीधे MCP टूल कॉल
कई टूल्स के साथ ज़्यादा
छोटे, चुने हुए टूलसेट
फूलना और डेटा के चक्कर
कोड एक्ज़ीक्यूशन के साथ MCP
कम
बड़े डेटासेट, कई चरण
सैंडबॉक्स चाहिए
शेल में CLI
लगभग शून्य
डेवलपर टूलिंग
टर्मिनल चाहिए
CLI के साथ स्किल फ़ाइल
बहुत कम
दोहराए जाने वाले वर्कफ़्लो
रख-रखाव चाहिए
CLI इतना अच्छा क्यों लगता है
मॉडल कमांड पहले से जानते हैं
कमांड लाइन टूल्स के पीछे दशकों के डॉक्यूमेंटेशन, फ़ोरम के जवाब और शेल हिस्ट्री होती है। किसी एक लेखक के खुले pull requests की सूची माँगने पर मॉडल पहली ही कोशिश में सही लाइन लिख देगा:
gh pr list --state open --json number,title,author \
| jq '.[] | select(.author.login == "maria") | .title'
एक लाइन, और मॉडल तक सिर्फ़ अंतिम शीर्षक पहुँचते हैं। कच्चा JSON कभी कॉन्टेक्स्ट में नहीं आता। पाइप, फ़िल्टर और रीडायरेक्ट एजेंट्स को मुफ़्त में कंपोज़िशन देते हैं।
मदद का टेक्स्ट ज़रूरत पड़ने पर आता है
CLI अपनी पूरी सतह पहले से नहीं बताता। एजेंट जिस एक सबकमांड की ज़रूरत है, उसके लिए --help चलाता है, कुछ पंक्तियाँ पढ़ता है और आगे बढ़ जाता है। इसे प्रोग्रेसिव डिसक्लोज़र कहते हैं, और बड़े टूल स्कीमा में ठीक यही नहीं होता।
इंसानों के लिए एक और फ़ायदा भी है। एजेंट जो भी कमांड चलाता है, उसे आप खुद टर्मिनल में चलाकर बग दोहरा सकते हैं। कोई छिपा प्रोटोकॉल नहीं, कोई खास इंस्पेक्टर नहीं।
💡 मोटा नियम: अगर किसी काम के लिए कोई परिपक्व CLI पहले से मौजूद है (git, gh, aws, kubectl, docker), तो एजेंट को उसे इस्तेमाल करने दें।
जहाँ CLI टूटता है
शेल नहीं, तो CLI नहीं
एक Google DeepMind इंजीनियर ने सबसे साफ़ प्रतिदलील दी: अगर आपका एजेंट फ़ोन पर नोट्स ऐप के अंदर रहता है, तो "बस CLI इस्तेमाल करें" कोई विकल्प नहीं है। यही बात ब्राउज़र चैट ऐप्स, सख्त एंटरप्राइज़ असिस्टेंट्स और उन सैंडबॉक्स पर लागू होती है जिनमें प्रोसेस की पहुँच नहीं है। रोज़ AI इस्तेमाल करने वाले ज़्यादातर लोग टर्मिनल में नहीं बैठते।
अनुमतियाँ, पहचान और ऑडिट
शेल एक अनगढ़ औज़ार है। टर्मिनल वाला एजेंट उस मशीन की फ़ाइल सिस्टम, एनवायरनमेंट वेरिएबल और हर लॉग-इन सेशन को विरासत में पाता है। आप उसे घेर सकते हैं, पर डिफ़ॉल्ट रूप से वह पूरी तरह खुला रहता है।
निष्पक्ष होने के लिए, कोई भी रास्ता डिफ़ॉल्ट रूप से सुरक्षित नहीं है। कोई वेब पेज, ईमेल या टिकट मॉडल के लिए छिपे निर्देश ले जा सकता है, और यह जोखिम तब भी रहता है जब टेक्स्ट किसी टूल कॉल से आए या curl के आउटपुट से। सैंडबॉक्स, केवल-पढ़ने वाले क्रेडेंशियल और जोखिम भरी कार्रवाइयों के लिए इंसानी मंज़ूरी, दोनों दुनिया में मायने रखते हैं। फ़र्क यह है कि MCP इन सीमाओं को लागू करने की स्वाभाविक जगह देता है, जबकि कच्चा शेल यह काम आप पर छोड़ देता है।
एक MCP सर्वर सिर्फ़ वही टूल दिखा सकता है जो आप चुनें। रिमोट सर्वर OAuth इस्तेमाल कर सकता है, ताकि हर व्यक्ति अपनी पहचान से काम करे, और एक केंद्रीय गेटवे हर कॉल लॉग कर सकता है। पचास लोगों की टीम के लिए यह उन पचास लैपटॉप से बेहतर है, जिनमें हर एक dotfile में लंबे समय वाला टोकन रखे हैं।
MCP खुद को कैसे ढाल रहा है
प्रोटोकॉल उसी आलोचना का जवाब दे रहा है जो आलोचकों ने उठाई, और तेज़ी से:
कोड एक्ज़ीक्यूशन: एजेंट एक छोटी स्क्रिप्ट लिखता है जो MCP टूल्स को कॉल करती है, सैंडबॉक्स में डेटा छानती है और सिर्फ़ नतीजा लौटाती है। Cloudflare का Code Mode यही विचार लागू करता है, जिसमें टूल्स को एक टाइप्ड API में बदला जाता है जिस पर मॉडल कोड लिखता है।
ज़रूरत पर टूल लोडिंग: Claude Code जैसे क्लाइंट अब टूल डेफ़िनिशन तभी लोड करते हैं जब एजेंट को टूल सर्च के ज़रिए उनकी ज़रूरत हो, शुरू में हर स्कीमा नहीं डालते।
चुने हुए सर्वर: बेहतर सर्वर पाँच से दस अच्छे नाम वाले टूल देते हैं, न कि नब्बे REST endpoints का यांत्रिक रैप।
OAuth वाले रिमोट सर्वर: एक होस्टेड सर्वर, कई उपयोगकर्ता, उचित साइन-इन और केंद्रीय लॉग।
मौजूदा माहौल का एक व्यावहारिक सार: जब आपके पास टर्मिनल हो तो CLI इस्तेमाल करें, जब प्रोटोकॉल की ज़रूरत हो तो चुने हुए MCP सर्वर का उपयोग करें, और पूरे API को अपने आप दर्जनों टूल्स में कभी न बदलें।
चुनने का एक सरल तरीका
पूछने लायक तीन सवाल
क्या एजेंट के पास शेल है? अगर नहीं, तो MCP शायद आपका एकमात्र रास्ता है।
वह किसकी पहचान से काम करता है? अगर कई उपयोगकर्ताओं को अलग साइन-इन और ऑडिट चाहिए, तो MCP पर भरोसा करें।
बीच के नतीजे कितने बड़े हैं? अगर वे बहुत बड़े हैं, तो काम को कोड में चलाएँ, चाहे CLI पाइपलाइन के ज़रिए हो या कोड एक्ज़ीक्यूशन वाले MCP से।
स्थिति
बेहतर विकल्प
क्यों
टर्मिनल वाला लोकल कोडिंग एजेंट
CLI
सबसे कम ओवरहेड, मॉडल टूल्स जानते हैं
टूल के पास पहले से अच्छा CLI है
CLI
पाइप डेटा को कॉन्टेक्स्ट से बाहर रखते हैं
ब्राउज़र या फ़ोन चैट ऐप
MCP
कोई शेल उपलब्ध नहीं
कई उपयोगकर्ता, साझा टूल, ऑडिट की ज़रूरत
MCP
OAuth, सीमित टूल्स, केंद्रीय लॉग
बिना CLI के और केवल OAuth वाला SaaS
MCP
मानक साइन-इन और टूल स्कीमा
बड़ी फ़ाइलें ले जाने वाला लंबा वर्कफ़्लो
कोड एक्ज़ीक्यूशन
डेटा मॉडल से बाहर रहता है
ज़्यादातर टीमें अंत में दोनों ही इस्तेमाल करती हैं। MCP उन कुछ सिस्टमों को संभालता है जिन्हें साइन-इन और गवर्नेंस चाहिए, और CLI वह सब संभालता है जो डेवलपर टर्मिनल में पहले से करते हैं।
व्यवहार में यह ऐसे दिखता है। टर्मिनल एजेंट पर काम करने वाला अकेला डेवलपर दिन भर git, gh और docker इस्तेमाल करेगा, और उन चीज़ों के लिए एक-दो MCP सर्वर जोड़ेगा जिनका कोई CLI नहीं है, जैसे डिज़ाइन टूल या टिकट ट्रैकर। ब्राउज़र में चैट असिस्टेंट चलाने वाली सपोर्ट टीम के पास कोई शेल नहीं है, इसलिए साइन-इन वाला होस्टेड MCP सर्वर ही एकमात्र काम का रास्ता है। दर्जनों एजेंट चलाने वाली प्लेटफ़ॉर्म टीम को केंद्रीय लॉग और सीमित टूल्स चाहिए, इसलिए वह कुछ चुने हुए सर्वरों के सामने एक गेटवे लगाती है।
ऐसा मॉडल चुनें जो टूल संभाल सके
दोनों रास्ते इस पर निर्भर हैं कि मॉडल टूल्स को भरोसेमंद तरीके से कॉल करे। PicassoIA पर आप एक ही जगह कई लार्ज लैंग्वेज मॉडल की तुलना कर सकते हैं: कोडिंग कार्यों को स्वचालित करने के लिए Claude Sonnet 5, जटिल कोडिंग काम के लिए GPT 5.6 Sol, एजेंट बनाने के लिए Kimi K2.6, और तेज़ चैट व कोड के लिए Gemini 3.5 Flash। उनमें से दो को एक ही टूल वाला काम दें और देखें कि हर एक फ़ेल हुई कॉल को कैसे संभालता है।
PicassoIA के साथ दोनों आज़माएँ
इमेज और वीडियो जनरेशन इस बहस के लिए अच्छा परीक्षण क्षेत्र है। आउटपुट बड़े होते हैं, काम में समय लगता है, और टूल को प्रगति बतानी होती है। PicassoIA वही चार मॉडल MCP कनेक्टर और REST API के ज़रिए देता है: PicassoIA Image, PicassoIA Image Editor Pro, PicassoIA Video और ऑडियो वाले वीडियो के लिए Seedance 2.5 Lite।
MCP से कनेक्ट करें
picassoia.com पर साइन इन करें और अपने अकाउंट में MCP कनेक्शन पेज खोलें (picassoia.com/en/mcp/accounts)।
उस पेज पर दिए निर्देशों के अनुसार कनेक्टर को अपने AI क्लाइंट में जोड़ें।
सादी भाषा में इमेज माँगें, जैसे "भोर में एक लाइटहाउस की 16:9 फ़ोटो"।
टूल एक जॉब शुरू करता है और एक ID लौटाता है। असिस्टेंट उसके पूरा होने तक जाँच करता है, फिर आपको नतीजा दिखाता है।
हर अकाउंट के लिए एक समय में अधिकतम पाँच जॉब चल सकते हैं, जो हर कनेक्शन में साझा होते हैं।
देखें कि प्रोटोकॉल यहाँ क्या अच्छा करता है। असिस्टेंट को URL, हेडर या पोलिंग अंतराल जानने की ज़रूरत नहीं। टूल के विवरण बताते हैं कि जॉब कैसे शुरू करें और उसकी जाँच कैसे करें, और नतीजा चैट में वापस आ जाता है। यही सुविधा MCP का वादा है, और ब्राउज़र में काम करने वाले गैर-तकनीकी उपयोगकर्ता के लिए यह "काम करता है" और "संभव नहीं" के बीच का फ़र्क है।
टर्मिनल से REST API कॉल करें
वही मॉडल https://api.picassoia.com/v1 पर उपलब्ध हैं, और एक बेयरर टोकन के साथ जो pia_sk_ से शुरू होता है। इसका ढाँचा Replicate शैली का है: एक prediction बनाएँ, उसकी स्थिति जाँचें, फिर आउटपुट लें।
रिस्पॉन्स में एक prediction ID आता है। GET /v1/predictions/{id} की स्थिति तब तक जाँचें जब तक स्टेटस succeeded दिखाए, फिर फ़ाइल डाउनलोड करें। हर मॉडल के सटीक इनपुट फ़ील्ड के लिए picassoia.com पर API पेज देखें।
💡 खुद आज़माएँ: वही प्रॉम्प्ट एक बार MCP कनेक्टर से और एक बार curl से चलाएँ। दोनों का समय लें, चरण गिनें और तय करें कि कौन-सा आपके वर्कफ़्लो में फिट बैठता है।
MCP मरा नहीं है और CLI कोई फ़ैशन नहीं है। ये दो टूल हैं जिनके काम अलग हैं, और समझदारी यह है कि हर एक को उस जगह से मिलाएँ जहाँ आपका एजेंट असल में रहता है। picassoia.com खोलें, एक मॉडल चुनें, अपना पहला प्रॉम्प्ट लिखें और अपनी इमेज के साथ दोनों रास्ते खुद देखें।