MCP सर्वर आपके एक भी प्रॉम्प्ट टाइप करने से पहले दसियों हज़ार टोकन खा सकते हैं। यह आर्टिकल बताता है कि /context से इस लागत को कैसे मापें, बेकार सर्वर कैसे हटाएँ, टूल सर्च कैसे चालू करें, टूल आउटपुट कैसे सीमित करें और सबएजेंट कैसे इस्तेमाल करें, ताकि Claude Code की कॉन्टेक्स्ट विंडो आपके असली काम के लिए बची रहे।
आप Claude Code खोलते हैं, एक छोटा-सा प्रॉम्प्ट टाइप करते हैं, और context मीटर पहले से आधा भरा दिखता है। आपके प्रॉम्प्ट में कोई गड़बड़ी नहीं है। असली वजह आमतौर पर वे MCP सर्वर होते हैं जिन्हें आपने पिछले महीने जोड़ा और फिर भूल गए। सेशन शुरू होते ही हर सर्वर Claude को टूल परिभाषाओं की एक सूची थमा देता है, और हर परिभाषा की कीमत असली काम शुरू होने से पहले टोकन में चुकानी पड़ती है। ऊपर से कुछ फूले हुए टूल रिस्पॉन्स जुड़ जाएँ, तो काम पूरा होने से बहुत पहले कॉन्टेक्स्ट विंडो खत्म हो जाती है। अच्छी बात यह है कि यह पूरी वर्कफ़्लो की सबसे आसानी से ठीक हो सकने वाली समस्याओं में से एक है। यह आर्टिकल वह क्रम बताता है जो काम करता है: पहले मापें, फिर सर्वर छाँटें, टूल सर्च चालू करें, आउटपुट सीमित करें, और सही समय पर सेशन रीसेट करें।
अगर ये लक्षण आपने पहचाने हैं, तो आप अकेले नहीं हैं। सुस्त लगने वाले सेशन, दस मिनट पहले दिए निर्देश भूल जाने वाले जवाब, और रीफ़ैक्टरिंग के बीच में चालू हो जाने वाला auto-compact, ये सब एक ही तरफ़ इशारा करते हैं: फिक्स्ड ओवरहेड बहुत ज़्यादा है और असली काम के लिए जगह बहुत कम।
Model Context Protocol (MCP) Claude Code को डेटाबेस, ब्राउज़र, इश्यू ट्रैकर, डिज़ाइन टूल और इमेज जनरेटर से बात करने देता है। हर कनेक्शन सचमुच उपयोगी है। लेकिन इसकी कीमत यह है कि Claude को पता होना चाहिए कि हर टूल क्या करता है, इसलिए हर टूल का नाम, उसका विवरण और पूरा JSON schema प्रॉम्प्ट में लोड होता है।
MCP का ओवरहेड चार जगहों से आता है, और इनमें से कुछ ही स्पष्ट दिखते हैं।
| स्रोत | कब लोड होता है | सामान्य प्रभाव | इसे कौन नियंत्रित करता है |
|---|---|---|---|
| टूल परिभाषाएँ | सेशन शुरू होने पर | प्रति टूल सैकड़ों टोकन, प्रति सर्वर हज़ारों | आप, सर्वर चुनकर |
| टूल रिस्पॉन्स | हर कॉल पर | कुछ सौ से दसियों हज़ार टोकन | सर्वर और आपकी आउटपुट सीमा |
| CLAUDE.md जैसी मेमोरी फ़ाइलें | सेशन शुरू होने पर | हर नया नियम जोड़ने पर बढ़ती हैं | आप |
| बातचीत का इतिहास | पूरे सेशन में जमा होता है | हर टर्न के साथ बढ़ता है | Compact और clear करना |
Anthropic का tool search पर इंजीनियरिंग लेख एक ऐसे सेटअप का वर्णन करता है जिसमें पाँच सर्वरों के 58 टूल थे और बातचीत शुरू होने से पहले ही लगभग 55K टोकन खा रहे थे। इसका मतलब है प्रति टूल लगभग 950 टोकन। 35 टूल वाला एक सर्वर, जैसे कोई पूरी सुविधाओं वाला code hosting इंटीग्रेशन, अकेले ही मानक window का दहाई प्रतिशत हिस्सा खा सकता है।
💡 त्वरित गणित: अगर आपके टूल औसतन 900 टोकन लेते हैं और आप 40 टूल जोड़ते हैं, तो आप लगभग 36,000 टोकन ऐसे मेन्यू पर खर्च कर चुके हैं जिसमें से Claude शायद कभी कुछ न मंगाए।
बेकार टूल दो तरीकों से नुकसान पहुँचाते हैं। पहला, सीधी जगह की कमी: जो window 30% भरी हुई शुरू होती है, उसमें कोड, लॉग और रीज़निंग के लिए 30% कम जगह होती है। Prompt caching बार-बार के टर्न पर इस फिक्स्ड ओवरहेड की कीमत कम कर देता है, लेकिन वह जो जगह घेरता है उसे कम नहीं करता।
दूसरा, फ़ैसले का शोर। जब पाँच सर्वर आपस में मिलते-जुलते search या fetch टूल दिखाते हैं, तो मॉडल के पास चुनने के लिए ज़्यादा लगभग-एक-जैसे विकल्प होते हैं। ऑन-डिमांड टूल लोडिंग पर Anthropic की अपनी जाँच में पाया गया कि शुरू में कम टूल दिखाने से सही टूल चुने जाने की विश्वसनीयता भी बेहतर हुई। कम टूल सिर्फ़ सस्ते नहीं होते, अक्सर ज़्यादा सटीक भी होते हैं।
अंदाज़े से सर्वर हटाना शुरू न करें। मापें, एक चीज़ बदलें, फिर दोबारा मापें।
अपने प्रोजेक्ट में एक नया सेशन खोलें और कोई भी प्रॉम्प्ट भेजने से पहले /context चलाएँ। Claude Code window का श्रेणी-वार ब्रेकडाउन दिखाता है: system prompt, system tools, MCP tools, memory files, messages और free space। चूँकि आपने अभी तक कुछ टाइप नहीं किया, messages वाली लाइन लगभग शून्य के आसपास होती है और बाकी सब शुद्ध ओवरहेड होता है।
फिर /mcp चलाएँ ताकि जुड़े हुए सर्वर और उनकी स्थिति की सूची मिले। सामान्य टर्मिनल से claude mcp list भी वही इन्वेंटरी देता है। /context से MCP tools वाली संख्या नोट कर लें। यही आपकी बेसलाइन है।
इसकी कोई आधिकारिक सीमा नहीं है, लेकिन व्यवहार में यह अनुमानित नियम अच्छा काम करता है:
| window में MCP tools का हिस्सा | फ़ैसला | क्या करें |
|---|---|---|
| 5% से कम | स्वस्थ | इसे छोड़ दें |
| 5% से 15% | देखने लायक | जिन सर्वरों को आप हफ़्ते में एक बार से कम छूते हैं, उन्हें हटाएँ |
| 15% से ज़्यादा | असली समस्या | सख़्ती से छाँटें और tool search चालू करें |
Memory files वाली लाइन भी जाँचें। जो CLAUDE.md नियमों की दीवार बन गया है, वह हर सेशन में टोकन खाता है, ठीक वैसे ही जैसे बातूनी MCP सर्वर खाता है।
सबसे सस्ता टोकन वह है जो कभी लोड ही नहीं होता। सर्वर की साफ़-सफ़ाई हर चतुर सेटिंग से बेहतर है।
/mcp मेन्यू खोलें और आज के काम के लिए ज़रूरत न हो ऐसी हर चीज़ बंद कर दें। अपने वर्ज़न के अनुसार, आप वहाँ से बिना कॉन्फ़िगरेशन खोए सर्वर टॉगल कर सकते हैं। जब पक्का हो जाए कि कोई सर्वर बेकार बोझ है, तो claude mcp remove <name> से उसे स्थायी रूप से हटा दें।
हर सर्वर के बारे में तीन सवाल पूछें:
एक ईमानदार "नहीं" भी उसे disable करने के लिए काफ़ी है।
MCP सर्वर तीन scopes में जोड़े जा सकते हैं: local, project और user। प्रोजेक्ट-स्कोप वाला सर्वर repo की root पर एक .mcp.json फ़ाइल में रहता है, इसलिए वह सिर्फ़ वहीं लोड होता है जहाँ उसकी ज़रूरत है:
claude mcp add --scope project my-db -- npx my-db-mcp-server
अपना user scope लगभग खाली रखें। डेटाबेस सर्वर उस repo में रखें जिसमें डेटाबेस है, और डिज़ाइन सर्वर उस repo में जिसमें डिज़ाइन हैं। एक बार के सेशन के लिए आप Claude Code को सिर्फ़ उन्हीं सर्वरों के साथ भी शुरू कर सकते हैं जिनके नाम एक config फ़ाइल में हैं:
claude --strict-mcp-config --mcp-config ./mcp/docs-only.json
वह सेशन बाकी सभी कॉन्फ़िगर किए गए सर्वरों को नज़रअंदाज़ कर देता है, जो किसी केंद्रित काम या साफ़ "पहले और बाद" की तुलना के लिए आदर्श है।
अगर कोई टूल पहले से command line program के रूप में मौजूद है, जैसे git, gh, docker, psql या aws, तो Claude उसे shell के ज़रिए चला सकता है। इसकी लागत शून्य टूल परिभाषा टोकन है, क्योंकि मॉडल को पहले से पता है कि ये कमांड कैसे काम करते हैं।
Anthropic ने code execution with MCP पर अपनी पोस्ट में इस विचार को और आगे बढ़ाया। सर्वरों को अलग-अलग टूल के बजाय code APIs के रूप में पेश करना, जिन्हें एजेंट किसी script से कॉल करता है, ने एक उदाहरण वर्कफ़्लो को लगभग 150,000 टोकन से घटाकर लगभग 2,000 कर दिया, यानी 98.7% की कमी। इस सबक का फ़ायदा उठाने के लिए आपको अपना टूल्स का सेट दोबारा बनाने की ज़रूरत नहीं है।
कुछ मामलों में MCP अब भी बेहतर है:
बाकी सब के लिए पहले CLI आज़माएँ।
कभी-कभी आपको सचमुच दर्जनों टूल उपलब्ध चाहिए होते हैं। यहीं deferred loading अपनी जगह बनाती है।
हर टूल परिभाषा प्रॉम्प्ट में चिपकाने के बजाय, क्लाइंट एक छोटा search टूल और टूल नामों की एक सूची लोड करता है। जब Claude को कुछ चाहिए होता है, तो वह खोजता है, और सिर्फ़ मिलती-जुलती परिभाषाएँ खींची जाती हैं। हाल के Claude Code रिलीज़ में यह अपने आप चालू हो जाता है, जब MCP टूल परिभाषाएँ window का बड़ा हिस्सा लेने लगती हैं, इस लेख के लिखे जाने के समय लगभग 10% पर।
Anthropic ने अपने एक उदाहरण में लगभग 85% की गिरावट टूल परिभाषा टोकन में बताई। विचार लाइब्रेरी की कार्ड कैटलॉग जैसा है: आप हर किताब अपनी मेज़ पर नहीं लाते, आप इंडेक्स रखते हैं और जो चाहिए उसे लाते हैं।
व्यवहार ENABLE_TOOL_SEARCH environment variable से नियंत्रित होता है:
# Default: only kicks in when MCP tools get large
export ENABLE_TOOL_SEARCH=auto
# Lower the trigger point (percent of the window)
export ENABLE_TOOL_SEARCH=auto:5
नाम और सीमाएँ रिलीज़ों के बीच बदलती रही हैं, इसलिए अपने इंस्टॉल किए गए वर्ज़न के documentation में जाँच लें।
💡 किसी बदलाव के बाद हमेशा
/contextदोबारा चलाएँ। अगर MCP tools वाली लाइन नहीं घटी, तो सेटिंग वह नहीं कर रही जो आप सोच रहे हैं।
इसमें एक समझौता है। deferred टूल का पहला उपयोग एक अतिरिक्त search चरण लेता है। अगर आप हर सेशन में वही तीन टूल कॉल करते हैं, तो उस छोटे सर्वर को सीधे लोड रखें और बाकी कम इस्तेमाल होने वाले टूल्स का काम tool search पर छोड़ें।
परिभाषाएँ एक निश्चित लागत हैं। रिस्पॉन्स वह परिवर्तनशील लागत हैं जो लोगों को चौंकाती है।
Claude Code तब चेतावनी देता है जब एक MCP टूल परिणाम लगभग 10,000 टोकन पार करता है, और डिफ़ॉल्ट रूप से 25,000 पर काट देता है। आप environment variable से यह सीमा घटा सकते हैं:
export MAX_MCP_OUTPUT_TOKENS=10000
सीमा एक सुरक्षा जाल है, डिज़ाइन नहीं। बेहतर इलाज वह सर्वर है जो शुरू से ही कम लौटाए। अगर आप सर्वर बनाते या कॉन्फ़िगर करते हैं, तो इन पैटर्न पर ज़ोर दें:
| पैटर्न | समस्या | बेहतर तरीका |
|---|---|---|
| पूरी टेबल लौटाना | संदर्भ में दसियों हज़ार पंक्तियाँ | सर्वर पर फ़िल्टर, सॉर्ट और सीमित करें |
| base64 इमेज एम्बेड करना | हर इमेज के लिए हज़ारों टोकन | होस्ट किया हुआ URL लौटाएँ |
| कच्चा पेज HTML लौटाना | मार्कअप का शोर हावी हो जाता है | एक सेलेक्टर से टेक्स्ट निकालें |
| पूरे payload के साथ status पोल करना | हर पोल पर बड़ा हिस्सा दोहराया जाता है | पूरा होने तक सिर्फ़ status फ़ील्ड लौटाएँ |
इमेज की कीमत उसके साइज़ के हिसाब से तय होती है, इनपुट टोकन में लगभग चौड़ाई गुणा ऊँचाई भागे 750 के बराबर। 1,000 गुणा 1,000 पिक्सल की इमेज लगभग 1,300 टोकन पर पड़ती है, और फ़ुल-रिज़ोल्यूशन स्क्रीनशॉट उसकी कई गुना लागत लेता है। जो सर्वर तस्वीरें या क्लिप जनरेट करते हैं, उन्हें छोटा URL और status लौटाना चाहिए, पिक्सल खुद कभी नहीं।
इमेज और वीडियो जनरेशन में यह सबसे पहले दिखता है। PicassoIA का MCP कनेक्टर सही तरीके से काम करता है: जनरेशन कॉल तुरंत एक प्रेडिक्शन ID लौटाती है, और होस्ट किया हुआ URL दिखने तक आप status पोल करते हैं। अगर आप एजेंट से कॉल करने के लिए जनरेटर चुन रहे हैं, तो P-Image और Flux 2 Pro जैसे टेक्स्ट-टू-इमेज मॉडल इस पैटर्न के साथ अच्छे बैठते हैं, और Seedance 2.5 Lite जैसा वीडियो मॉडल भी उसी बनाने, पोल करने और फ़ेच करने वाले लूप में फ़िट होता है।
एक दुबला सेटअप भी लंबे सेशन में भर जाता है। बचाव की आख़िरी परत संरचना है।
सबएजेंट अपनी अलग context window में चलता है और सिर्फ़ एक सारांश वापस भेजता है। इसलिए यह शोरगुल वाले कामों का आदर्श घर है: browser automation, बड़ी खोजें, इमेज जनरेशन लूप। .claude/agents/ में एक subagent फ़ाइल का नाम, विवरण, tools allowlist और model लेती है, ताकि आप उसे ठीक उन दो-तीन टूल्स तक सीमित कर सकें जिनकी उसे ज़रूरत है।
इसे mise en place समझें: हर कटोरे में एक सामग्री होती है, और काउंटर पर कुछ और नहीं छूता। यांत्रिक कामों के लिए Claude 4.5 Haiku जैसा छोटा मॉडल अक्सर काफ़ी होता है, और यह आपके मुख्य सेशन को उस सोच के लिए खाली रखता है जिसके लिए बड़ा मॉडल चाहिए। नए रिलीज़ सबएजेंट को अपने MCP सर्वर घोषित करने की सुविधा भी देते हैं, ताकि भारी सर्वर कभी मुख्य बातचीत को न छुएँ।
/compact अब तक की बातचीत को एक सारांश से बदल देता है, और आप उसे दिशा दे सकते हैं:
/compact keep the failing test names, file paths and the final design decision
इसे स्वाभाविक ब्रेकपॉइंट पर चलाएँ: कोई फ़ीचर अभी पूरा हुआ, टेस्ट अभी पास हुए, या आप नए चरण की शुरुआत करने वाले हैं। auto-compact का इंतज़ार न करें। वह तब चालू होता है जब window लगभग भर जाती है, और ऐसा नाज़ुक edit के बीच में भी हो सकता है।
अगर आप किसी असंबंधित काम पर जा रहे हैं, तो compact न करें। Clear करें। किसी दूसरे बग के बारे में पुराना context कोई संपत्ति नहीं है, वह शोर है जो जवाबों को भटकाता है। /clear के बाद केवल वही लोड करें जो नए काम को चाहिए।
💡 स्थायी तथ्य CLAUDE.md में रखें, लेकिन उसे छोटा रखें। वह हर सेशन में लोड होता है, इसलिए हर अतिरिक्त पैराग्राफ़ एक ऐसा कर है जो आप हमेशा चुकाते हैं। उसे हर महीने देखें और ऐसे नियम हटाएँ जिन्हें मॉडल बिना बताए पहले से मानता है।
Claude Code तक पहुँचने से पहले अपने सेशन के इनपुट हिस्से को सिकोड़ने का एक कम-जोखिम तरीका यह है। PicassoIA पर Claude Sonnet 5 कोडिंग और tool-use कामों के लिए बनाया गया है, इसलिए यह फूले हुए CLAUDE.md को संक्षिप्त करने, लंबे लॉग का सारांश बनाने या एक कसा हुआ प्रॉम्प्ट लिखने के लिए एक सुविधाजनक sandbox है। कच्चे गड़बड़ झाले के बजाय परिणाम को Claude Code में चिपकाएँ।
low है, जो सबसे तेज़ और सस्ते जवाबों के लिए thinking बंद रखता है। इसे केवल सचमुच जटिल रीज़निंग के लिए बढ़ाएँ।max_tokens का डिफ़ॉल्ट 8,192 है। सारांश के लिए बहुत कम संख्या जवाब को कसा हुआ रखती है।max_image_resolution विकल्प का डिफ़ॉल्ट 0.5 megapixels है, और यह मॉडल तक पहुँचने से पहले तस्वीरों को छोटा कर देता है, जिससे समय और पैसा दोनों बचते हैं।| सेटिंग | डिफ़ॉल्ट | टोकन बचाने वाली चाल |
|---|---|---|
effort | low | सारांश और दोबारा लिखने के लिए low ही रखें |
max_tokens | 8192 | उतना कम करें जितना आपको चाहिए उसके जवाब के आकार से मेल खाए |
max_image_resolution | 0.5 megapixels | जब तक बारीक विवरण ज़रूरी न हो, कम रखें |
system_prompt | खाली | एक छोटा फ़ॉर्मेट नियम एक बार सेट करें और दोबारा इस्तेमाल करें |
कठिन रीज़निंग वाले कामों के लिए, जैसे कई फ़ाइलों में फैले रीफ़ैक्टर की योजना बनाना, Claude Fable 5 और Claude Opus 4.7 इसी प्लेटफ़ॉर्म पर उपलब्ध हैं, ताकि आप देख सकें कि हर एक एक ही छोटे किए गए इनपुट को कैसे संभालता है।
यह पूरी योजना एक पेज पर, प्रयास बनाम फ़ायदे के क्रम में:
| उपाय | प्रयास | सामान्य लाभ |
|---|---|---|
/context चलाएँ और बेसलाइन दर्ज करें | 2 मिनट | दिखाता है कि टोकन कहाँ जाते हैं |
| बेकार सर्वर disable या remove करें | 5 मिनट | अक्सर सबसे बड़ा अकेला लाभ |
.mcp.json से सर्वर scope करें | 10 मिनट | Global सर्वरों को हर जगह लोड होने से रोकता है |
| पतले सर्वरों की जगह CLI लगाएँ | 15 मिनट | परिभाषाएँ पूरी तरह हटाता है |
| Tool search चालू करें | 2 मिनट | टूल्स के बड़े सेट के लिए बड़ी कटौती |
MAX_MCP_OUTPUT_TOKENS घटाएँ | 1 मिनट | बेकाबू रिस्पॉन्स से बचाता है |
| शोरगुल वाले कामों के लिए subagents | 20 मिनट | मुख्य window को साफ़ रखता है |
ब्रेकपॉइंट पर /compact, कामों के बीच /clear | लगातार | काम के बीच overflow रोकता है |
आज पहली दो पंक्तियों से शुरू करें। इनमें दस मिनट से कम लगते हैं और अक्सर चौंकाने वाली मात्रा में जगह लौट आती है।
जब आपकी window में फिर से जगह हो जाए, तो उसे किसी रचनात्मक काम में लगाएँ। PicassoIA खोलें, GPT Image 2 या P-Image जैसा कोई इमेज मॉडल चुनें, और एक सादे वाक्य से अपनी पहली तस्वीर बनाएँ। फिर उसे Seedance 2.5 Lite या PicassoIA Video से चलायमान करें। अपना कोई विचार आज़माएँ, प्रॉम्प्ट में एक विवरण बदलें, और देखें कि नतीजा कितना बदलता है। इन मॉडलों की क्षमता देखने का यह सबसे तेज़ तरीका है, और हर प्रयोग आपके context को हल्का रखने का एक अच्छा बहाना है।
अपनी भाषा चुनें
