MCP कॉन्फ़िगरेशन: संरचना, कनेक्शन और अनुमतियाँ समझें
MCP सेटअप को तीन चरणों में बांटने से समस्या पहचानना आसान होता है: फ़ाइल की संरचना देखें, कनेक्शन जांचें, फिर सर्वर और मांगी गई अनुमतियों का मूल्यांकन करें। संरचना की जांच पहला चरण है; कनेक्शन और विश्वसनीयता के लिए अलग जांच जरूरी है।
ये 3 अलग प्रश्न हैं
क्या ऐप सेटिंग पढ़ सकता है? क्या कनेक्शन काम करता है? क्या स्रोत और अनुमतियाँ आपके डेटा के लिए उचित हैं? पहले का हाँ बाकी दोनों का उत्तर नहीं है।
MCP क्लाइंट को क्षमताएँ देने वाले सर्वर से जोड़ता है। सर्वर stdio वाला स्थानीय प्रोग्राम या HTTP सेवा हो सकता है; संचार का तरीका बदलने से जाँच के बिंदु बदलते हैं।
संदर्भ: Model Context Protocol — Clients, servers and transports
अपने क्लाइंट का स्वीकार्य प्रारूप देखें
ToolRoof mcpServers के अंतर्गत सीमित JSON प्रारूप जाँचता है: वैकल्पिक args और env के साथ command, या वैकल्पिक headers के साथ url। एक प्रविष्टि में command और url दोनों होना त्रुटि है; अनजान फ़ील्ड चेतावनी देते हैं।
यह सभी MCP ऐप का प्रारूप नहीं है। जाँच के दायरे से बाहर होने पर सही विकल्प हटाने के बजाय क्लाइंट के दस्तावेज़ देखें। टूल कमांड नहीं चलाता, URL नहीं खोलता और प्रमाणीकरण नहीं जाँचता।
चेतावनी सभी गोपनीय मानों का पता नहीं लगाती
आर्ग्युमेंट, एनवायरनमेंट वेरिएबल और हेडर में संवेदनशील डेटा हो सकता है। उन जगहों का संकेत न तो हर मान को गोपनीय साबित करता है, न चेतावनी न होने पर फ़ाइल को गोपनीय डेटा से मुक्त।
सार्वजनिक सहायता रिपोर्ट में असली कॉन्फ़िगरेशन न डालें। संवेदनशील हिस्से हटाकर उदाहरण दें और कनेक्ट करते समय स्रोत व अनुमतियाँ जाँचें। HTTPS और सही JSON अपने आप भरोसा नहीं बनाते।
उदाहरण: सही परिणाम का सीमित अर्थ
{"mcpServers":{"notes":{"url":"https://example.com/mcp","type":"http"}}} समर्थित प्रारूप में एक सर्वर दिखाता है। पास होना केवल संरचना का प्रमाण है; example.com उदाहरण का पता है, जाँचा हुआ MCP सर्वर नहीं।
उसी प्रविष्टि में command जोड़ने पर संचार का तरीका अस्पष्ट होने से जाँच विफल होती है। headers में {"X-Mode":"demo"} जोड़ने से संरचना सही रहती है, पर समीक्षा की चेतावनी आती है। इसका अर्थ demo को गोपनीय क्रेडेंशियल घोषित करना नहीं है।