Cursor 40 MCP टूल के बाद चेतावनी देता है, VS Code 128 से ज़्यादा रिक्वेस्ट रद्द कर देता है, और Claude Code टूल सर्च से टूल डेफ़िनिशन को टालता है। यह लेख हर लिमिट, हर टूल की टोकन लागत और उन तरीकों को बताता है जिनसे एक भरे सेटअप को सीमा के भीतर रखा जा सकता है।
एक और MCP सर्वर जोड़ते ही आपका एजेंट अचानक फ़ाइल पढ़ना भूल सकता है। कोई क्रैश नहीं, कोई लाल बैनर नहीं, बस एक टूल जो कल था और आज नहीं है। यही MCP टूल लिमिट का असर है, और हर एडिटर इसे अलग तरीके से संभालता है। Cursor 40 टूल के बाद चेतावनी देता है, VS Code 128 से ज़्यादा रिक्वेस्ट को रद्द कर देता है, और Claude Code चुपचाप ज़्यादातर टूल डेफ़िनिशन को तब तक टालता है जब तक मॉडल उन्हें माँगे।
यह लेख हर क्लाइंट के असली आँकड़े देता है, लिमिट पार होने पर दिखने वाले संदेश बताता है, लिमिट के पीछे का टोकन गणित समझाता है, और कुछ छोटे तरीके देता है जिनसे एक भरे सेटअप को सीमा के भीतर रखा जा सके।
💡 त्वरित राय: Cursor में 40 टूल, VS Code में 128 और Windsurf में 100 को ध्यान में रखकर योजना बनाएँ। Claude Code को "कोई तय संख्या नहीं, लेकिन टूल सर्च चालू न हो तो हर डेफ़िनिशन फिर भी कॉन्टेक्स्ट खाता है" की तरह समझें। लिमिट रिलीज़ के साथ बदलती रहती हैं, इसलिए अपने इंस्टॉल किए गए वर्ज़न से मिलान कर लें।
आधिकारिक डॉक्स और कम्युनिटी थ्रेड अक्टूबर 2026 तक की स्थिति यह बताते हैं।
| क्लाइंट | टूल लिमिट | लिमिट पार होने पर क्या होता है |
|---|---|---|
| Cursor | सभी सक्षम MCP सर्वरों में मिलाकर 40 टूल | एक चेतावनी दिखती है और एजेंट तक सिर्फ़ पहले 40 टूल पहुँचते हैं |
| VS Code (Copilot Chat) | प्रति चैट रिक्वेस्ट 128 टूल | एरर: "Cannot have more than 128 tools per request" |
| Windsurf (Cascade) | सभी सर्वरों में मिलाकर 100 टूल | कुछ टूल बंद करने तक अतिरिक्त टूल उपलब्ध नहीं होते |
| Claude Code | कोई तय संख्या नहीं | टूल सर्च डिफ़ॉल्ट रूप से डेफ़िनिशन टालता है; उसे बंद करने पर सब कुछ पहले से लोड हो जाता है |
| Claude Desktop | कोई प्रकाशित हार्ड कैप नहीं | हर सक्षम टूल डेफ़िनिशन कन्वर्सेशन कॉन्टेक्स्ट में जाती है |
दो बातें ध्यान खींचती हैं। पहली, VS Code इस तालिका का अकेला क्लाइंट है जिसकी संख्या आधिकारिक डॉक्यूमेंटेशन में दर्ज है। Cursor की 40 और Windsurf की 100 संख्या फ़ोरम थ्रेड और थर्ड-पार्टी लेखों से आती है, इसलिए इन पर "अपना वर्ज़न जाँचें" वाली टिप्पणी ज़रूरी है। दूसरी, हार्ड कैप शायद ही आपकी पहली समस्या होती है। धीमे जवाब, ग़लत टूल चुनाव और कॉन्टेक्स्ट विंडो का इतना भर जाना कि आप प्रॉम्प्ट लिखें उससे पहले ही वह भर जाए, ये सब कैप से बहुत पहले दिखने लगते हैं।
एक MCP सर्वर हर टूल का वर्णन करता है: नाम, सादी भाषा में विवरण और उसके आर्गुमेंट्स के लिए एक JSON स्कीमा। क्लाइंट हर रिक्वेस्ट में यह पूरा बंडल मॉडल को भेजता है, आपके प्रॉम्प्ट से पहले और किसी फ़ाइल की सामग्री से भी पहले। दस छोटे टूल लगभग असर नहीं डालते। अस्सी लंबे-चौड़े टूल उस विंडो का बड़ा हिस्सा खा सकते हैं जो आप कोड के लिए चाहते थे।
असल वजह यही है कि क्लाइंट सीमाएँ तय करते हैं। कैप कॉन्टेक्स्ट बजट बचाने, लेटेंसी घटाने और मॉडल को विकल्पों में डूबने से रोकने का सीधा तरीका है। Cursor के फ़ोरम थ्रेड 40 टूल की कैप को इन्हीं शब्दों में समझाते हैं: दर्जनों कच्चे टूल आगे भेजने से मॉडल उन्हें परखने में कॉन्टेक्स्ट जलाता है, इसलिए लेटेंसी बढ़ती है और सटीकता घटती है।
कॉन्टेक्स्ट कहानी का केवल आधा हिस्सा है। दूसरा आधा चुनाव है। जब मॉडल के सामने ओवरलैपिंग नामों वाले दर्जनों टूल होते हैं, जैसे search_issues, search_repos और search_code, तो उसे अंदाज़ा लगाना पड़ता है कि कौन सा सही है, और सूची बढ़ने के साथ अंदाज़े ज़्यादा गलत होते हैं।
OpenAI के फ़ंक्शन कॉलिंग डॉक्यूमेंटेशन में सुझाव है कि किसी टर्न की शुरुआत में 20 से कम फ़ंक्शन रखने का लक्ष्य रखें, और वह इसे एक सॉफ़्ट सुझाव कहता है। GitHub ने Copilot में इसी से मिलता नतीजा पाया: उसने डिफ़ॉल्ट बिल्ट-इन टूल सेट को 40 से घटाकर 13 मुख्य टूल किया और बाकी को माँग पर खोला। GitHub के अपने बेंचमार्क में इस तरीके से सफलता दर 2 से 5 प्रतिशत अंक बढ़ी और औसत लेटेंसी 400 मिलीसेकंड घटी।
तो असली व्यावहारिक सीमा प्रिंट की गई कैप से नीचे होती है। 12 साफ़ और अलग नामों वाले टूल वाला सर्वर अक्सर 90 ऐसे टूल वाले सर्वर से बेहतर होता है जिनके नाम एक जैसे लगते हैं।
अपने एडिटर कॉन्फ़िग को छुए बिना आप टूल की उलझन लगभग दस मिनट में खुद माप सकते हैं।
यही प्रयोग कुछ मॉडलों पर साथ-साथ दोहराएँ। Claude Sonnet 5, GPT 5.4 और Gemini 3.1 Pro PicassoIA पर चैट मॉडल के रूप में उपलब्ध हैं, इसलिए आप देख सकते हैं कि भरी सूची में हर एक कैसे व्यवहार करता है। अगर सूची छोटी होने पर ग़लत चुनाव तेज़ी से घटते हैं, तो आपको पता चल जाएगा कि आपका वर्कफ़्लो वास्तव में कितने टूल उठा सकता है।
💡 सावधानी: यह परीक्षण सादे टेक्स्ट से मॉडल के चुनाव को जाँचता है। असली क्लाइंट अपना खुद का रूटिंग जोड़ते हैं, इसलिए नतीजे को संकेत मानें, गारंटी नहीं।
जब आपके सक्षम सर्वरों के टूल 40 से आगे जाते हैं, तो Cursor चेतावनी दिखाता है। Cursor फ़ोरम पर रिपोर्ट किया गया शब्दांकन कुछ ऐसा है: सक्षम सर्वरों से आपके 50 टूल हैं, लिमिट 40 है, और कुछ टूल एजेंट को उपलब्ध नहीं हो सकते। पुराने रिलीज़ में अतिरिक्त टूल बस नज़रअंदाज़ कर दिए जाते थे। ऐसे सर्वर जोड़े गए जिनमें कुल 45 टूल थे, और एजेंट ने 40 इस्तेमाल किए, यह बताए बिना कि कौन से पाँच गायब हो गए, इसका कोई विस्तृत डायग्नोस्टिक नहीं था।
कुछ हाल के लेख कहते हैं कि नए Cursor बिल्ड टूल ज़्यादा लचीले ढंग से रजिस्टर करते हैं और कुछ टूल माँग पर लोड करते हैं। हमने जो MCP डॉक्यूमेंटेशन पेज देखा, उसमें टूल की गिनती प्रकाशित नहीं है, इसलिए योजना के लिए 40 अब भी सुरक्षित संख्या है।
💡 गणित पर ध्यान दें: कैप कुल पर लागू होती है, प्रति सर्वर पर नहीं। तीन सर्वर, हर एक में 15 टूल, यानी कुल 45, जो लिमिट से पाँच ज़्यादा है, भले ही कोई एक सर्वर बड़ा न लगे।
चार कदम, सबसे कम मेहनत से सबसे ज़्यादा मेहनत तक क्रम में:
.cursor/mcp.json में रखें और सिर्फ़ रोज़ के सर्वर ग्लोबल ~/.cursor/mcp.json में छोड़ें।Cursor के फ़ोरम पर हर टूल को अलग से चालू-बंद करने की माँग बार-बार उठती है, इसलिए अगर आपको आज यही बारीकी चाहिए, तो आपको सर्वर स्तर पर ही छाँटना होगा।
तीनों में VS Code सबसे साफ़ बताता है। उसका डॉक्यूमेंटेशन कहता है कि एक चैट रिक्वेस्ट में एक समय पर अधिकतम 128 टूल सक्षम हो सकते हैं। सीमा पार करते ही Copilot Chat यह एरर देता है: "Cannot have more than 128 tools per request."
यह गिनती टूल्स पिकर में सक्षम हर चीज़ पर लागू होती है, सिर्फ़ MCP टूल पर नहीं, इसलिए यह आपकी उम्मीद से जल्दी भर जाती है। दो-तीन बड़े सर्वर ही काफ़ी हो सकते हैं।
तुरंत हल Chat व्यू के टूल्स पिकर में है। गिनती 128 से नीचे आने तक अलग-अलग टूल या पूरे MCP सर्वर अनचेक करें, फिर रिक्वेस्ट दोबारा भेजें।
अगर आप 128 से आगे जाना चाहते हैं, तो VS Code वर्चुअल टूल देता है। github.copilot.chat.virtualTools.threshold सेट करें और VS Code मिलते-जुलते टूल को एक ही वर्चुअल टूल के तहत समूहित कर देता है। मॉडल पहले समूह देखता है और किसी समूह को तभी खोलता है जब प्रॉम्प्ट को उसकी ज़रूरत हो। इससे एक चैट रिक्वेस्ट 128 की सीमा से आगे जा सकती है।
इसे एक विषय-सूची की तरह समझें: मॉडल अध्यायों के शीर्षक पढ़ता है, फिर एक अध्याय खोलता है। इसकी कीमत यह है कि पहली बार किसी समूह की ज़रूरत पर एक अतिरिक्त विस्तार चरण लगता है, और बदले में शुरुआती सूची कहीं छोटी रहती है।
GitHub के एम्बेडिंग-आधारित रूटिंग के परीक्षण दिखाते हैं कि समूहीकरण क्यों फ़ायदेमंद है। ज़रूरी टूल 94.5 प्रतिशत मामलों में तैयार मिला, जबकि LLM-आधारित चयन में 87.5 प्रतिशत और स्थिर टूल सूची में 69.0 प्रतिशत।
Claude Code अलग रास्ता अपनाता है। गिनती पर कैप लगाने के बजाय वह हर डेफ़िनिशन का पहले से भुगतान नहीं करता। टूल सर्च के साथ MCP टूल डेफ़िनिशन रिक्वेस्ट से रोक ली जाती हैं और मॉडल को उन्हें लोड करने के लिए सिर्फ़ एक सर्च टूल मिलता है। Anthropic के MCP डॉक्यूमेंटेशन में अपवाद दर्ज हैं: कस्टम ANTHROPIC_BASE_URL के साथ, ENABLE_TOOL_SEARCH=false के साथ, और Claude 4.5 पीढ़ी से पुराने मॉडलों के साथ टूल सर्च बंद रहता है।
कम्युनिटी लेखों में इसी वेरिएबल के और मान बताए गए हैं, जैसे auto, जो तभी टालता है जब डेफ़िनिशन कॉन्टेक्स्ट विंडो के 10 प्रतिशत से ऊपर जाएँ, और 5 प्रतिशत की सीमा के लिए auto:5। उन पर भरोसा करने से पहले अपने इंस्टॉल किए गए वर्ज़न के डॉक्स देख लें। एक लेख ने 147 टूल डेफ़िनिशन को पहले से लोड करने पर लगभग 90,000 टोकन मापे, जबकि टूल सर्च चालू होने पर लगभग 15,000।
आउटपुट का आकार भी मायने रखता है। Claude Code चेतावनी देता है जब एक MCP टूल का परिणाम 10,000 टोकन से ऊपर जाए, और डिफ़ॉल्ट रूप से आउटपुट को 25,000 पर सीमित रखता है। इसे MAX_MCP_OUTPUT_TOKENS से तभी बढ़ाएँ जब काम सचमुच इसकी माँग करे।
Anthropic के डॉक्यूमेंटेशन में हमें Claude Desktop के लिए कोई तय टूल गिनती नहीं मिली। थर्ड-पार्टी लेख एक सरल तंत्र बताते हैं: जुड़े हर सर्वर का हर टूल हर मैसेज के लिए कन्वर्सेशन कॉन्टेक्स्ट में डाला जाता है, बिना किसी डायनामिक रिट्रीवल के। उनकी व्यावहारिक सलाह है कि संतृप्ति और उलझन शुरू होने से पहले 30 से 50 सक्रिय टूल के बीच रहें। इस दायरे को आधिकारिक लिमिट नहीं, कम्युनिटी अनुभव मानें।
Claude उपयोगकर्ताओं के लिए सबक यह है कि लिमिट एक संख्या नहीं, एक बजट है। वर्तमान बातचीत को जितने कनेक्टर चाहिए बस उतने ही चालू रखें, बाकी बंद कर दें।
प्रकाशित संख्याएँ काफ़ी अलग-अलग होती हैं, क्योंकि स्कीमा का विवरण अलग-अलग होता है। ये आँकड़े सार्वजनिक टोकन लागत सूचियों और ऊपर बताए गए लेख से लिए गए हैं:
| सर्वर या सेटअप | टूल डेफ़िनिशन | पहले से लगे टोकन | प्रति टूल (लगभग) |
|---|---|---|---|
| GitHub MCP सर्वर | 86 | 14,406 | लगभग 170 |
| छोटा GitHub सर्वर वेरिएंट | 36 | 11,430 | लगभग 320 |
| GitHub Projects सर्वर | 19 | 2,316 | लगभग 120 |
| एक लेख का मिला-जुला सेटअप | 147 | लगभग 90,000 | लगभग 610 |
फैलाव ही सबक है। विवरण और स्कीमा कितना है, उसके हिसाब से एक टूल लगभग 120 से 610 टोकन तक लेता है। टूल गिनें, पर उनका वज़न भी तौलें।
किसी भी सेटअप को जाँचने के लिए यह इस्तेमाल करें:
टूल × प्रति टूल टोकन ÷ कॉन्टेक्स्ट विंडो = आपके टाइप करने से पहले खर्च हुआ हिस्सा
| टूल | हर एक के टोकन | कुल | 200,000 की विंडो में हिस्सा |
|---|---|---|---|
| 10 | 300 | 3,000 | 1.5% |
| 40 | 300 | 12,000 | 6% |
| 86 | 170 | 14,620 | 7.3% |
| 128 | 600 | 76,800 | 38.4% |
200,000 की विंडो सिर्फ़ एक उदाहरण है, और आपका मॉडल इससे ज़्यादा या कम दे सकता है। पैटर्न फिर भी वही रहता है: 40 हल्के टूल लगभग 6 प्रतिशत खाते हैं, जबकि 128 भारी टूल एक-तिहाई से ज़्यादा निगल सकते हैं। स्कीमा का वज़न कैप पर छपी संख्या से ज़्यादा मायने रखता है।
हर टूल को तीन-चार कामों में बाँटें, जैसे कोड, डेटा, डॉक्स और मीडिया। फिर एक समय पर एक काम को सक्षम करें। Cursor में इसका मतलब प्रोजेक्ट-वार कॉन्फ़िग है, VS Code में टूल्स पिकर, और Claude में कनेक्टर टॉगल।
समूहीकरण नाम टकराव को भी सुलझाता है। जब डॉक्स वाले टूल और कोड वाले टूल कभी एक बातचीत में नहीं होते, तो search का केवल एक ही अर्थ हो सकता है।
ज़्यादातर सेटअप में बेकार बोझ होता है। इस सूची को एक बार ज़रूर जाँचें:
💡 मोटा नियम: अगर कोई टूल एक महीने से कॉल नहीं हुआ, तो वह टोकन खा रहा है और बदले में कुछ नहीं दे रहा।
अगर आप अपना MCP सर्वर बनाते हैं, तो बजट को ध्यान में रखकर डिज़ाइन करें: एक काम, छोटे विवरण, ऐसे नाम जो कभी न टकराएँ, और कसे हुए आर्गुमेंट स्कीमा। Claude के लिए PicassoIA कनेक्टर हल्के तरीके का अच्छा उदाहरण है। इसमें नौ टूल हैं: generate_image, edit_image, दो वीडियो जनरेटर, get_generation, list_generations, list_models, get_account और cancel_generation। ये सभी एक ही काम करते हैं, इमेज और वीडियो बनाना।
इतने आकार का सर्वर Cursor की 40 और Windsurf की 100 सीमा के आराम से भीतर रहता है, और आपको दबाव महसूस होने से पहले वह आधा दर्जन और सर्वरों के लिए जगह छोड़ देता है।
व्यवस्थित टूल बजट से क्या मिलता है, यह महसूस करने का सबसे आसान तरीका है कि उसके ज़रिए एक असली वर्कफ़्लो चलाकर देखें। सादी भाषा में इमेज माँगें, नतीजा जाँचें, एक विवरण बदलें, फिर दोबारा माँगें। केंद्रित सेटअप इस लूप को तेज़ रखता है, क्योंकि मॉडल ज़रूरी टूल खोजने के लिए साठ असंबंधित टूल में नहीं भटकता।
इस लेख की तस्वीरें P-Image और छोटे, साफ़ प्रॉम्प्ट से बनी हैं। आप अभी Picasso IA पर इसी तरह के प्रॉम्प्ट चला सकते हैं:
Picasso IA एक स्थिर इमेज को छोटे वीडियो में भी बदल सकता है, यानी एक कदम और जोड़कर वही फ़ोटो क्लिप बन सकती है। सभी मॉडल picassoia.com/en/all-models पर देखें, कोई एक चुनें, अपने प्रोजेक्ट के बारे में प्रॉम्प्ट लिखें और नतीजा देखें। एक शब्द बदलें, फिर चलाएँ और तुलना करें। एक-एक चीज़ बदलकर परखने की यही छोटी आदत वही आदत है जो MCP सेटअप को स्वस्थ रखती है।
अपनी भाषा चुनें
