क्या हमें अब भी MCP की ज़रूरत है? जब AI एजेंट्स को अब भी MCP सर्वर चाहिए

हर कुछ महीनों में कोई पोस्ट करता है कि MCP मर चुका है, और हर कुछ महीनों में कोई टीम उत्पादन में एक और MCP सर्वर लॉन्च कर देती है। दोनों बातें एक साथ सच हैं। मॉडल शेल कमांड चलाने, डॉक्स पढ़ने और छोटी स्क्रिप्ट लिखने में कहीं बेहतर हो गए हैं, इसलिए हर टूल को एक प्रोटोकॉल में लपेटने के शुरुआती कई कारण कमज़ोर पड़ गए हैं। फिर भी कुछ काम ऐसे हैं जिन्हें एक मानक, प्रमाणित और रिमोट इंटरफ़ेस चाहिए, जिससे कोई भी एजेंट बिना कस्टम कनेक्टिंग कोड के जुड़ सके। यह लेख इन दोनों समूहों को अलग करता है। आप देखेंगे कि सादा CLI या स्किल फ़ाइल कहाँ MCP सर्वर से बेहतर है, सर्वर कहाँ अब भी जीतता है, और लगभग पाँच मिनट में फ़ैसला कैसे करें।

MCP असल में क्या करता है

सीधी परिभाषा

Model Context Protocol, यानी MCP, एक ओपन स्टैंडर्ड है जिसे Anthropic ने नवंबर 2024 में जारी किया था। यह बताता है कि कोई AI एप्लिकेशन (क्लाइंट) एक अलग प्रोग्राम (सर्वर) से तीन चीज़ें कैसे माँगता है: टूल्स जिन्हें वह कॉल कर सके, रिसोर्सेज़ जिन्हें वह पढ़ सके, और प्रॉम्प्ट जिन्हें वह दोबारा इस्तेमाल कर सके। संदेश JSON-RPC के ज़रिए जाते हैं, लोकल सर्वर के लिए स्टैंडर्ड इनपुट और आउटपुट पर, और रिमोट सर्वर के लिए Streamable HTTP पर। 2025 में OpenAI और Google ने इसे अपनाया, और बाद में यह प्रोटोकॉल Linux Foundation के Agentic AI Foundation के अधीन चला गया, इसलिए इसे कोई एक विक्रेता नियंत्रित नहीं करता।

इसे एक ट्रैवल अडैप्टर की तरह समझें। दीवार का सॉकेट (सेवा) और प्लग (एजेंट) एक-दूसरे के बारे में कुछ जानने की ज़रूरत नहीं रखते। बीच का अडैप्टर बेमेल को संभालता है।

वह समस्या जिसके लिए यह बना

MCP से पहले, M असिस्टेंट्स को N सेवाओं से जोड़ने का मतलब था M गुणा N कस्टम इंटीग्रेशन। हर जोड़ी का अपना साइन-इन फ़्लो, अपनी स्कीमा की अजीब बातें और अपने बग थे। MCP ने इसे M जमा N बना दिया: हर सेवा के लिए एक सर्वर, हर असिस्टेंट के लिए एक क्लाइंट, और हर संयोजन काम करता है। यह बचत असली है, और इसी से समझ आता है कि लॉन्च के लगभग एक साल के भीतर हज़ारों सार्वजनिक सर्वर क्यों आ गए।

💡 याद रखने लायक बात: MCP प्लंबिंग है, बुद्धिमत्ता नहीं। इसे इस आधार पर परखें कि आपके खास काम के लिए यह प्लंबिंग विकल्प से सस्ती पड़ती है या नहीं, न कि इस आधार पर कि यह इस महीने फ़ैशन में है या नहीं।

MCP के खिलाफ़ तर्क

आलोचक गलत नहीं हैं। तीन शिकायतें बार-बार उठती हैं, और हर एक माप पर खरी उतरती है।

टूल डेफ़िनिशन आपका कॉन्टेक्स्ट खा जाते हैं

सर्वर द्वारा दिया गया हर टूल अपने साथ एक नाम, एक विवरण और एक JSON स्कीमा लेकर आता है। ज़्यादातर क्लाइंट सेशन की शुरुआत में इन सबको मॉडल की कॉन्टेक्स्ट विंडो में लोड कर देते हैं। यहाँ एक मोटा, उदाहरण के लिए गणना है: 400 टोकन प्रति स्कीमा वाले 40 टूल्स का एक सर्वर 16,000 टोकन जोड़ता है। ऐसे पाँच सर्वर जोड़ें तो उपयोगकर्ता के एक शब्द लिखने से पहले ही 80,000 टोकन खर्च हो चुके होते हैं।

इस बिल के तीन हिस्से हैं: पैसा, लेटेंसी, और ध्यान। हर अनुरोध पर टोकन की कीमत लगती है, लंबे प्रॉम्प्ट पर जवाब धीमे आते हैं, और भरी हुई कॉन्टेक्स्ट में उस सामग्री के लिए कम जगह बचती है जिसकी मॉडल को असल में ज़रूरत है। जब दो सर्वर एक ही नाम वाला search टूल दिखाते हैं और मॉडल को अनुमान लगाना पड़ता है कि आपका मतलब किससे था, तो टूल चुनने की गुणवत्ता भी अक्सर गिरती है।

एजेंट्स पहले से शेल की भाषा बोलते हैं

कोडिंग एजेंट्स git, gh, curl, jq, docker और psql में माहिर होते हैं। ये टूल्स ट्रेनिंग डेटा में हज़ारों बार आते हैं, इनका --help फ़्लैग होता है, और इनका आउटपुट सादा टेक्स्ट होता है। जब कोई मॉडल gh pr list --json title,author चला सकता है और नतीजा पार्स कर सकता है, तो GitHub MCP सर्वर बहुत ज़्यादा क्षमता जोड़े बिना एक परत और जोड़ देता है।

CLI कंपोज़ भी होता है। मॉडल एक कमांड का आउटपुट दूसरी में पाइप कर सकता है, नतीजा फ़ाइल में लिख सकता है, और सिर्फ़ वही लाइनें पढ़ सकता है जिनकी उसे ज़रूरत है। MCP टूल कॉल अपना पूरा नतीजा कॉन्टेक्स्ट में लौटा देता है, जब तक सर्वर लेखक ने पेजिनेशन की योजना न बनाई हो, और कई लेखकों ने ऐसा नहीं किया।

स्किल्स और स्क्रिप्ट्स कम खर्चीली हैं

स्किल फ़ाइलें एक अलग रास्ता अपनाती हैं। स्किल एक फ़ोल्डर है जिसमें एक छोटा मार्कडाउन विवरण और, वैकल्पिक रूप से, स्क्रिप्ट्स होती हैं। जब तक एजेंट यह तय नहीं करता कि उसे स्किल चाहिए, केवल उसका नाम और एक लाइन का सार कॉन्टेक्स्ट में रहता है, और तभी वह पूरे निर्देश पढ़ता है। आप हर अनुरोध पर नहीं, बल्कि काम होने के समय भुगतान करते हैं।

"हम डिप्लॉय कैसे करते हैं", "हम रिलीज़ नोट्स कैसे लिखते हैं", या "हम वेयरहाउस से डेटा कैसे क्वेरी करते हैं" जैसे आंतरिक वर्कफ़्लो के लिए स्किल और स्क्रिप्ट अक्सर सबसे छोटा रास्ता होता है। वहाँ होस्ट करने के लिए कोई सर्वर नहीं होता, डीबग करने के लिए कोई ट्रांसपोर्ट नहीं होता, और सब कुछ उसी रिपॉज़िटरी में रहता है जिसमें वह कोड है जिसका वह वर्णन करता है।

जहाँ MCP अब भी जीतता है

अब दूसरी तरफ़ की बात। ये वे स्थितियाँ हैं जहाँ MCP को स्क्रिप्ट्स से बदलने पर काम कम नहीं, बल्कि ज़्यादा बनता है।

असली ऑथ वाली रिमोट सेवाएँ

लैपटॉप पर चल रही स्क्रिप्ट एनवायरनमेंट वेरिएबल से API टोकन पढ़ सकती है। एक डेवलपर के लिए यह ठीक है। लेकिन जब पचास लोगों को CRM की ज़रूरत हो, हर किसी की अलग अनुमति हो, और सिक्योरिटी टीम ऐसे टोकन चाहती हो जो एक्सपायर हों, तब यह टूट जाता है। MCP का ऑथराइज़ेशन फ़्लो OAuth 2.1 पर बना है, इसलिए रिमोट सर्वर हर यूज़र से साइन-इन करवा सकता है, स्कोप्ड टोकन जारी कर सकता है, और उन्हें एक ही जगह से रद्द कर सकता है। एजेंट कभी भी शेल हिस्ट्री में चिपका हुआ लंबे समय तक चलने वाला गुप्त कोड नहीं रखता।

होस्टेड सर्वर वहाँ भी काम करते हैं जहाँ कोई शेल मौजूद ही नहीं: एक चैट ऐप, एक मोबाइल क्लाइंट, एक ब्राउज़र साइडबार। CLI को टर्मिनल चाहिए। रिमोट MCP सर्वर को नेटवर्क कनेक्शन चाहिए।

लंबे जॉब और एसिंक्रोनस नतीजे

कुछ काम मिलीसेकंड में नहीं, मिनटों में पूरे होते हैं। इमेज और वीडियो जनरेशन इसके सबसे साफ़ उदाहरण हैं। एक अनुरोध एक जॉब शुरू करता है, कहीं कोई GPU उसे उठाता है, और कॉलर को बाद में वापस जाँचना पड़ता है। नब्बे सेकंड तक रुकने वाली शेल कमांड अटपटी होती है। जिस टूल का शुरू, पोल और नतीजे का स्पष्ट अनुबंध हो, उसे सही बनाना आसान होता है।

PicassoIA का अपना कनेक्टर इसी पैटर्न पर चलता है। इसका API Replicate स्टाइल का है: प्रेडिक्शन बनाएँ, उसे पोल करें, आउटपुट लाएँ। MCP कनेक्शन के ज़रिए एजेंट चार मॉडल तक पहुँच सकता है, PicassoIA Image, PicassoIA Image Editor Pro, PicassoIA Video, और ऑडियो के साथ वीडियो के लिए Seedance 2.5 Lite, और इसके लिए किसी को हाथ से एंडपॉइंट नहीं लिखने पड़ते। प्लेटफ़ॉर्म हर अकाउंट के लिए पाँच एक साथ चलने वाले प्रेडिक्शन की अनुमति देता है, जो API क्रेडेंशियल और MCP कनेक्शन में साझा है, इसलिए जो एजेंट एक साथ दस अनुरोध भेजता है, उसे यह सीमा माननी होगी। अच्छी तरह बना सर्वर इस हिसाब-किताब को साफ़ टूल नतीजों के पीछे छिपा देता है, ठीक वैसे ही जैसे किचन का पास ऑर्डर को क्रम में रखता है जबकि कुक एक साथ काम करते हैं।

सोचिए कि एक कंटेंट टीम एजेंट से लॉन्च पोस्ट, पाँच हीरो इमेज और एक छोटी एनिमेटेड क्लिप माँगती है। लिखने का काम मॉडल के अंदर होता है। इमेज और क्लिप रिमोट, धीमी और रेट-लिमिटेड होती हैं, और यही वह आकार है जिसे MCP अच्छी तरह संभालता है।

टीम, ऑडिट ट्रेल और अनुमतियाँ

जब कोई एजेंट प्रोडक्शन डेटा को छूता है, तो कोई न कोई पूछता है कि किसने क्या किया। एक केंद्रीय MCP गेटवे हर टूल कॉल का लॉग रख सकता है, हर टीम के लिए allow lists लागू कर सकता है, और जोखिम भरी कार्रवाइयों को सेवा तक पहुँचने से पहले रोक सकता है। वही काम अलग-अलग स्क्रिप्ट्स से करने पर लॉग कई लैपटॉप पर बिखरे मिलते हैं।

समीक्षक इसकी कद्र करते हैं। वे एक लॉग और एक पॉलिसी फ़ाइल पढ़कर देख सकते हैं कि एजेंट को क्या करने की अनुमति थी, बजाय इसके कि पचास अलग-अलग शेल हिस्ट्री की जाँच करें।

MCP बनाम CLI बनाम स्किल्स बनाम API

यही तुलना एक त्वरित संदर्भ तालिका के रूप में यहाँ है।

ध्यान दें कि जवाब शायद ही कभी सब कुछ MCP या कोई MCP नहीं होता। सही चुनाव इस पर निर्भर करता है कि टूल को कौन कॉल करता है, वह कितनी देर चलता है, और उसकी ज़रूरत कितनी बार पड़ती है।

MCP कैसे बदल रहा है

आलोचना असर कर गई, और इकोसिस्टम ने जवाब दिया। दो बदलाव सबसे अहम हैं।

टूल डंप की जगह कोड एक्सीक्यूशन

Anthropic की इंजीनियरिंग टीम ने 2025 के अंत में एक पैटर्न का वर्णन किया, जिसमें एजेंट ऐसा कोड लिखता है जो MCP टूल्स को कॉल करता है, बजाय इसके कि हर कॉल को कॉन्टेक्स्ट विंडो से होकर गुज़ारा जाए। टूल डेफ़िनिशन ऐसी फ़ाइलों के रूप में दिखते हैं जिन्हें एजेंट ब्राउज़ कर सकता है, बीच के नतीजे एक सैंडबॉक्स के भीतर रहते हैं, और केवल अंतिम जवाब मॉडल तक लौटता है। उनके एक कार्य उदाहरण में टोकन उपयोग लगभग 150,000 से घटकर लगभग 2,000 रह गया, यानी 98.7% की कमी।

लेज़ी टूल लोडिंग

अब कई क्लाइंट टूल डेफ़िनिशन ज़रूरत पड़ने पर लोड करते हैं। मॉडल एक कैटलॉग खोजता है, जिन दो-तीन टूल्स की उसे ज़रूरत है, उन्हें उठाता है, और बाकी को नज़रअंदाज़ कर देता है। यही कार्ड कैटलॉग वाला तरीका है: लाइब्रेरी में हज़ारों कार्ड होते हैं, पर आप एक ही दराज़ खोलते हैं। इससे पिछले भाग की सबसे बड़ी शिकायत दूर होती है, और मानक भी नहीं छोड़ना पड़ता।

सर्वर लेखकों ने भी खुद को बदला। छह अच्छी तरह वर्णित, उच्च-स्तरीय टूल्स वाला सर्वर उस सर्वर से बेहतर है जो 300 एंडपॉइंट वाले REST API को पंक्ति-दर-पंक्ति दोहराता है, क्योंकि मॉडल के पास कम विकल्प होते हैं और हर विकल्प का कुछ अर्थ होता है।

पाँच मिनट की फ़ैसला चेकलिस्ट

कुछ भी बनाने या इंस्टॉल करने से पहले इसे देख लें।

MCP कब चुनें

• कई यूज़र्स को एक ही सेवा तक अपनी-अपनी स्कोप्ड पहुँच चाहिए
• काम एसिंक्रोनस है, जैसे रेंडर जॉब या लंबे एक्सपोर्ट
• एजेंट ऐसी जगह चलता है जहाँ कोई शेल नहीं है
• आपको केंद्रीय लॉगिंग, allow lists, या रद्दीकरण चाहिए
• सेवा का मालिक पहले से एक मेंटेन किया हुआ सर्वर देता है

MCP कब छोड़ें

• कोई जानी-मानी CLI पहले से यह काम कर देती है
• काम लोकल फ़ाइलों, git या बिल्ड का है
• इसे केवल आप इस्तेमाल करते हैं, एक ही मशीन पर
• सर्वर किसी REST API को हूबहू दोहराएगा
• आप इसे हर सेशन में लोड करेंगे, पर हफ़्ते में एक बार ही इस्तेमाल करेंगे

मिक्स्ड सेटअप जो काम करते हैं

ज़्यादातर परिपक्व टूल्स का सेट तीनों का इस्तेमाल करता है। एक कोडिंग एजेंट git और टेस्ट के लिए शेल चलाता है, टीम के नियमों के लिए एक स्किल पढ़ता है, और टिकट ट्रैकर, डेटाबेस और मीडिया जनरेशन के लिए दो-तीन रिमोट MCP सर्वर से जुड़ता है। PicassoIA पर उपलब्ध LLM के साथ आप वही टूल कॉलिंग विचार आज़मा सकते हैं, जैसे Claude Sonnet 5, GPT 5.6 Sol, Kimi K2.6, और Gemini 3.5 Flash। मॉडल का चुनाव उतना मायने नहीं रखता जितना टूल्स का दायरा छोटा और साफ़ रखना।

आम गलतियाँ जो टीमें करती हैं

1. सब कुछ लपेट देना क्योंकि आप ऐसा कर सकते हैं। ls या cat के चारों ओर सर्वर एक प्रोसेस, एक ट्रांसपोर्ट और एक स्कीमा जोड़ता है, बदले में ऐसा कुछ नहीं देता जो शेल पहले से नहीं देता।
2. टोकन बिल को नज़रअंदाज़ करना। पहले संदेश से पहले देखें कि आपके जुड़े सर्वर कितने टोकन जोड़ते हैं। अगर संख्या चौंकाती है, तो हर प्रोजेक्ट में सर्वर बंद करें या लेज़ी लोडिंग पर जाएँ।
3. बिना ऑथ सीमाओं के शिप करना। पूरी फ़ाइल और नेटवर्क पहुँच वाला लोकल सर्वर तब जोखिम बन जाता है जब मॉडल अविश्वसनीय वेब पेज पढ़ता है। अनुमतियों को सीमित करें, डिफ़ॉल्ट रूप से केवल-पढ़ने वाले टूल्स रखें, और लिखने से पहले पुष्टि माँगें।
4. सर्वरों में टूल्स दोहराना। दो सर्वर जो दोनों सर्च, फ़ेच या सेंड देते हैं, मॉडल को भ्रमित करते हैं। टूल्स के नाम साफ़ रखें या एक सर्वर बंद कर दें।
5. प्रोटोकॉल को ही प्रोडक्ट मान लेना। यूज़र्स नतीजे की परवाह करते हैं। अगर एक स्क्रिप्ट, एक स्किल या एक डायरेक्ट API कॉल कम सेटअप में बेहतर नतीजा देती है, तो उसे इस्तेमाल करें और आगे बढ़ें।

Picasso IA पर अपनी इमेज बनाएँ

तो क्या अब भी हमें MCP की ज़रूरत है? लोकल, जाने-पहचाने टूल्स के लिए आमतौर पर नहीं। रिमोट, प्रमाणित, धीमी और साझा सेवाओं के लिए आमतौर पर हाँ। यही बँटवारा पूरा जवाब है, और क्लाइंट टूल्स लोड करने में जितने स्मार्ट होते जाएँगे, यह बँटवारा भी बदलता रहेगा।

अगर आप बिना स्पेक पढ़े एक एसिंक्रोनस, रिमोट वर्कफ़्लो को काम करते देखना चाहते हैं, तो कुछ बनाकर देखें। Picasso IA खोलें, एक त्वरित स्थिर छवि के लिए PicassoIA Image चुनें, फिर PicassoIA Image Editor Pro से उसे परिष्कृत करें, और फिर PicassoIA Video से नतीजे को एनिमेट करें। इस लेख की हर इमेज सादी भाषा के प्रॉम्प्ट से शुरू हुई थी, और वही वर्कफ़्लो MCP कनेक्शन के ज़रिए एजेंट के लिए भी खुला है। सब कुछ picassoia.com/en/all-models पर देखें, एक विचार टाइप करें, और देखें कि एक वाक्य कितनी दूर तक जाता है।