MCP Server URL का मतलब: फ़ॉर्मेट, उदाहरण और इसे कहाँ ढूँढें

आप AI क्लाइंट में एक लिंक पेस्ट करते हैं, कनेक्ट दबाते हैं, और कुछ नहीं होता। या सेटअप स्क्रीन "MCP server URL" माँगती है और आपको पता नहीं कि यह पता कहाँ से आएगा। संक्षेप में जवाब यह है: MCP सर्वर URL एक रिमोट Model Context Protocol सर्वर का वेब पता है। यह वह सटीक एंडपॉइंट है जिसे आपका AI क्लाइंट टूल्स की सूची लेने, डेटा पढ़ने और आपकी ओर से एक्शन चलाने के लिए कॉल करता है।

यह लेख बताता है कि यह पता क्या दर्शाता है, यह कैसे बनता है, कौन से असली उदाहरणों से आप तुलना कर सकते हैं, और आपको जिस पते की ज़रूरत है वह कहाँ मिलेगा। आप उन गलतियों को भी देखेंगे जिनकी वजह से ज़्यादातर कनेक्शन फेल होते हैं, साथ ही सर्वर को दोष देने से पहले कॉन्फ़िग जाँचने का एक त्वरित तरीका भी।

MCP Server URL का मतलब

एक टूल सर्वर का पता

Model Context Protocol (MCP) एक ओपन स्टैंडर्ड है, जो किसी AI एप्लिकेशन को एक अनुमानित भाषा के ज़रिए बाहरी टूल्स से बात करने देता है। इसमें तीन भूमिकाएँ होती हैं: होस्ट (वह AI ऐप जिसे आप इस्तेमाल करते हैं), उस ऐप के अंदर चलने वाला क्लाइंट, और वह सर्वर जो टूल्स, रिसोर्स और प्रॉम्प्ट उपलब्ध कराता है। क्लाइंट और सर्वर के बीच संदेश JSON-RPC के रूप में जाते हैं।

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

इसे एंडपॉइंट क्यों कहा जाता है

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

💡 टिप: अगर सेटअप पेज "server URL," "endpoint URL," "connector URL" या "remote MCP URL" लिखता है, तो आमतौर पर उसका मतलब यही एक पता होता है।

URL आपको क्या नहीं बताता

URL टूल्स का वर्णन नहीं करता। इसमें आपका लॉगिन नहीं होता। यह बस एक दरवाज़ा है। सर्वर क्या-क्या देता है, यह तब दिखता है जब क्लाइंट कनेक्ट होकर पूछता है। इसीलिए दो मिलते-जुलते दिखने वाले पते बहुत अलग तरह से काम कर सकते हैं, और सिर्फ़ एक काम करता URL यह साबित नहीं करता कि सेटअप सही है।

फ़ॉर्मेट, एक-एक हिस्से में

MCP सर्वर URL एक मानक वेब URL है। इसके सिंटैक्स में कोई हैरानी की बात नहीं है। स्पेसिफ़िकेशन खुद यह नमूना इस्तेमाल करता है:

https://example.com/mcp

स्कीम, होस्ट और पाथ

उस नमूने को हिस्सों में बाँटें, तो हर हिस्से का एक काम है।

लोकल डेवलपमेंट सर्वर अक्सर सादा http://localhost:3000/mcp इस्तेमाल करते हैं। अपनी मशीन पर यह ठीक है। किसी बिना एन्क्रिप्ट किए पते को खुले इंटरनेट पर कभी न दिखाएँ।

/mcp और /sse बार-बार क्यों दिखते हैं

स्पेसिफ़िकेशन सिर्फ़ इतना कहता है कि एंडपॉइंट "ऊपर जैसे URL" हो सकता है। पाथ एक परंपरा है, कोई नियम नहीं। फिर भी व्यवहार में दो प्रत्यय सबसे ज़्यादा दिखते हैं:

• /mcp आमतौर पर Streamable HTTP सर्वर की ओर इशारा करता है, जो मौजूदा मानक ट्रांसपोर्ट है।
• /sse आमतौर पर पुराने HTTP+SSE ट्रांसपोर्ट की ओर इशारा करता है, जो प्रोटोकॉल वर्ज़न 2024-11-05 से है।

प्रत्यय को संकेत समझें, गारंटी नहीं। कोई प्रदाता अपना एंडपॉइंट /v1/mcp पर या किसी सबडोमेन की रूट पर प्रकाशित कर सकता है। URL को ठीक वैसा ही कॉपी करें जैसा छपा है, जिसमें आख़िरी स्लैश भी शामिल है। उदाहरण के लिए, GitHub का रिमोट सर्वर /mcp/ पर खत्म होता है।

Streamable HTTP और लीगेसी SSE

Streamable HTTP ने पुराने HTTP+SSE ट्रांसपोर्ट की जगह ले ली। नए डिज़ाइन में क्लाइंट हमेशा एक POST भेजता है, जिसमें Accept हेडर होता है, और उसमें application/json और text/event-stream दोनों लिखे होते हैं। सर्वर या तो एक JSON ऑब्जेक्ट लौटाता है या इवेंट्स की एक स्ट्रीम। सर्वर Mcp-Session-Id हेडर भी लौटा सकता है, जिसे क्लाइंट हर बाद के अनुरोध में दोहराता है, और क्लाइंट MCP-Protocol-Version हेडर भेजते हैं ताकि दोनों पक्ष स्पेसिफ़िकेशन के वर्ज़न पर सहमत रहें।

Claude Code का डॉक्युमेंटेशन अब SSE को डेप्रिकेटेड बताता है और जहाँ भी हो, HTTP सर्वरों की सिफ़ारिश करता है। कई प्रदाता पुराने क्लाइंटों के लिए /sse पता चालू रखते हैं, इसीलिए आपको दोनों तरह की शैलियाँ अब भी मिलती हैं।

💡 टिप: जो क्लाइंट पुराने सर्वरों के साथ सहज रहना चाहता है, वह उपयोगकर्ता से एक URL लेता है और पहले POST आज़माता है। अगर सर्वर 4xx एरर लौटाता है, तो वह GET पर वापस आ जाता है और SSE स्ट्रीम की उम्मीद करता है। इसी फ़ॉलबैक की वजह से वही पेस्ट किया गया URL कभी एक ऐप में चलता है और दूसरे में फेल हो जाता है।

रिमोट URL या लोकल कमांड?

हर MCP सर्वर का URL नहीं होता। यह कई लोगों को हैरान करता है, और यही समझाता है कि कुछ सेटअप पता माँगने के बजाय कमांड क्यों माँगते हैं।

Stdio सर्वरों का कोई URL नहीं होता

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

रिमोट सर्वरों को पता चाहिए

Streamable HTTP में सर्वर एक स्वतंत्र प्रोसेस के रूप में चलता है और एक साथ कई क्लाइंट संभाल सकता है। यही वह सेटअप है जहाँ URL ज़रूरी हो जाता है, क्योंकि क्लाइंट को नेटवर्क के ज़रिए सर्वर ढूँढना होता है।

दूसरे कॉलम को निर्णय के नियम की तरह इस्तेमाल करें। अगर आपका प्रदाता आपको एक कमांड लाइन देता है, तो आप stdio पर हैं। अगर वह आपको एक लिंक देता है, तो आप रिमोट ट्रांसपोर्ट पर हैं।

लोकल पतों के लिए सुरक्षा नोट्स

जब कोई सर्वर आपकी अपनी मशीन पर HTTP के ज़रिए चलता है, तो स्पेसिफ़िकेशन कहता है कि उसे 0.0.0.0 के बजाय 127.0.0.1 से बाइंड होना चाहिए, और DNS रीबाइंडिंग हमलों को रोकने के लिए उसे Origin हेडर को वैलिडेट करना होगा। सीधी भाषा में: localhost पर चलने वाला लोकल MCP सर्वर आपके नेटवर्क के दूसरे डिवाइसों से कभी पहुँच में नहीं होना चाहिए, जब तक आप जानबूझकर ऐसा न चाहें।

तुलना के लिए असली उदाहरण

नीचे दिए पते आधिकारिक डॉक्युमेंटेशन पेजों और सार्वजनिक सूचियों से लिए गए हैं। प्रदाता एंडपॉइंट बदलते रहते हैं, इसलिए इस तालिका को एक पैटर्न संदर्भ समझें और किसी भी URL पर भरोसा करने से पहले उसे प्रदाता के मौजूदा डॉक्स में जाँच लें।

ध्यान देने लायक पैटर्न

• कई प्रदाता एक समर्पित mcp. सबडोमेन इस्तेमाल करते हैं: mcp.notion.com, mcp.sentry.dev, mcp.supabase.com।
• कुछ एंडपॉइंट को मौजूदा API होस्ट से जोड़ते हैं, जैसे GitHub api.githubcopilot.com के साथ करता है।
• पाथ छोटे रहते हैं। वर्ज़न नंबर वाले लंबे पाथ अपवाद हैं।
• इनमें से किसी भी URL में कोई सीक्रेट नहीं होता। क्रेडेंशियल अलग से जाते हैं, OAuth साइन-इन के ज़रिए या Authorization हेडर में।

डॉक्स से दो कमांड

Claude Code के डॉक्स Notion और Asana के लिए ये सटीक रूप दिखाते हैं:

claude mcp add --transport http notion https://mcp.notion.com/mcp
claude mcp add --transport sse asana https://mcp.asana.com/sse

प्रॉम्प्ट कॉपी करें

एकमात्र अंतर --transport वैल्यू और पाथ का है। बाकी सब, जिसमें आपका चुना हुआ नाम भी शामिल है, आपका अपना फ़ैसला रहता है।

अपना URL कहाँ ढूँढें

चूँकि URL सर्वर के मालिक का होता है, इसलिए सबसे भरोसेमंद स्रोत हमेशा मालिक ही होता है। यह क्रम सबसे ज़्यादा समय बचाता है।

प्रदाता के डॉक्स से शुरू करें

प्रदाता के डॉक्युमेंटेशन में "MCP," "remote MCP" या "connectors" खोजें। डेवलपर पोर्टलों पर आम तौर पर एक समर्पित पेज होता है, जिसमें पते के बगल में अक्सर कॉपी बटन होता है। उस पेज पर /mcp या /sse प्रत्यय सीधे लिखा होता है, इसलिए आपको अंदाज़ा नहीं लगाना पड़ता।

प्रोडक्ट के अंदर देखें

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

रिपॉज़िटरी का README पढ़ें

ओपन-सोर्स सर्वर खुद को README फ़ाइल में समझाते हैं। "Usage," "Installation" या "Configuration" नाम का हिस्सा खोजें। अगर README में सिर्फ़ command और args दिखे, तो सर्वर सिर्फ़ stdio है और जब तक कोई उसे डिप्लॉय न करे, उसका कोई सार्वजनिक URL नहीं होता।

रजिस्ट्री या डायरेक्टरी में खोजें

MCPservers.org जैसी सार्वजनिक डायरेक्टरियाँ रिमोट MCP सर्वरों और उनके एंडपॉइंट की सूचियाँ रखती हैं। उम्मीदवार ढूँढने के लिए इनका इस्तेमाल करें, फिर पते को प्रदाता के अपने डॉक्स से मिलाएँ। डायरेक्टरी की प्रविष्टियाँ पुरानी हो सकती हैं।

किसी मौजूदा क्लाइंट से पूछें

अगर किसी साथी ने पहले ही सर्वर कनेक्ट किया है, तो उससे Claude Code में claude mcp list या claude mcp get <name> चलाने को कहें। ये दोनों कमांड दिखाते हैं कि सर्वर कैसे कॉन्फ़िगर है, और वहीं आप पता पहचान सकते हैं। चल रहे सेशन के भीतर /mcp कमांड हर सर्वर की स्थिति दिखाता है।

क्लाइंट में URL जोड़ना

एक बार सही पता हाथ में हो, तो सेटअप एक मिनट से कम लेता है। लगभग हर क्लाइंट के लिए तीन रास्ते ठीक बैठते हैं।

कमांड लाइन सेटअप

Claude Code को ट्रांसपोर्ट, एक नाम और URL चाहिए:

claude mcp add --transport http <name> <url>

प्रॉम्प्ट कॉपी करें

हर अनुरोध के साथ टोकन भेजने के लिए एक हेडर जोड़ें:

claude mcp add --transport http secure-api https://api.example.com/mcp \
  --header "Authorization: Bearer your-token"

प्रॉम्प्ट कॉपी करें

कॉन्फ़िग फ़ाइल सेटअप

ज़्यादातर क्लाइंट एक JSON फ़ाइल भी पढ़ते हैं। फ़ील्ड के नाम ऐप-दर-ऐप अलग होते हैं, इसलिए अपने क्लाइंट के डॉक्स जाँचें, पर ढाँचा लगभग इसी जैसा होता है:

{
  "mcpServers": {
    "notion": {
      "type": "http",
      "url": "https://mcp.notion.com/mcp"
    },
    "local-files": {
      "command": "npx",
      "args": ["-y", "example-mcp-package"]
    }
  }
}

प्रॉम्प्ट कॉपी करें

पहली एंट्री रिमोट है और url इस्तेमाल करती है। दूसरी stdio है और command इस्तेमाल करती है। हर एंट्री में एक ही शैली रखें।

चैट ऐप्स में कनेक्टर स्क्रीन

कस्टम कनेक्टर स्क्रीन वाले चैट ऐप आम तौर पर दो चीज़ें माँगते हैं: एक नाम और URL। पता पेस्ट करें, सेव करें, और अगर साइन-इन का प्रॉम्प्ट आए तो उसे पूरा करें। और कुछ नहीं चाहिए, क्योंकि कनेक्शन खुलते ही ऐप टूल्स खुद ढूँढ लेता है।

सामान्य URL गलतियाँ और उनके समाधान

ज़्यादातर फ़ेल कनेक्शन कुछ छोटे कारणों से होते हैं। कुछ भी और छूने से पहले इन्हें इसी क्रम में जाँचें।

गलत पाथ या प्रत्यय गायब

सिर्फ़ होस्ट नाम, जैसे https://mcp.example.com, अक्सर काफ़ी नहीं होता। क्लाइंट को सटीक एंडपॉइंट पाथ चाहिए। अगर 404 मिलता है, तो प्रदाता के मौजूदा डॉक्स से पता फिर से कॉपी करें और अक्षर-दर-अक्षर मिलाएँ, आख़िरी स्लैश समेत।

API और MCP पते आपस में मिलाना

सामान्य REST API बेस URL कोई MCP URL नहीं है। https://api.example.com/v1 जैसा बेस सामान्य अनुरोध संभालता है और MCP ट्रांसपोर्ट पर JSON-RPC नहीं बोलता। अगर कोई प्रदाता दोनों देता है, तो डॉक्स उन्हें अलग पेजों पर लिखते हैं। MCP server URL लिखे फ़ील्ड में कभी API बेस न डालें और उम्मीद न करें कि टूल्स दिखेंगे।

क्रेडेंशियल गायब होना

सही URL भी इस्तेमाल की अनुमति के बिना फ़ेल होगा। जब आपका टोकन गायब या समाप्त हो, तो सर्वर 401 लौटाता है, और जब आपका अकाउंट उस वर्कस्पेस तक नहीं पहुँच सकता, तो 403। क्लाइंट के ज़रिए फिर से साइन इन करें, या Authorization हेडर में भेजे जा रहे Bearer टोकन को रीफ़्रेश करें।

💡 टिप: टोकन URL से बाहर रखें। अगर कोई प्रदाता आपसे क्वेरी स्ट्रिंग में सीक्रेट पेस्ट करने को कहे, तो उस लिंक को पासवर्ड की तरह समझें और उसे स्क्रीनशॉट या टिकट में कभी साझा न करें।

त्वरित लक्षण तालिका

एक बारीकी बहुत उलझन बचाती है: स्पेसिफ़िकेशन सर्वर को अनुमति देता है कि वह GET का जवाब 405 से दे और बताए कि उस एंडपॉइंट पर SSE स्ट्रीम उपलब्ध नहीं है। इसलिए अकेले GET पर 405 हमेशा खराबी हो, ऐसा नहीं होता।

PicassoIA और व्यवहार में MCP

API पता बनाम MCP पता

PicassoIA https://api.picassoia.com/v1 पर एक डेवलपर API प्रकाशित करता है। यह Replicate-शैली के एंडपॉइंट इस्तेमाल करता है, जैसे POST /v1/models/{owner}/{name}/predictions और GET /v1/predictions/{id}, और pia_sk_ से शुरू होने वाले Bearer टोकन से प्रमाणित करता है। वह पता REST API का है। वह नहीं MCP सर्वर URL है, इसलिए उसे MCP फ़ील्ड में न डालें।

MCP कनेक्शन आपके अकाउंट से picassoia.com/en/mcp/accounts पर प्रबंधित होते हैं, जिसके लिए लॉगिन चाहिए। MCP सर्वर URL सार्वजनिक पेजों पर नहीं छपा होता, इसलिए अंदाज़े से पता लेने के बजाय वहीं से शुरू करें। प्लान के नियम लागू होते हैं, इसलिए देखें कि आपके प्लान में क्या शामिल है।

MCP से आप क्या पहुँच सकते हैं

चार मॉडल API और MCP, दोनों के ज़रिए उपलब्ध हैं:

• PicassoIA Image टेक्स्ट से इमेज जनरेशन के लिए।
• PicassoIA Image Editor Pro किसी मौजूदा तस्वीर को एडिट करने के लिए।
• PicassoIA Video टेक्स्ट या इमेज से वीडियो के लिए।
• Seedance 2.5 Lite ऑडियो के साथ वीडियो के लिए।

जॉब्स असिंक्रोनस चलते हैं: आप एक प्रेडिक्शन बनाते हैं, उसकी स्थिति जाँचते हैं, फिर नतीजा लाते हैं। हर अकाउंट के लिए एक साथ 5 प्रेडिक्शन की सीमा है, जो सभी टोकन और MCP कनेक्शनों में साझा होती है, और प्रॉम्प्ट 4,000 अक्षरों तक हो सकते हैं।

Claude Sonnet 5 से अपना कॉन्फ़िग जाँचें

Claude Sonnet 5 मॉडल कोडिंग और टूल यूज़ के कामों को संभालता है, इसलिए कॉन्फ़िग फ़ाइल के लिए यह एक उपयोगी दूसरी नज़र बन जाता है। PicassoIA पर एक छोटी प्रक्रिया यह है:

1. Claude Sonnet 5 पेज खोलें और Prompt फ़ील्ड में अपना अनुरोध लिखें।
2. कॉन्फ़िग चिपकाएँ, जिसमें हर टोकन की जगह एक प्लेसहोल्डर हो। कभी असली सीक्रेट न चिपकाएँ।
3. एक सटीक सवाल पूछें: "क्या हर एंट्री stdio है या रिमोट, और क्या पाथ सही लगता है?"
4. effort स्तर चुनें। त्वरित जाँच के लिए Low ठीक है; कई सर्वरों वाली उलझी फ़ाइल के लिए medium या high बेहतर है।
5. चाहें तो System Prompt जोड़ें, जैसे "आप MCP कॉन्फ़िग की समीक्षा करते हैं और गलत ट्रांसपोर्ट बताते हैं।"
6. अगर आपके पास एरर का स्क्रीनशॉट है, तो उसे Image फ़ील्ड में लगाएँ, फिर चलाएँ और जवाब की तुलना प्रदाता के डॉक्स से करें।

💡 टिप: जवाब को फ़ैसले के बजाय एक सुराग समझें। अगर दोनों में फ़र्क हो, तो प्रदाता के डॉक्स हमेशा ही अंतिम माने जाएँगे।

अगर आप दूसरी राय चाहते हैं, तो GPT 5.6 Sol भी इसी तरह काम करता है।

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

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