MCP सर्वर प्रविष्टि JSON का छोटा-सा टुकड़ा है जिसकी विफलता बेरहम है: कोई कुंजी ग़लत हो तो त्रुटि नहीं आती, सर्वर बस दिखता नहीं। हर ट्रांसपोर्ट को अलग आकार चाहिए — स्थानीय को कमांड और तर्क, दूरस्थ को URL और आम तौर पर एक हेडर — और इन्हें मिला देने से ऐसी फ़ाइल बनती है जो पूरी दिखती है और कुछ करती नहीं। यह बिल्डर सिर्फ़ वही फ़ील्ड पूछता है जिन्हें चुना हुआ ट्रांसपोर्ट सचमुच इस्तेमाल करता है, दूसरे का फ़ील्ड भरा हो तो चेतावनी देता है, और शायद व्यवहार की सबसे आम ग़लती दिखाता है: ऐसी फ़ाइल में असली साख लिख देना जो अंततः रिपॉज़िटरी में जाती है। यह कॉन्फ़िग फ़ाइल और उसके बराबर एक-पंक्ति कमांड, दोनों देता है।
विशेषताएँ
सिर्फ़ वे फ़ील्ड जो चुना हुआ ट्रांसपोर्ट इस्तेमाल करता है
दूसरे ट्रांसपोर्ट का फ़ील्ड भरा हो तो चेतावनी
फ़ाइल में असली जैसा गोपनीय मान दिखे तो चिह्नित, प्लेसहोल्डर नहीं
दूरस्थ होस्ट के लिए बिना एन्क्रिप्शन HTTP पर चेतावनी, localhost पर चुप
कमांड फ़ील्ड में घुस आए तर्क पकड़ता है
परिवेश चर और हेडर संपादन योग्य जोड़ों में
परियोजना फ़ाइल और डेस्कटॉप ऐप कॉन्फ़िग दोनों देता है
बराबर वाला कमांड, सही ढंग से उद्धृत
MCP सर्वर कॉन्फ़िग का उपयोग कैसे करें
सर्वर का नाम रखिए — उसके उपकरण इसी से समूहित होते हैं
वह ट्रांसपोर्ट चुनिए जो वह इस्तेमाल करता है
कमांड और तर्क भरिए, या URL और हेडर
JSON अपने कॉन्फ़िग में कॉपी कीजिए, या कमांड चलाइए
उदाहरण
इनपुट
"command": "npx -y some-server"
आउटपुट
Warning: looked up as a single executable with that name
पहला शब्द कमांड है; बाक़ी सब तर्क।
सामान्य त्रुटियाँ और समस्या निवारण
सर्वर कभी दिखता ही नहीं। — आम तौर पर आकार की चूक: url वाली stdio प्रविष्टि, या command वाली दूरस्थ प्रविष्टि। दोनों यहाँ दिखाई जाती हैं, क्योंकि अकेले में कोई त्रुटि नहीं देती।
कमांड नहीं मिलता। — तर्क अलग रखने होते हैं। कमांड फ़ील्ड में npx और बाक़ी तर्क सूची में: स्पेस वाला कमांड उसी नाम की एकल निष्पादन फ़ाइल की तरह खोजा जाता है।
मेरे यहाँ चलता है, दूसरों के यहाँ नहीं। — आम तौर पर तर्कों में आपकी मशीन का पूर्ण पथ है, या आपके परिवेश की ऐसी साख चाहिए जो किसी और के पास नहीं।
कॉन्फ़िग फ़ाइल में मेरा टोकन है। — उसकी जगह परिवेश चर का संदर्भ दीजिए। असली जैसा गोपनीय मान यहाँ दिखाया जाता है, क्योंकि कॉन्फ़िग फ़ाइलें रिपॉज़िटरी में चली जाती हैं।
अक्सर पूछे जाने वाले प्रश्न
कौन-सा ट्रांसपोर्ट लें?
जो कुछ स्थानीय रूप से चलाते हैं उसके लिए stdio: क्लाइंट उसे प्रक्रिया की तरह शुरू करता है और उसके मानक इनपुट-आउटपुट से बात करता है। दूरस्थ सर्वर के लिए HTTP। SSE मुख्यतः उन सर्वरों के लिए है जो HTTP के आम होने से पहले लिखे गए।
कॉन्फ़िग फ़ाइल कहाँ जाती है?
परियोजना फ़ाइल रिपॉज़िटरी में रहती है ताकि पूरी टीम को एक ही सर्वर मिलें; डेस्कटॉप ऐप का अपना कॉन्फ़िग है उन सर्वरों के लिए जो आप हर जगह चाहते हैं। दोनों रूप निकाले जाते हैं और पथ दिखाया जाता है।
टोकन फ़ाइल से बाहर कैसे रखें?
मान के बजाय परिवेश चर का संदर्भ लिखिए। यहाँ की जाँच देखती है कि मान असली साख जैसा है या प्लेसहोल्डर जैसा, और सिर्फ़ पहले पर आपत्ति करती है।
फ़ाइल लें या कमांड?
दोनों एक ही काम करते हैं। परियोजना के साथ संस्करण में रखना हो तो फ़ाइल बेहतर; सिर्फ़ आज़मा रहे हों तो कमांड तेज़। दोनों एक ही फ़ील्डों से बनते हैं।
सर्वर का नाम क्यों मायने रखता है?
यही वह कुंजी है जिसके नीचे प्रविष्टि रखी जाती है और उसके उपकरणों का नामस्थान भी, इसलिए दो सर्वर इसे साझा नहीं कर सकते, और नाम बदलने से हर जगह उन उपकरणों का संदर्भ बदल जाता है।
संबंधित टूल
MCP टूल स्कीमा बिल्डर — उपकरण तय कीजिए और JSON Schema पाइए, strict mode जाँच के साथ।
टूल स्कीमा सत्यापन — परिभाषा चिपकाइए और जानिए वह क्यों अस्वीकार हो रही है।
हुक बिल्डर — settings.json के हुक बनाइए और कभी न चलने वाले मैचर पकड़िए।
अनुमति नियम परीक्षक — अनुमति, पूछो और मनाही के नियम असली कमांडों पर आज़माइए।