किसी भी MCP सर्वर को Claude Code और Claude Desktop से कनेक्ट करें

किसी MCP सर्वर को Claude Code और Claude Desktop दोनों से जोड़ना सिर्फ़ वही कॉन्फ़िगरेशन दो जगह कॉपी करने से कहीं ज़्यादा है।

Claude Code में MCP सर्वर को अलग-अलग स्कोप में कॉन्फ़िगर किया जा सकता है, जिनमें local, project और user स्तर शामिल हैं। कॉन्फ़िगरेशन हो जाने के बाद भी सर्वर को मंज़ूरी देनी पड़ सकती है, तभी आप जाँच पाएँगे कि वह असल में कनेक्ट हुआ है या नहीं। Claude Desktop इसे अलग ढंग से संभालता है: स्थानीय MCP सर्वर Extensions या Developer कॉन्फ़िग के ज़रिए लोड हो सकते हैं, जबकि रिमोट सर्वर अलग कनेक्शन प्रक्रिया से चलते हैं। नतीजा यह है कि Claude Code में चलने वाला MCP सर्वर अपने आप Claude Desktop में उपलब्ध नहीं हो जाता।

उलझन की एक और आम वजह यह है कि “added”, “approved”, “connected” और “able to complete the task” को एक ही चीज़ मान लिया जाता है। ये अलग-अलग अवस्थाएँ हैं।

“Added” का मतलब सिर्फ़ इतना है कि कॉन्फ़िगरेशन दर्ज हो गया। “Pending approval” का मतलब है कि सर्वर अब भी मंज़ूरी का इंतज़ार कर रहा है। “Connected” का मतलब है कि MCP कनेक्शन सफलतापूर्वक बन गया। लेकिन इन सभी चरणों के अपेक्षित रूप से काम करने पर भी एजेंट असल कार्य पूरा करने में असमर्थ रह सकता है।

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

यह वह परत है जिसे संभालने के लिए ego (lite) बनाया गया है। एजेंट ऐसे असली ब्राउज़र एनवायरनमेंट के भीतर काम जारी रख सकता है जिसमें कार्य की ज़रूरत वाली स्थिति पहले से मौजूद है, जिसमें मौजूदा लॉगिन सत्र और वर्तमान पेज की स्थिति शामिल है। ऐसे MCP कॉन्फ़िगरेशन को बार-बार बदलने के बजाय जो पहले से काम कर रहा है, एजेंट सीधे ब्राउज़र वाले कार्य पर आगे बढ़ सकता है।

इसलिए MCP की गड़बड़ी सुलझाते समय यहीं न रुकें कि सर्वर “Connected” दिखा रहा है या नहीं। पहचानें कि असल में कौन सी परत विफल हो रही है: क्या सर्वर जोड़ा गया है? क्या उसे मंज़ूरी मिली है? क्या वह कनेक्ट है? और क्या ब्राउज़र के पास कार्य पूरा करने के लिए ज़रूरी स्थिति है?

आप असल में क्या कनेक्ट कर रहे हैं

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

प्रोटोकॉल ख़ुद modelcontextprotocol.io पर परिभाषित है, जो ट्रांसपोर्ट, क्षमताओं और client-server अनुबंध की संदर्भ सामग्री है।

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

कुछ भी टाइप करने से पहले स्कोप चुनें

Claude Code सर्वर परिभाषा रखने के लिए तीन जगह देता है, और ग़लत जगह चुनना ही सर्वर के “गायब” होने की सबसे आम वजह है: वह ठीक-ठाक कनेक्ट हुआ था, मगर ऐसी डायरेक्टरी में जहाँ आप अब नहीं हैं।

local डिफ़ॉल्ट है। जब आप ऐसा सर्वर परख रहे हों जिसके बारे में पक्का न हों, तब इसका इस्तेमाल करें, और ऐसी हर चीज़ के लिए भी जिसमें ऐसा क्रेडेंशियल हो जिसे आप रिपॉज़िटरी में नहीं रखना चाहते। project तब चुनें जब सर्वर सचमुच उस कोडबेस का हिस्सा हो, जैसे टीम रेपो के लिए कोई प्रोजेक्ट-मैनेजमेंट सर्वर, क्योंकि वह प्रविष्टि चेकआउट के साथ चलती है और हर टीममेट को एक बार अनुमोदन संकेत मिलता है। user उन सर्वरों के लिए चुनें जो कोड के नहीं, आपके बारे में हैं: कोई पर्सनल नोट्स सर्वर, घर के लैब का एंडपॉइंट, या वह चीज़ जो आपको हर सत्र में चाहिए।

डुप्लिकेट बनाने से पहले एक बात अच्छी तरह समझ लें: जब एक ही सर्वर नाम एक से ज़्यादा जगह मौजूद हो, तो Claude Code एक ही बार कनेक्ट करता है और सबसे ऊँची प्राथमिकता वाले स्रोत से पूरी प्रविष्टि उठा लेता है। प्राथमिकता का क्रम local, फिर project, फिर user, फिर plugin से आने वाले सर्वर है। फ़ील्ड आपस में मिलाए नहीं जाते, इसलिए जिस project प्रविष्टि में कोई वैकल्पिक key नहीं है, उसे किसी ज़्यादा पूर्ण user प्रविष्टि से चुपचाप पूरा नहीं किया जाता; जो चलता है वह पूरी project प्रविष्टि होती है।

Claude Code में सर्वर जोड़ें

Claude Code एक ही कमांड देता है जिसके कई रूप होते हैं, यह इस पर निर्भर करता है कि सर्वर कैसे दिया गया है। HTTP पर चलने वाला रिमोट सर्वर सबसे आसान मामला है, क्योंकि स्थानीय तौर पर चलाने के लिए कुछ है ही नहीं:

# Remote server over HTTP (the recommended transport)
claude mcp add --transport http <name> <url>

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

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

# Local server as a child process
claude mcp add [options] <name> -- <command> [args...]

# Real shape, with an environment variable
claude mcp add --env API_KEY=your-key --transport stdio airtable \
  -- npx -y airtable-mcp-server

जब सर्वर विक्रेता आपको JSON स्निपेट देता है, जो ज़्यादातर मामलों में होता है क्योंकि एक ही स्निपेट हर MCP क्लाइंट में काम करता है, तो आप उसे फ़्लैग में बदलने के बजाय सीधे पेस्ट कर सकते हैं। पास करें वह ऑब्जेक्ट जो mcpServers के अंदर है, उसे घेरने वाला wrapper नहीं:

claude mcp add-json weather-api \
  '{"type":"http","url":"https://api.weather.com/mcp","headers":{"Authorization":"Bearer token"}}'

दो फ़्लैग जानने लायक हैं, हालाँकि दोनों में से कोई ज़रूरी नहीं है। स्कोप फ़्लैग तय करता है कि प्रविष्टि कहाँ जाएगी, और उसे दोनों तरह से लिखा जा सकता है:

claude mcp add --transport http stripe --scope local https://mcp.stripe.com
claude mcp add --transport http notion -s user https://mcp.notion.com/mcp

एक ही कमांड के दो रूपों में अक्सर भ्रम हो जाता है। सादा add कमांड उस नाम वाली प्रविष्टि को पूरी तरह फिर से लिख देता है, जो तब चाहिए जब विक्रेता ने अपना URL बदल दिया हो। add-json रूप वही ऑब्जेक्ट लेता है और उसे एक ही प्रविष्टि के रूप में रखता है, जो तब चाहिए जब सर्वर को एक साथ कई फ़ील्ड चाहिए:

जाँचें कि कनेक्शन असल में बना या नहीं

सफल add एक Added लाइन छापता है, और उस लाइन का मतलब सिर्फ़ इतना है: कॉन्फ़िगरेशन डिस्क पर लिख दिया गया था। इससे यह पता नहीं चलता कि सर्वर चलता है या नहीं। असली सवाल का जवाब list कमांड देता है, जो हर सर्वर का हेल्थ स्टेटस बताता है: connected, authentication चाहिए, या कनेक्ट करने में विफल:

हर सबकमांड के लिए कमांड-स्तर का संदर्भ है Claude Code का आधिकारिक MCP दस्तावेज़, जिसे इस वॉकथ्रू के साथ पढ़ना फ़ायदेमंद रहेगा।

इस गाइड में उदाहरण के तौर पर इस्तेमाल किए गए ब्राउज़र सर्वर के इंस्टॉल और रजिस्ट्रेशन के चरण यहाँ दिए हैं: Claude Code और Cursor के लिए Playwright MCP सेटअप गाइड।

claude mcp list          # health status for every configured server
claude mcp get notion    # detail for one server, including its Issue line

जब कोई स्टेटस विफलता दिखाता है, तो list कमांड उसी लाइन में विफलता का विवरण जोड़ देता है, और सिंगल-सर्वर व्यू उसे किसी Issue लाइन पर HTTP स्टेटस या एरर कोड के साथ दोहराता है, साथ में सर्वर से लौटा जो भी टेक्स्ट हो। उस विवरण को ही मुख्य सबूत मानें, अपनी JSON दोबारा पढ़ने के बजाय। उसमें से क्रेडेंशियल जैसा टेक्स्ट हटा दिया जाता है, और खुला हुआ URL जानबूझकर कभी शामिल नहीं किया जाता, क्योंकि URL अपनी query string में कोई सीक्रेट ले जा सकता है।

हर स्टेटस कनेक्शन की कोशिश से नहीं आता। कुछ कॉन्फ़िगरेशन का फ़ैसला बताते हैं, और Claude Code उन्हें सर्वर से संपर्क किए बिना ही छाप देता है। साझा फ़ाइल से आया project स्कोप वाला सर्वर तब तक अनुमोदन लंबित पर रहता है जब तक आप इंटरैक्टिव क्लाइंट एक बार चला कर संकेत स्वीकार न करें। आपकी सेटिंग्स में disabled दर्ज सर्वर इस प्रोजेक्ट के लिए disabled दिखता है और ऐप के अंदर वाले पैनल से वापस आ जाता है। किसी सेटिंग प्रविष्टि से अस्वीकार किया गया सर्वर सिंगल-सर्वर व्यू में दिखता है पर list में नहीं, और यह फ़र्क तब काम आता है जब कोई ऐसा सर्वर जिसे आपने जोड़ा था, गायब लगने लगे।

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

WebSocket सर्वर ऊपर कही हर बात का अपवाद हैं: वे list के आउटपुट में बिल्कुल नहीं दिखते। उन्हें जाँचने के लिए सिंगल-सर्वर व्यू या ऐप के अंदर वाला पैनल इस्तेमाल करें।

वही सर्वर Claude Desktop में जोड़ें

Desktop बिल्कुल अलग जानवर है, और लोग जहाँ अटकते हैं वह यह बदलाव है कि स्थानीय सर्वर के लिए इसका मुख्य प्रलेखित रास्ता अब JSON फ़ाइल नहीं है। अब का तरीका पैकेज किए गए एक्सटेंशन हैं: Settings खोलें, Extensions पर जाएँ, डायरेक्टरी ब्राउज़ करें या developer सेक्शन से बंडल किया हुआ .mcpb पैकेज इंस्टॉल करें, फिर पैकेज जो भी सेटिंग्स माँगे वे भर दें। API key जैसे ज़रूरी मान इंटरफ़ेस से ही लिए जाते हैं, और संवेदनशील फ़ील्ड ऑपरेटिंग सिस्टम के सुरक्षित store से एन्क्रिप्ट रहते हैं। डायरेक्टरी वाले एक्सटेंशन ख़ुद अपडेट हो जाते हैं; निजी तौर पर बाँटे गए एक्सटेंशन के लिए नया वर्शन आने पर मैन्युअल रीइंस्टॉल करना पड़ता है।

अगर कोई विक्रेता अब भी आपको JSON स्निपेट देता है और कोई पैकेज नहीं, तो मैन्युअल रास्ता गया नहीं है, वह जगह बदल चुका है। डेस्कटॉप ऐप का मेन्यू खोलें, Settings चुनें, फिर Developer, और edit-config कंट्रोल इस्तेमाल करें, जो फ़ाइल मौजूद न हो तो बना देता है और हो तो खोल देता है। macOS पर वह फ़ाइल यहाँ रहती है: ~/Library/Application Support/Claude/claude_desktop_config.json; Windows पर वह यहाँ रहती है: %APPDATA%\Claude\claude_desktop_config.json। ज़्यादातर स्थानीय सर्वर npx से लॉन्च होते हैं और उनके लिए Node.js इंस्टॉल होना चाहिए, और ऐप यह फ़ाइल सिर्फ़ शुरू होते समय पढ़ता है, इसलिए पूरी तरह बंद करके दोबारा चलाना कोई अंधविश्वासी अतिरिक्त कदम नहीं, प्रक्रिया का हिस्सा है।

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

व्यक्तिगत अकाउंट के लिए रास्ता customization सेटिंग्स की connectors स्क्रीन है, जहाँ आप कस्टम कनेक्टर जोड़ते हैं और सर्वर का URL पेस्ट करते हैं; एक advanced सेक्शन OAuth client ID और secret लेता है, अगर सर्वर dynamic client registration का समर्थन नहीं करता। संगठन प्लान पर कोई owner कनेक्टर को संगठन स्तर पर जोड़ता है और सदस्य फिर अपने-अपने हिसाब से प्रमाणित होते हैं। प्लान की सीमाएँ लागू होती हैं: मुफ़्त अकाउंट सिर्फ़ एक कस्टम कनेक्टर तक सीमित है, और कनेक्टर तब तक custom दिखता है जब तक उसका डोमेन डायरेक्टरी की किसी लिस्टिंग से मेल न खाए।

वह कॉन्फ़िग ढाँचा जिस पर दोनों ऐप सहमत हैं

इन अलग-अलग सतहों के नीचे प्रविष्टि वही एक ऑब्जेक्ट होती है। रिमोट सर्वर एक type, एक URL और वैकल्पिक headers होता है। स्थानीय सर्वर एक command, उसके args और वैकल्पिक environment ब्लॉक होता है। जब विक्रेता का दस्तावेज़ और आपकी फ़ाइल आपस में न मिलें, तो तुलना इसी ढाँचे से करें:

{
  "mcpServers": {
    "remote-example": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "headers": { "Authorization": "Bearer YOUR_TOKEN" }
    },
    "local-example": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@example/mcp-server"],
      "env": { "CACHE_DIR": "/tmp" }
    }
  }
}

उस ऑब्जेक्ट में तीन बातें ज़्यादातर टाली जा सकने वाली विफलताओं की वजह बनती हैं। stdio प्रविष्टि में अगर command में रिलेटिव पथ हो, तो काम करने वाली डायरेक्टरी बदलते ही वह टूट जाती है, इसलिए absolute पथ इस्तेमाल करें। JSON स्ट्रिंग के अंदर Windows पथ के backslash escaped होने चाहिए, वरना फ़ाइल ग़लत स्ट्रिंग के रूप में पार्स होती है। और जिस रिमोट प्रविष्टि में type बिल्कुल न हो, उसे स्थानीय सर्वर मानकर पढ़ा जाता है, जिससे URL के बारे में कुछ भी कहने के बजाय missing command वाली उलझाने वाली गलती आती है।

दोनों ऐप जहाँ अलग होते हैं वह नामकरण है। Claude Code ऐसे नाम माँगता है जो अक्षरों, अंकों, हाइफ़न और अंडरस्कोर से बने हों, जबकि डेस्कटॉप कॉन्फ़िग की key ज़्यादा उदार है। दोनों जगह नाम एक जैसा रखना अपने नोट्स सीधे रखने का सबसे सस्ता तरीका है।

क्रेडेंशियल, वेरिएबल और ${VAR} में छिपा जाल

कॉन्फ़िग फ़ाइल में टोकन हार्ड-कोड करना ही वह तरीका है जिससे सीक्रेट रिपॉज़िटरी में पहुँच जाते हैं, इसलिए MCP कॉन्फ़िग वेरिएबल एक्सपैंशन का समर्थन करते हैं। इसका सिंटैक्स दो रूपों में है, एक सादा और एक डिफ़ॉल्ट वाला, और एक्सपैंशन command, उसके arguments, environment ब्लॉक, URL और headers सब पर लागू होता है:

{
  "mcpServers": {
    "api-server": {
      "type": "http",
      "url": "${API_BASE_URL:-https://api.example.com}/mcp",
      "headers": { "Authorization": "Bearer ${API_KEY}" }
    }
  }
}

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

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

project स्कोप वाली प्रविष्टियों के लिए एक दूसरा, ज़्यादा सीमित नियम है: किसी command या argument में project-डायरेक्टरी वेरिएबल का ज़िक्र करने पर उसके लिए डिफ़ॉल्ट देना ज़रूरी है, क्योंकि प्रविष्टि पढ़े जाने के समय वह मान सेट होगा, इसकी गारंटी नहीं है। plugin से आने वाले कॉन्फ़िग उसे सीधे बदल देते हैं और इसी शर्त के अधीन नहीं हैं।

कनेक्शन की गड़बड़ियाँ ठीक करना

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

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

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

ट्रांसपोर्ट सर्वर तक नहीं पहुँच पाता। किसी रिमोट एंडपॉइंट के लिए पहले पक्का करें कि URL सेवा की जड़ नहीं बल्कि MCP पथ है, फिर देखें कि क्रेडेंशियल वाक़ई पहुँच रहा है। सामने वाले सिरे से आया 401 या 403 इस पूरी गाइड का सबसे साफ़ संकेत है: क्लाइंट सर्वर तक पहुँच गया और सर्वर ने कॉलर को अस्वीकार कर दिया, जो आपको सीधे ऊपर वाले क्रेडेंशियल सेक्शन पर ले जाता है। connection refused या resolution failure उलटी दिशा में इशारा करता है, यानी पते या फ़ायरवॉल की ओर।

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

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

कोई project सर्वर किसी और के लिए कनेक्ट नहीं होता। यह ट्रस्ट गेट है, कोई टूटी प्रविष्टि नहीं। किसी टीममेट के ताज़ा क्लोन को वर्कस्पेस पर भरोसा करके साझा प्रविष्टि एक बार मंज़ूर करनी पड़ती है। अगर उन्होंने ऐसा नहीं किया, तो सर्वर अनुमोदन लंबित दिखता है और हेल्थ चेक कभी चलता ही नहीं।

जब MCP सर्वर को ब्राउज़र सत्र चाहिए

ब्राउज़र की ओर काम करने वाले सर्वरों में चौथा चरण ही पूरी कहानी बन जाता है। सर्वर कनेक्ट हो जाता है, ट्रांसपोर्ट ठीक है, हैंडशेक पूरा हो जाता है, टूल सूची भर जाती है, और कार्य फिर भी विफल होता है, क्योंकि जिस ब्राउज़र को वह चलाता है उसमें साइन-इन सत्र नहीं है, या उसने जो प्रोफ़ाइल खोला वह वही नहीं है जिसमें आपके cookies हैं। क्लाइंट में हर लक्षण ठीक दिखता है।

उस उदाहरण में जो सर्वर है वह microsoft/playwright-mcp, जहाँ उसकी टूल सूची और ज्ञात समस्याएँ ट्रैक होती हैं।

Claude Code के अंदर एजेंट किस-किस तरह ब्राउज़र तक पहुँच सकता है, इसके बड़े सेट के लिए देखें पाँच ब्राउज़र रास्तों की तुलना।

इसी परत पर ego (lite) काम करता है, और यह साफ़ रखना ज़रूरी है कि यह असल में कौन सा उत्पाद है। यह MCP सर्वर नहीं है और कोई टूल पंजीकृत नहीं करता: यह ऐसा ब्राउज़र है जो इस तरह बनाया गया है कि एजेंट उसी ब्राउज़र के भीतर काम करे जिसमें आपके लॉगिन पहले से हैं, न कि उसके बगल में खड़े ताज़ा ऑटोमेशन प्रोफ़ाइल में। एजेंट और उस ब्राउज़र के बीच का कनेक्शन, एजेंट और उसके टूल के बीच के कनेक्शन से अलग मामला है। MCP कनेक्शन Claude Code या Claude Desktop के पास रहता है; ego-browser ब्राउज़र सत्र रखता है, और ये सत्र अलग-अलग Space में रहते हैं ताकि एजेंट का काम उस विंडो से न टकराए जिसे आप इस्तेमाल कर रहे हैं। जब कोई ब्राउज़र MCP सर्वर खाली पेज, लॉगिन रीडायरेक्ट या ऐसा एलिमेंट लौटाए जिसे वह देख ही न पाए, तो समाधान लगभग हमेशा सीमा के उस पार होता है, न कि उस कॉन्फ़िग में जिसे आपने अभी जाँचा है।

अगर आपने अभी तक कोई ब्राउज़र सर्वर नहीं चुना है, तो Claude Code के लिए ब्राउज़र MCP की तुलना मौजूदा विकल्पों को इस आधार पर क्रम देती है कि हर एक कहाँ तक पहुँच सकता है और उसकी लागत क्या है।

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

हर परत के फ़ायदे-नुक़सान यहाँ विस्तार से समझाए गए हैं: MCP बनाम CLI और ब्राउज़र एक्सटेंशन कहाँ फ़िट होते हैं।

सर्वर कनेक्ट होने पर आप क्या अनुमति दे रहे हैं

सर्वर कनेक्ट करना एक क्षमता देना है, और ऊपर वाली स्कोप तालिका अनुमति तालिका का भी काम करती है। user स्कोप वाला सर्वर आपके खोले हर प्रोजेक्ट में मौजूद रहता है, उनमें भी जो आपने लिखे नहीं। project स्कोप वाला सर्वर हर उस व्यक्ति के लिए मौजूद होता है जो रिपॉज़िटरी क्लोन करे। दोनों में से कोई बात अपने आप में बुरी नहीं है, पर सेटअप के महीने भर बाद दोनों भूल जाना आसान है।

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

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

सर्वर परिभाषाएँ कनेक्ट होते ही context भी खर्च करती हैं; MCP टोकन का इस्तेमाल कम कैसे करें में इस सौदे का यह पक्ष समझाया गया है।

यूज़र इंटरफ़ेस इस फ़र्क को और साफ़ करता है: रिमोट कनेक्टर विक्रेता के क्लाउड से चलता है, और उतनी ही नेटवर्क पहुँच रखता है; जबकि स्थानीय सर्वर आपकी मशीन पर आपके अकाउंट की अनुमतियों के साथ चलता है। इसीलिए रिमोट कनेक्टर के लिए सुरक्षा सवाल यह है कि उस एंडपॉइंट तक और कौन पहुँच सकता है, और स्थानीय सर्वर के लिए सवाल यह है कि वह प्रोसेस क्या-क्या छू सकता है।

अक्सर पूछे जाने वाले प्रश्न

क्या एक ही MCP सर्वर Claude Code और Claude Desktop दोनों में इस्तेमाल किया जा सकता है?

हाँ, बशर्ते आप हर ऐप को अलग-अलग कॉन्फ़िगर करें। दोनों क्लाइंट अलग कॉन्फ़िगरेशन पढ़ते हैं, इसलिए Claude Code में सर्वर जोड़ने का Desktop पर कोई असर नहीं पड़ता, और डेस्कटॉप एक्सटेंशन इंस्टॉल करने से सर्वर Claude Code के लिए उपलब्ध नहीं हो जाता। दोनों जगह बनाए रखने के लिए रिमोट सर्वर सबसे सस्ता है, क्योंकि एक ही URL दोनों में चलता है और सिर्फ़ आसपास की प्रविष्टि अलग होती है।

सर्वर असल में कहाँ चलता है?

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

सर्वर अनुमोदन लंबित में क्यों दिखता है?

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

क्या SSE अब भी काम करता है, या मुझे माइग्रेट करना चाहिए?

SSE ट्रांसपोर्ट पुराना हो चुका है पर अब भी स्वीकार किया जाता है। जहाँ सर्वर दोनों एंडपॉइंट देता हो, वहाँ HTTP ट्रांसपोर्ट बेहतर विकल्प है, और हाल के वर्शनों में क्लाइंट HTTP को प्राथमिकता देता है और सर्वर के स्वीकार न करने पर SSE पर लौट आता है। माइग्रेशन के लिए प्रविष्टि के type और URL में एक लाइन का बदलाव चाहिए, रीइंस्टॉल नहीं।

सर्वर मेरे टर्मिनल में चलता है पर ऐप में क्यों नहीं?

लगभग हमेशा इसलिए क्योंकि ऐप को वह एनवायरनमेंट नहीं मिलता जो आपके शेल के पास था। आपके टर्मिनल में एक PATH और कुछ export किए गए वेरिएबल होते हैं जो कोई GUI ऐप कभी नहीं देखता, इसलिए बिना पूरा पथ दिए लॉन्च किया गया सर्वर एक जगह हल होता है और दूसरी जगह नहीं। कमांड के लिए absolute पथ इस्तेमाल करें, और सर्वर को जो वेरिएबल चाहिए वे आसपास के शेल पर छोड़ने के बजाय उसके environment ब्लॉक से पास करें।

किसी सर्वर को साफ़-सुथरे तरीके से कैसे हटाएँ?

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

क्या मैं project का .mcp.json रिपॉज़िटरी में कमिट कर सकता हूँ?

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

Claude Code में जोड़ा गया सर्वर Claude Desktop को क्यों नहीं दिखता?

क्योंकि दोनों ऐप अलग-अलग कॉन्फ़िगरेशन पढ़ते हैं। CLI से रजिस्टर किया सर्वर Claude Code की अपनी स्कोप फ़ाइलों में रहता है, और Desktop सिर्फ़ अपने एक्सटेंशन और अपनी Developer कॉन्फ़िग पढ़ता है। सर्वर को Desktop की ओर दोबारा जोड़ें, या दोनों को एक ही रिमोट URL पर इंगित करें ताकि बनाए रखने के लिए एक ही परिभाषा रहे।

कॉन्फ़िग फ़ाइल संपादित करने के बाद ऐप को दोबारा चलाना ज़रूरी है?

Claude Code अपनी सर्वर परिभाषाएँ अपने ही कमांडों से पढ़ता और लिखता है, इसलिए मैन्युअल रीस्टार्ट की ज़रूरत नहीं है। Claude Desktop अपनी मैन्युअल कॉन्फ़िग फ़ाइल शुरू होते समय पढ़ता है, इसलिए ऐप के बाहर किया गया बदलाव रीस्टार्ट के बाद ही लागू होता है।

सर्वर सूची में needs authentication का क्या मतलब है?

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