लोकल MCP सर्वर stdio के ज़रिए आपकी अपनी मशीन पर एक प्रोसेस के रूप में चलते हैं, जबकि रिमोट MCP सर्वर एक HTTPS एंडपॉइंट के पीछे रहते हैं, जिस तक आपकी टीम का कोई भी सदस्य पहुँच सकता है। यह लेख सेटअप, सुरक्षा, लेटेंसी, लागत और स्केलिंग को परखता है, ताकि आप अपने AI एजेंट के लिए सही विकल्प चुन सकें।
आपकी AI एजेंट कॉन्फ़िग फ़ाइल सबसे पहले एक चीज़ माँगती है: एक command या एक url। यही एक पंक्ति तय करती है कि आपके टूल्स कहाँ चलेंगे, उन तक कौन पहुँच सकेगा, जब आपका लैपटॉप स्लीप मोड में जाएगा तब क्या होगा, और उनके पीछे की मशीन का खर्च कौन उठाएगा। गलत चुनाव का मतलब या तो बैकग्राउंड प्रोसेस के ढेर को संभालते रहना है, या किसी अजनबी के सर्वर को आपकी फ़ाइलों तक रास्ता देना।
लोकल MCP सर्वर और रिमोट MCP सर्वर के बीच का चुनाव तकनीकी लगता है, पर असल में यह भरोसे, दूरी और मालिकाना हक का सवाल है। यह लेख बताता है कि हर एक कैसे काम करता है, कहाँ कौन सा बेहतर है, कहाँ कौन सा दिक्कत देता है, और अंत में एक छोटी चेकलिस्ट देता है, ताकि आप पाँच मीटिंग्स में नहीं, पाँच मिनट में फ़ैसला कर सकें।
💡 संक्षिप्त उत्तर: जब टूल आपकी अपनी मशीन की फ़ाइलों, शेल या निजी डेटा को छूता हो, तब लोकल सर्वर का उपयोग करें। जब कई लोगों, डिवाइस या एजेंट्स को बिना कुछ इंस्टॉल किए एक ही टूल चाहिए, तब रिमोट सर्वर का उपयोग करें।
Model Context Protocol, यानी MCP, एक ओपन स्टैंडर्ड है जो AI एप्लिकेशन को एक सुसंगत इंटरफ़ेस के ज़रिए बाहरी टूल्स बुलाने देता है। हर मॉडल और हर ऐप के लिए अलग प्लगइन लिखने के बजाय डेवलपर एक ही सर्वर लिखता है। कोई भी संगत क्लाइंट फिर उसके टूल्स की सूची देख सकता है, उन्हें बुला सकता है और नतीजे पढ़ सकता है।
इसमें तीन भूमिकाएँ होती हैं। होस्ट वह ऐप है जिसे आप इस्तेमाल करते हैं, जैसे कोड एडिटर या चैट असिस्टेंट। उसके अंदर एक MCP क्लाइंट रहता है, जो सर्वर से एक-से-एक कनेक्शन बनाए रखता है। सर्वर टूल्स (वे कार्य जिन्हें मॉडल माँग सकता है), रिसोर्सेज़ (वह डेटा जिसे मॉडल पढ़ सकता है) और प्रॉम्प्ट्स (दोबारा इस्तेमाल होने वाले टेम्पलेट) उपलब्ध कराता है। संदेश JSON-RPC 2.0 में चलते हैं, इसलिए ट्रैफ़िक चाहे पॉइंट A से B तक किसी भी रास्ते से जाए, वह सादा संरचित टेक्स्ट ही रहता है।
बस यही "यह A से B तक कैसे पहुँचता है" वाला हिस्सा ही पूरी लोकल बनाम रिमोट बहस है।
स्पेसिफ़िकेशन दो मानक ट्रांसपोर्ट परिभाषित करता है:
लोकल सर्वर लगभग हमेशा stdio का उपयोग करते हैं। रिमोट सर्वर Streamable HTTP का उपयोग करते हैं, जिसने पुराने HTTP plus SSE ट्रांसपोर्ट की जगह ली है। दोनों मामलों में टूल्स एक जैसे हो सकते हैं। बदलता सिर्फ़ प्लंबिंग है, और वही तय करती है कि आपका सिक्योरिटी मॉडल, लेटेंसी और रखरखाव का बिल कैसा होगा।
stdio के साथ आपका क्लाइंट एक कॉन्फ़िग फ़ाइल पढ़ता है, आपके लिखे कमांड को स्पॉन करता है और उस प्रोसेस को पूरे सेशन के दौरान चालू रखता है। रिक्वेस्ट stdin से अंदर जाती हैं, जवाब stdout से बाहर आते हैं, और लॉग stderr पर जाने चाहिए। stdout में कोई भटका हुआ print लिख दें तो प्रोटोकॉल स्ट्रीम बिगड़ जाती है, जो पहले दिन की एक क्लासिक गलती है।
{
"mcpServers": {
"project-files": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects"]
}
}
}
यहाँ कोई पोर्ट खोलना नहीं पड़ता, कोई फ़ायरवॉल नियम नहीं, और कोई लॉगिन स्क्रीन नहीं। प्रोसेस आपकी यूज़र परमिशन और एनवायरनमेंट वेरिएबल्स विरासत में लेती है, और यही इसे इतना सुविधाजनक बनाता है और इतना सोचने लायक भी।
हर टीम के सदस्य को रनटाइम इंस्टॉल करना पड़ता है, सही वर्ज़न पिन करना पड़ता है और कॉन्फ़िग कॉपी करनी पड़ती है। सर्वर अपडेट करें तो दस लैपटॉप आपस में असंगत हो जाते हैं। हर क्लाइंट ऐप भी अपनी प्रोसेस स्पॉन करता है, इसलिए तीन एडिटर का मतलब है तीन कॉपियाँ साथ-साथ चलती हुईं। और लोकल सर्वर आपके सेशन के साथ ही मर जाता है, इसलिए आपका लैपटॉप बंद होने पर उसे कोई नहीं बुला सकता।
सपोर्ट एक छिपी हुई लागत है। जब कोई टूल किसी एक व्यक्ति की मशीन पर टूटता है, तो आप टूल को नहीं, बल्कि Node वर्ज़न, PATH की समस्या या किसी गायब Python पैकेज को डीबग कर रहे होते हैं।
रिमोट सर्वर https://tools.example.com/mcp जैसे URL पर रहता है। क्लाइंट JSON-RPC संदेश HTTP POST रिक्वेस्ट के रूप में उस एक एंडपॉइंट पर भेजता है। सर्वर सामान्य JSON जवाब देता है, या जब उसके पास प्रोग्रेस अपडेट या कई संदेश भेजने हों, तब Server-Sent Events स्ट्रीम खोलता है। एक सेशन हेडर सर्वर को कॉल्स के बीच स्टेट रखने देता है।
अधिकांश क्लाइंट में इसे जोड़ने के लिए एक ही कमांड लगता है:
claude mcp add --transport http notes https://tools.example.com/mcp
चूँकि एंडपॉइंट इंटरनेट से पहुँच योग्य है, इसलिए ऑथेंटिकेशन का सवाल "इस लैपटॉप में कौन लॉग इन है" से बदलकर "किसके पास वैध टोकन है" बन जाता है। स्पेक में ऑथराइज़ेशन फ़्लो OAuth पर आधारित है, इसलिए यूज़र ब्राउज़र के ज़रिए साइन इन करता है और क्लाइंट एक स्कोप्ड, रद्द किया जा सकने वाला टोकन सहेजता है।
PicassoIA का अपना कनेक्टर एक अच्छा असली उदाहरण है। यह एक रिमोट MCP सर्वर है जो इमेज जनरेशन, इमेज एडिटिंग और वीडियो जनरेशन के टूल्स उपलब्ध कराता है। जॉब एसिंक्रोनस होते हैं: एक जनरेट कॉल तुरंत एक prediction ID लौटाती है, और क्लाइंट नतीजे के लिए पोल करता है। हर कनेक्शन पर प्रति अकाउंट पाँच एक साथ चलने वाले predictions की साझा सीमा लागू होती है, जो केवल इसलिए संभव है क्योंकि स्टेट सर्वर पर रहती है। आपके लैपटॉप को कभी GPU, मॉडल डाउनलोड या Python एनवायरनमेंट नहीं चाहिए।
अब आप किसी और के अपटाइम और अपने कनेक्शन पर निर्भर हैं। नेटवर्क राउंड ट्रिप हर टूल कॉल में लेटेंसी जोड़ते हैं, और धीमा हैंडशेक एजेंट को सुस्त महसूस करा सकता है। सर्वर को आपकी मशीन से जो कुछ चाहिए, जैसे कोई लोकल फ़ाइल, वह वहाँ होती ही नहीं। होस्टिंग का मतलब है TLS सर्टिफ़िकेट, मॉनिटरिंग, रेट लिमिट और ऑन-कॉल पर कोई व्यक्ति। और सार्वजनिक एंडपॉइंट एक निशाना होता है, इसलिए उसे पहले दिन से ही उचित ऑथेंटिकेशन चाहिए।
| कारक | लोकल (stdio) | रिमोट (Streamable HTTP) |
|---|---|---|
| यह कहाँ चलता है | आपकी मशीन पर, एक चाइल्ड प्रोसेस के रूप में | एक URL के पीछे होस्ट किया गया सर्वर |
| हर यूज़र के लिए सेटअप | एक रनटाइम इंस्टॉल करें और कॉन्फ़िग बदलें | URL चिपकाएँ और साइन इन करें |
| अपडेट | हर मशीन पर मैन्युअल | एक बार डिप्लॉय होता है |
| नेटवर्क चाहिए | नहीं | हाँ |
| लोकल फ़ाइलों तक पहुँच | सीधी | कोई नहीं, जब तक आप उन्हें अपलोड न करें |
| ऑथ मॉडल | OS यूज़र और एनवायरनमेंट वेरिएबल्स | OAuth या बेयर टोकन |
| मल्टी-यूज़र सपोर्ट | कमज़ोर | इसी के लिए बना है |
| लेटेंसी का अतिरिक्त बोझ | नगण्य | हर कॉल पर एक नेटवर्क राउंड ट्रिप |
| चलाने की लागत | आपका अपना हार्डवेयर | होस्टिंग और रखरखाव |
| आम विफलता | प्रोसेस क्रैश होती है या शुरू होने में विफल रहती है | आउटेज, टाइमआउट या एक्सपायर्ड टोकन |
दोनों में से कोई भी अपने आप ज़्यादा सुरक्षित नहीं है। लोकल सर्वर आपकी परमिशन के साथ चलता है, इसलिए कोई दुर्भावनापूर्ण या बग वाला पैकेज आपकी फ़ाइलें और SSH कॉन्फ़िग पढ़ सकता है, और npx या uvx के ज़रिए आया कोई भी कोड ऐसा है जिसका शायद आपने ऑडिट नहीं किया। रिमोट सर्वर वह कोड आपकी मशीन से बाहर रखता है, लेकिन अब आपको उसके ऑपरेटर पर उस हर चीज़ के लिए भरोसा करना होता है जो टूल को मिलती है, और हर रिक्वेस्ट नेटवर्क से होकर गुज़रती है।
💡 अंगूठे का नियम: किसी भी MCP सर्वर को ब्राउज़र एक्सटेंशन की तरह मानें। जाँचें कि उसे किसने लिखा है, वर्ज़न पिन करें, और सबसे संकीर्ण परमिशन दें जिससे वह अब भी काम कर सके।
कुछ खास बातें जो करने लायक हैं:
127.0.0.1 से बाइंड करें और Origin हेडर को वैलिडेट करें, वरना आपके ब्राउज़र का कोई वेब पेज DNS rebinding के ज़रिए उन तक पहुँच सकता है।stdio लेयर की लागत लगभग शून्य है। रिमोट कॉल कम से कम एक नेटवर्क राउंड ट्रिप जोड़ती है, जो एक ही क्षेत्र के भीतर कुछ मिलीसेकंड और महाद्वीपों के पार कुछ सौ मिलीसेकंड हो सकती है, साथ में TLS और किसी भी ऑथ जाँच का समय। व्यवहार में टूल का अपना काम, जैसे डेटाबेस क्वेरी, API कॉल या इमेज रेंडर, ट्रांसपोर्ट को कहीं पीछे छोड़ देता है। रिमोट लेटेंसी सिर्फ़ उन बातूनी एजेंट्स पर असर डालती है जो एक के बाद एक दर्जनों छोटी कॉल दागते हैं।
विश्वसनीयता का समीकरण उलटा है। लोकल प्रोसेस तेज़ और साफ़ नज़र आने वाली विफलता देती है, आम तौर पर स्टार्टअप पर। रिमोट सेवा चुपचाप विफल हो सकती है: एक्सपायर टोकन, रेट लिमिट, या क्षेत्रीय आउटेज। रिट्राई की योजना बनाएँ और ऐसे एरर मैसेज लिखें जिन पर मॉडल कार्रवाई कर सके।
दोनों तरफ़ स्पष्ट टाइमआउट सेट करें। जो क्लाइंट किसी अटके हुए रिमोट कॉल का अनंत इंतज़ार करता है, वह पूरी बातचीत को जमा देता है, जबकि जो सर्वर बहुत जल्दी हार मान लेता है, वह वीडियो रेंडरिंग जैसे वैध लंबे जॉब्स काट देता है। कुछ सेकंड से ज़्यादा चलने वाली किसी भी चीज़ की प्रोग्रेस रिपोर्ट करें।
लोकल को होस्ट करने का खर्च नहीं है, पर सपोर्ट में समय लगता है, और हर "मेरी मशीन पर तो चल रहा है" वाली शिकायत आप पर आती है। रिमोट में पैसा और ऑपरेशंस का काम लगता है, लेकिन जब टीम शामिल हो जाए तो सपोर्ट का समय बचाता है। ब्रेक-ईवन उस पल के आसपास होता है जब मुट्ठी भर से ज़्यादा लोगों को एक ही सर्वर चाहिए।
इसका अनुमान लगाने का एक सरल तरीका: लोगों की गिनती करें, उसे प्रति व्यक्ति प्रति माह सेटअप और समस्या-निवारण में लगने वाले मिनटों से गुणा करें, और उस संख्या की तुलना एक छोटे होस्टिंग प्लान से करें। दो लोगों के लिए लोकल रास्ता आम तौर पर जीतता है। बीस के लिए शायद ही कभी जीतता है।
जब आपके टूल्स आपकी अपनी चीज़ों को छूते हों, तब लोकल चुनें: कोड रिपॉज़िटरी, नोट्स फ़ोल्डर, लोकल डेटाबेस, या कोई ब्राउज़र जिसे आप ऑटोमेट करते हैं। प्रोटोटाइप के लिए भी लोकल बेहतर घर है, क्योंकि आप सर्वर में बदलाव करके उसे सेकंडों में रीस्टार्ट कर सकते हैं, बिना डिप्लॉय पाइपलाइन के।
जब कोई टूल टीम का हो, तब रिमोट चुनें: टिकट सिस्टम, आंतरिक नॉलेज बेस, साझा डिज़ाइन एसेट्स, बिलिंग डेटा। केंद्रीय ऑथ और ऑडिट लॉग कुछ मिलीसेकंड बचाने से ज़्यादा मायने रखते हैं। जब क्लाइंट प्रोसेस स्पॉन नहीं कर सकता, तब भी रिमोट ही एकमात्र विकल्प है, जो ज़्यादातर वेब असिस्टेंट और मोबाइल ऐप्स का मामला है।
चरणों में रोलआउट करें। एक केवल-पढ़ने वाले रिमोट सर्वर से शुरू करें ताकि लोग बिना जोखिम के उसे आज़मा सकें, ऑडिट लॉग ठीक दिखने लगे तो लिखने वाले टूल्स जोड़ें, और एक किल स्विच रखें जो एक ही कदम में टोकन रद्द कर दे। जो टीमें यह क्रम छोड़ देती हैं, वे आम तौर पर अपनी गलतियाँ डैशबोर्ड से नहीं, किसी गुस्से भरे संदेश से जानती हैं।
इन सवालों के जवाब क्रम से दें, और पहली "हाँ" पर रुक जाएँ:
असली प्रोजेक्ट शायद ही कभी एक ही विकल्प चुनते हैं। ये पैटर्न बार-बार दिखते हैं:
अस्थिर कनेक्शन वाले कैफ़े से काम करना वही जगह है जहाँ हाइब्रिड सेटअप सबसे ज़्यादा फ़ायदा देता है। फ़ाइल टूल्स लोकल चलते रहते हैं, जबकि होस्टेड टूल्स बैकग्राउंड में रिट्राई करते हैं, और जब तक आप खुद न चाहें, कुछ भी संवेदनशील आपकी मशीन से बाहर नहीं जाता।
/Users/me/notes पढ़ता है, क्लाउड बॉक्स पर कोई मतलब नहीं रखता। अगर डेटा आपके लैपटॉप पर है, तो सर्वर भी आपके लैपटॉप पर होना चाहिए।आप जो भी ट्रांसपोर्ट चुनें, फ़ायदा एक ही है: एक AI असिस्टेंट जो सिर्फ़ बात करने के बजाय आपके लिए असली काम करता है। रिमोट कनेक्शन इसे महसूस करने का सबसे तेज़ तरीका है, क्योंकि वहाँ कुछ इंस्टॉल नहीं करना पड़ता और कुछ चालू नहीं रखना पड़ता।
पहले इमेज पर आज़माएँ। PicassoIA Image एक सादी भाषा में लिखे प्रॉम्प्ट को सेकंडों में तैयार तस्वीर में बदल देता है, जिसमें सात आस्पेक्ट रेशियो, लॉक किया जा सकने वाला सीड और प्रति इमेज कोई सीमा नहीं है। एक प्रॉम्प्ट लिखें, कुछ वेरिएशन जनरेट करें, फिर लेंस, रोशनी या कैमरा एंगल जैसी कोई एक डिटेल बदलें और देखें कि क्या बदलता है। प्रॉम्प्ट, नतीजा और बदलाव का यह छोटा चक्र ही वह आदत है जो बाद के हर टूल को, MCP हो या न हो, इस्तेमाल करना आसान बनाती है।
अगर आप खुद सर्वर कोड लिख या रिव्यू कर रहे हैं, तो एक मज़बूत कोडिंग मॉडल मदद करता है। Claude Sonnet 5, GPT 5.6 Sol, Gemini 3.5 Flash और Kimi K2.6 सभी PicassoIA पर उपलब्ध हैं, ताकि आप देख सकें कि हर एक एक ही टूल स्कीमा को कैसे संभालता है।
प्रयोग के लिए तैयार हैं? PicassoIA खोलें, पूरी मॉडल सूची से एक मॉडल चुनें और आज ही अपनी पहली इमेज जनरेट करें।
अपनी भाषा चुनें
