अपनी संदर्भ विंडो को जलाना बंद करें - हम क्लाउड कोड में एमसीपी आउटपुट में 98% की कटौती कैसे करते हैं

प्रत्येक एआई-संचालित वर्कफ़्लो पर छिपा हुआ कर

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

यह समस्या सैद्धांतिक नहीं है. क्लाउड कोड, कर्सर और इसी तरह के एआई-संचालित विकास परिवेशों के अंदर एमसीपी (मॉडल कॉन्टेक्स्ट प्रोटोकॉल) एकीकरण पर निर्माण करने वाली टीमें यह खोज रही हैं कि उनके टूल प्रतिक्रियाएं नियमित रूप से मॉडल की वास्तव में जरूरत से 50x से 100x अधिक डेटा लौटाती हैं। एक साधारण डेटाबेस क्वेरी पूर्ण स्कीमा डंप लौटाती है। एक फ़ाइल खोज संपूर्ण निर्देशिका ट्री लौटाती है। एक एपीआई स्थिति जांच पिछले हफ्तों में पृष्ठांकित लॉग लौटाती है। प्रत्येक अतिरिक्त टोकन सीमित संदर्भ विंडो को नष्ट कर देता है, जिससे उन कार्यों का प्रदर्शन ख़राब हो जाता है जो वास्तव में मायने रखते हैं। समाधान जटिल नहीं है, लेकिन एआई टूल डिज़ाइन के बारे में आपके सोचने के तरीके में मूलभूत बदलाव की आवश्यकता है।

मॉडलों के टूटने से पहले कॉन्टेक्स्ट विंडोज़ क्यों टूट जाती है?

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

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

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

98% कटौती ढाँचा: चार सिद्धांत जिन्होंने सब कुछ बदल दिया

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

यहां चार सिद्धांत हैं जिन्होंने हमारे अनुकूलन को संचालित किया:

सारांश लौटाएँ, डेटासेट नहीं। किसी क्वेरी से 200 पंक्तियाँ लौटाने के बजाय, एक गिनती और 3-5 सर्वाधिक प्रासंगिक पंक्तियाँ लौटाएँ। यदि मॉडल को और अधिक की आवश्यकता है, तो वह एक विशिष्ट स्लाइस की मांग कर सकता है। यह एकल परिवर्तन आमतौर पर डेटा-हेवी टूल पर आउटपुट को 80-90% तक कम कर देता है।

संरचित, न्यूनतम स्कीमा का उपयोग करें. हर उस फ़ील्ड को हटा दें जो उपकरण के घोषित उद्देश्य से सीधे तौर पर प्रासंगिक नहीं है। एक "परिनियोजन स्थिति जांचें" उपकरण को स्थिति, टाइमस्टैम्प और त्रुटि (यदि कोई हो) लौटानी चाहिए - पूर्ण परिनियोजन प्रकटन, पर्यावरण चर और बिल्ड लॉग नहीं।

छोटा सा भूत

Frequently Asked Questions

What is context window exhaustion and why does it matter?

Context window exhaustion occurs when an AI coding assistant runs out of usable memory mid-conversation due to bloated tool outputs. This causes the model to forget earlier context, re-read files unnecessarily, and contradict its own suggestions. For teams relying on AI-powered development workflows, this silently degrades productivity and output quality, turning a capable assistant into an unreliable one without any obvious error message.

How did you reduce MCP output by 98%?

We restructured our MCP tool responses to return only essential data instead of verbose, unfiltered outputs. By implementing smart summarization, selective field returns, and context-aware truncation, we eliminated the noise that was consuming precious context tokens. The result is that Claude Code maintains coherent, productive conversations for significantly longer sessions — enabling complex, multi-step engineering tasks without losing the thread.

Does this optimization work with platforms like Mewayz?

Absolutely. Mewayz is a 207-module business OS starting at $19/mo that relies on efficient AI automation across its entire platform. Optimized MCP outputs mean AI-assisted workflows within tools like Mewayz at app.mewayz.com run faster and more reliably, since every saved token translates directly into longer productive sessions and more accurate responses when managing complex business operations.

Can I apply these MCP optimization techniques to my own projects?

Yes. The core principles — minimizing response payloads, returning only requested fields, and summarizing large datasets before passing them to the model — are universally applicable. Whether you're building custom MCP servers or integrating third-party tools with Claude Code, auditing your tool outputs for unnecessary verbosity is the single highest-impact optimization you can make to extend productive conversation length.

Related Posts

• कैसलवानिया और ब्लडस्टेन्ड डेवलपर शुटारो इडा का 52 वर्ष की आयु में निधन हो गया
• macOS का अल्प-ज्ञात कमांड-लाइन सैंडबॉक्सिंग टूल (2025)
• कैलिफोर्निया का नया विधेयक DOJ-अनुमोदित 3D प्रिंटर की मांग करता है जो स्वयं रिपोर्ट करें
• GPU पर Async/प्रतीक्षा करें