# MCP के साथ कोड एक्सीक्यूशन: अपना एजेंट दोबारा लिखने से पहले टूल टोकन्स मापें

> MCP के साथ कोड एक्सीक्यूशन टूल संदर्भ को सिकोड़ सकता है, लेकिन पहले मापें कि कौन-से टोकन्स डेफिनिशन्स से आते हैं और कौन-से परिणामों से। यहाँ Claude Code और Codex की एक प्रक्रिया दी है, साथ में सीधे कॉल, टूल सर्च और कोड एक्सीक्यूशन के लिए एक निर्णय तालिका।

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

**संक्षिप्त उत्तर:** MCP के साथ कोड एक्सीक्यूशन एजेंट को जनरेट किए गए कोड से टूल कॉल करने देता है, ताकि वह कॉल जोड़ सके और मॉडल को परिणाम दिखाने से पहले मध्यवर्ती डेटा फ़िल्टर कर सके। यह दो अलग-अलग टोकन लागतों को निशाना बनाता है: संदर्भ में लोड होने वाली टूल डेफिनिशन्स और संदर्भ से होकर वापस भेजे जाने वाले टूल परिणाम। सेटअप बदलने से पहले हर एक को मापें: टूल सर्च डेफिनिशन्स को टालता है, जबकि कोड एक्सीक्यूशन तब सबसे उपयोगी है जब कई कॉल जोड़े जा सकें या बड़े परिणामों को मॉडल के देखने से पहले घटाया जा सके। [Anthropic का मूल डिज़ाइन](https://www.anthropic.com/engineering/code-execution-with-mcp) यह पैटर्न समझाता है; यह गाइड इसे कोडिंग एजेंट के पक्ष से मापती है।

## MCP के साथ कोड एक्सीक्यूशन क्या बदलता है?

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

एक MCP सर्वर बिल्कुल वैसा ही रह सकता है जबकि एजेंट यह बदल देता है कि वह सर्वर के टूल कैसे खोजता और कॉल करता है। एजेंट को सर्वर तक पहुँचने की अनुमति अभी भी चाहिए, और कोड रनटाइम को चलने के लिए सुरक्षित जगह चाहिए। [Anthropic का स्पष्टीकरण](https://www.anthropic.com/engineering/code-execution-with-mcp) TypeScript रैपर की एक फाइल सिस्टम इस्तेमाल करता है; टूल सर्च और प्रोग्रामैटिक टूल कॉलिंग जैसी नई API फ़ीचर्स टूल को टालने या कोड से टूल कॉल चलाने के अन्य तरीके देती हैं।

काम करने वाली सीमा यह है: **एजेंट कोड लिखता है → कोड MCP टूल कॉल करता है → सैंडबॉक्स मध्यवर्ती डेटा रखता है → मॉडल को सिर्फ़ लौटाया गया मान मिलता है।** अगर सैंडबॉक्स नहीं है, तो एक्सीक्यूशन चरण एक अनट्रस्टेड-कोड सीमा है, न कि टोकन अनुकूलन जिसे आप हल्के में ऑन कर दें।

## कोडिंग-एजेंट सत्र में MCP टोकन्स कहाँ जाते हैं?

वे दो बकेट में जाते हैं: उपलब्ध टूल डेफिनिशन्स और मॉडल को लौटाए गए परिणाम। एक तीसरा मुद्दा, स्थिर डेफिनिशन उपसर्ग पर बार-बार बिलिंग, प्रॉम्प्ट कैशिंग से प्रभावित होता है लेकिन उस उपसर्ग को संदर्भ विंडो से गायब नहीं करता। [Anthropic की संदर्भ गाइड](https://platform.claude.com/docs/en/agents-and-tools/tool-use/manage-tool-context) इन्हीं कारणों से इन कंट्रोल को अलग करती है।

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

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

## मैं Claude Code और Codex में MCP टोकन लागत कैसे माप सकता हूँ?

सत्र-स्तर की रीडिंग के लिए क्लाइंट के संदर्भ व्यू का उपयोग करें, फिर नए-सत्र तुलना से एक सर्वर को अलग करें। सटीक API प्रीफ़्लाइट के लिए, उसी अनुरोध को एक बार बिना टूल और एक बार सर्वर की `tools` सरणी के साथ गिनें।

**Claude Code:** एक साफ़ सत्र शुरू करें, `/context` चलाएँ, और टास्क करने से पहले MCP/टूल-डेफिनिशन हिस्सा दर्ज करें। संबंधित MCP सर्वर कनेक्ट करके वही टास्क चलाएँ, फिर `/context` दोबारा जाँचें। मौजूदा Claude Code टूल सर्च के साथ, सपोर्टेड फर्स्ट-पार्टी सेटअप पर MCP टूल डिफ़ॉल्ट रूप से deferred होते हैं और माँग पर खोजे जाते हैं, इसलिए कोई डेफिनिशन एजेंट के उसे सर्च करने के बाद दिख सकती है; टास्क से पहले और बाद दोनों की रीडिंग लें। [कमांड रेफरेंस](https://code.claude.com/docs/en/commands) `/context` को डॉक्यूमेंट करता है, और [MCP रेफरेंस](https://code.claude.com/docs/en/mcp) डिफ़ॉल्ट टूल-सर्च व्यवहार और उसके अपवादों को डॉक्यूमेंट करता है।

पहली रीडिंग ऐसी दिखती है। October 4, 2026 को एक साफ़ टेस्ट में (Claude Code 2.1.289, एक खाली प्रोजेक्ट, पाँच सर्वर कनेक्टेड), `claude -p "/context"` ने कोई भी टास्क चलने से पहले हर MCP टूल को उसके अनुमानित डेफिनिशन आकार के साथ सूचीबद्ध किया:

| सर्वर                                   | टूल | डेफिनिशन टोकन्स | सबसे बड़ा टूल                  |
| --------------------------------------- | --: | --------------: | ------------------------------ |
| Playwright MCP 0.0.83                   |  25 |           ~6.8k | `browser_take_screenshot`, 578 |
| Octobrain 0.14.4                        |   4 |           ~4.2k | `memorize`, 1.7k               |
| Octocode 0.26.4                         |   4 |           ~3.5k | `structural_search`, 1.8k      |
| Octofs 0.16.0                           |   6 |           ~3.3k | `view`, 1.0k                   |
| MCP रेफरेंस फाइल सिस्टम सर्वर 2026.8.31 |  14 |           ~3.1k | `read_text_file`, 321          |

उन डेफिनिशन्स के सभी 20.8k टोकन्स deferred पंक्ति में बैठे थे, सत्र के 12.5k शुरुआती कुल योग से बाहर। दो रन प्रति सर्वर 1–3% भिन्न रहे। यहाँ टूल संख्या लागत का कमज़ोर संकेतक है: रेफरेंस फाइल सिस्टम सर्वर के 14 छोटे टूल, Octofs के 6 टूल से कम खर्च कराते हैं, और एक लंबा विवरण दर्जन भर छोटे विवरणों पर भारी पड़ सकता है।

खुद क्लाइंट सेटअप के लिए, हमारा [Claude Code और Codex MCP वॉकथ्रू](/blog/octofs-0-16-faster-filesystem-for-claude-code-and-codex) इस्तेमाल करें; यह माप प्रक्रिया मानती है कि सर्वर पहले से कनेक्टेड है।

**Codex:** एक नए थ्रेड में, `/status` और `/mcp` दर्ज करें, एक प्रतिनिधि टास्क चलाएँ, फिर उसी सर्वर को अक्षम करके या उसकी टूल सूची सिकोड़कर नया थ्रेड शुरू करने के बाद `/status` की तुलना करें। एक बार में एक ही सर्वर बदलें।

Codex सत्र संदर्भ उपयोग को `/status` में और कनेक्टेड सर्वर को `/mcp` में डॉक्यूमेंट करता है; डॉक्यूमेंटेड स्थिति पूरे-सत्र का आँकड़ा है और स्कीमा टोकन्स को हर सर्वर से नहीं जोड़ता। नियंत्रित रन के बीच के अंतर को अनुमान मानें क्योंकि प्रोजेक्ट इंस्ट्रक्शन्स, प्रॉम्प्ट हिस्ट्री और अन्य टूल भी संदर्भ घेरते हैं। [Codex का मौजूदा रेफरेंस](https://developers.openai.com/codex/cli/slash-commands) उन कमांड को सूचीबद्ध करता है।

Messages API अनुरोध के लिए, Anthropic का `POST /v1/messages/count_tokens` एंडपॉइंट अपनी असल `tools` सरणी और सिस्टम प्रॉम्प्ट के साथ इस्तेमाल करें। एक गिनती टूल के साथ करें और दूसरी उन्हीं टूल को हटाकर उसी अनुरोध के साथ करें; डेफिनिशन ओवरहेड का अनुमान लगाने के लिए कुल योगों को घटाएँ।

एंडपॉइंट मैसेज, सिस्टम प्रॉम्प्ट और टूल के लिए एक साथ टोकन संख्या लौटाता है, और मॉडल प्रतिक्रिया नहीं बनाता। परिणाम लागत भी मापने के लिए, प्रतिनिधि `tool_result` सामग्री शामिल करके गिनती दोहराएँ। यह एक प्रीफ़्लाइट गिनती है; असली वर्कफ़्लो ट्यून करते समय इसकी तुलना प्रतिक्रिया के वास्तविक उपयोग से करें। [Anthropic का टोकन-गणना रेफरेंस](https://platform.claude.com/docs/en/api/messages/count_tokens) अनुरोध और लौटाए गए `input_tokens` फ़ील्ड को परिभाषित करता है।

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

## क्या Anthropic ने 2025 के MCP लेख के बाद से टूल सर्च जारी किया है?

हाँ। October 4, 2026 तक, Anthropic Messages API में deferred टूल लोडिंग को डॉक्यूमेंट करता है और कहता है कि Claude Code सपोर्टेड फर्स्ट-पार्टी सेटअप पर डिफ़ॉल्ट रूप से MCP टूल सर्च सक्षम करता है। API संस्करण को टूल सर्च टूल चाहिए और वह पात्र डेफिनिशन्स को `defer_loading` से चिह्नित करता है; Claude Code कनेक्टेड MCP सर्वर के लिए वह पथ संभालता है। [API गाइड](https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool) अनुरोध का आकार बताती है, जबकि [मौजूदा Claude Code MCP डॉक्स](https://code.claude.com/docs/en/mcp) बताते हैं कि वह कब टूल को पहले से लोड करने पर वापस जाता है।

यह पुरानी पोस्ट के लिए एक सार्थक अपडेट है, लेकिन टूल सर्च हर टूल डेफिनिशन को अनुरोध से नहीं हटाता: API को deferred डेफिनिशन्स अभी भी मिलती हैं ताकि वह ज़रूरत पड़ने पर उन्हें सर्च और विस्तारित कर सके। यह ज़्यादातर डेफिनिशन्स को मॉडल के शुरुआती संदर्भ से बाहर रखता है और उस जगह के बदले एक अतिरिक्त खोज चरण लेता है। Anthropic की [टूल सर्च गाइड](https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool) कहती है कि सादा टूल कॉलिंग 10 से कम टूल के साथ, जब आप हर अनुरोध पर हर टूल इस्तेमाल करते हों, या जब सभी डेफिनिशन्स मिलकर 100 टोकन्स से नीचे रहती हों, तब बेहतर फ़िट बैठती है; उसका [टूल-संदर्भ अवलोकन](https://platform.claude.com/docs/en/agents-and-tools/tool-use/manage-tool-context) टूल सर्च को 20 या अधिक के सेट पर रखता है। इन दोनों सीमाओं के बीच, स्विच करने से पहले मापें।

OpenAI Responses API में एक समान `tool_search` पथ उजागर करता है; मौजूदा गाइड कहती है कि यह gpt-5.4 और उसके बाद सपोर्टेड है और MCP टूल डेफिनिशन पर `defer_loading: true` इस्तेमाल करता है। यह एक API फ़ीचर है। Codex CLI में, `/status` से समग्र सत्र संदर्भ देखें और अपने MCP कॉन्फ़िगरेशन से उजागर सर्वर टूल सिकोड़ें। [OpenAI की टूल-सर्च गाइड](https://developers.openai.com/api/docs/guides/tools-tool-search) API फ़ीचर बताती है; [Codex कॉन्फ़िग रेफरेंस](https://developers.openai.com/codex/config-reference) `enabled_tools` सूचीबद्ध करता है।

## मुझे क्या चुनना चाहिए: सीधे MCP कॉल, टूल सर्च, या कोड एक्सीक्यूशन?

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

| चुनें                      | कब फ़िट बैठता है                                                                                                     | किस ट्रेडऑफ़ की योजना रखें                                                                                |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| सीधे कॉल                   | एक छोटा, स्थिर टूल सेट लगभग हर टास्क पर इस्तेमाल होता है, या किसी इंसान को हर व्यक्तिगत क्रिया की समीक्षा करनी चाहिए | डेफिनिशन्स उपलब्ध रहती हैं; बड़े आउटपुट और कॉल-दर-कॉल राउंडट्रिप अब भी संदर्भ घेरते हैं                   |
| टूल सर्च / deferred लोडिंग | कैटलॉग बड़ा है लेकिन हर टास्क सिर्फ़ कुछ टूल इस्तेमाल करता है                                                        | एक खोज चरण; API को सर्च के लिए डेफिनिशन्स अभी भी मिलती हैं                                                |
| कोड एक्सीक्यूशन            | कोई टास्क कई टूल जोड़ता है, रिकॉर्ड पर लूप चलाता है, या कच्चे मध्यवर्ती डेटा की जगह सघन सारांश लौटा सकता है          | सैंडबॉक्सिंग, सीमाओं और मॉनिटरिंग वाला एक्सीक्यूशन एनवायरनमेंट चाहिए; कोड एक रन में कई टूल कॉल कर सकता है |

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

स्रोत आँकड़े उदाहरण के तौर पर उपयोगी हैं, पूर्वानुमान के तौर पर नहीं। Anthropic की 2025 इंजीनियरिंग पोस्ट अपने डिज़ाइन उदाहरण में 150,000 से 2,000 टोकन्स (98.7%) की गिरावट रिपोर्ट करती है। Cloudflare की February 2026 पोस्ट अपने दो-टूल वाले Cloudflare API Code Mode के लिए लगभग 1,000 टोकन्स रिपोर्ट करती है, तुलना में इसके समतुल्य नेटिव टूल सेट के लिए 1.17 मिलियन; Cloudflare कहता है कि उस तुलना ने tiktoken इस्तेमाल किया। ये हर वेंडर के स्वयं रिपोर्ट किए गए परिणाम हैं, और सर्वर, स्कीमा, रनटाइम और टास्क का आकार भिन्न हैं। [Anthropic की पोस्ट](https://www.anthropic.com/engineering/code-execution-with-mcp) और [Cloudflare की पोस्ट](https://blog.cloudflare.com/code-mode-mcp/) आपकी सेटअप के लिए अपेक्षित बचत स्थापित नहीं करतीं।

एक अलग [AIMultiple बेंचमार्क](https://aimultiple.com/code-execution-with-mcp), जिसे August 2026 में अपडेट किया गया, अपने Bright Data MCP / GPT-4.1 टेस्ट में 78.5% कम इनपुट टोकन्स और 7% अधिक औसत लेटेंसी रिपोर्ट करता है। उस बेंचमार्क में आउटपुट टोकन्स बढ़े। यह याद दिलाता है कि इनपुट, आउटपुट, लेटेंसी और टास्क सफलता को अलग-अलग ट्रैक करें; अकेले "कम टोकन्स" पूरा परिणाम नहीं है।

## उपयोगी डेटा छिपाए बिना मैं टूल आउटपुट की सीमा कैसे तय करूँ?

आउटपुट की सीमा उस परत पर तय करें जो जानती है कि टास्क को क्या चाहिए। सर्वर पेजिनेट कर सकता है या अंश लौटा सकता है; MCP क्लाइंट व्यक्तिगत टूल परिणाम सीमित कर सकता है; मॉडल कोड से कह सकता है कि परिणाम प्रिंट करने से पहले फ़ील्ड चुने और पंक्तियाँ एग्रीगेट करे।

Claude Code चेतावनी देता है जब कोई MCP टूल 10,000 टोकन्स से अधिक लौटाता है, और उसकी 25,000-टोकन डिफ़ॉल्ट अधिकतम सीमा है जहाँ टूल अपनी परिणाम-आकार सीमा घोषित नहीं करता। Codex प्रति-टूल `output_token_limit` और हिस्ट्री में संग्रहीत आउटपुट के लिए एक सामान्य `tool_output_token_limit` उजागर करता है। ये सीमाएँ बाँधती हैं कि बातचीत संदर्भ तक क्या पहुँचता है; वे चौड़े टूल स्कीमा को छोटा नहीं करतीं। [Claude Code के MCP आउटपुट कंट्रोल](https://code.claude.com/docs/en/mcp) और [Codex का कॉन्फ़िगरेशन रेफरेंस](https://developers.openai.com/codex/config-reference) देखें।

एक Codex TOML उदाहरण जिसमें छोटा उजागर टूल सेट और प्रति-टूल आउटपुट बजट है। यह पुष्टि करने के लिए कि एलाउ-लिस्ट लागू हुई, `codex mcp get <server> --json` रिज़ॉल्व किए गए `enabled_tools` प्रिंट करता है (Codex CLI 0.160.0 पर जाँचा गया); यह सर्वर के एनवायरनमेंट वेरिएबल्स भी बिना मास्क प्रिंट करता है, इसलिए वह आउटपुट टिकट और चैट लॉग से दूर रखें:

```toml
[mcp_servers.example]
enabled_tools = ["search", "read"]

[mcp_servers.example.tools.read]
output_token_limit = 2000
```

कॉन्फ़िगर की गई सीमा एक बजट है, न सख़्त छत और न लक्ष्य: Codex `output_token_limit` को मानक 20% सीरियलाइज़ेशन अलाउंस से पहले लागू करता है, इसलिए संग्रहीत परिणाम उससे कुछ आगे निकल सकता है। परिणाम का आकार उपयोगी रखें: सिर्फ़ ज़रूरी फ़ील्ड माँगें, रिकॉर्ड पेजिनेट करें, और जब पूरा डेटा न चाहिए हो तो गिनती या कुछ प्रतिनिधि पंक्तियाँ लौटाएँ। OpenAI की [MCP गाइड](https://developers.openai.com/api/docs/guides/tools-connectors-mcp) Responses API के `allowed_tools` फ़िल्टर को भी सपोर्ट करती है।

## कोड एक्सीक्यूशन सुरक्षा और अनुमोदन के बारे में क्या बदलता है?

यह कुछ काम को दिखने वाले, एक-बार-में-एक टूल कॉल से हटाकर एक ऐसे प्रोग्राम में ले जाता है जिसे मॉडल लिखता है और रनटाइम चलाता है। यह निजी मध्यवर्ती डेटा को मॉडल के संदर्भ से बाहर रख सकता है, लेकिन इसका मतलब यह भी है कि कोड एनवायरनमेंट आपकी सुरक्षा सीमा का हिस्सा है।

Anthropic का API अब मैनेज्ड सैंडबॉक्स में प्रोग्रामैटिक टूल कॉलिंग प्रदान करता है। स्व-निर्मित इम्प्लीमेंटेशन के लिए, Anthropic चेतावनी देता है कि क्लाइंट-साइड एक्सीक्यूशन सैंडबॉक्स के बाहर अनट्रस्टेड कोड चलाता है और कोड-इंजेक्शन वेक्टर बन सकता है; स्व-प्रबंधित सैंडबॉक्सिंग आइसोलेशन जोड़ती है लेकिन इंफ्रास्ट्रक्चर काम माँगती है। MCP के लिए Cloudflare का Worker-आधारित Code Mode डिफ़ॉल्ट रूप से सामान्य नेटवर्क एक्सेस अस्वीकार करता है और विशिष्ट सेवाओं को बाइंडिंग्स के रूप में उजागर करता है। ये उदाहरण दो पैटर्न दिखाते हैं: एक्सीक्यूशन को अलग करें, और उसे सीमित दायरे वाली क्षमताएँ दें। [Anthropic की प्रोग्रामैटिक टूल-कॉलिंग गाइड](https://platform.claude.com/docs/en/agents-and-tools/tool-use/programmatic-tool-calling) और [Cloudflare का मूल Code Mode डिज़ाइन](https://blog.cloudflare.com/code-mode/) देखें।

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

## छोटी MCP टूल सतह के लिए यह कैसा दिखता है?

छोटी सतह को भी आउटपुट शेपिंग से फ़ायदा हो सकता है, लेकिन उसे कोड एक्सीक्यूशन की ज़रूरत न हो। हम [octofs](/blog/introducing-octofs) बनाते हैं, छह टूल वाला एक फाइल सिस्टम MCP सर्वर, जिनमें `view` और `batch_edit` शामिल हैं; `batch_edit` एक कॉल में एक फाइल पर 50 तक गैर-अतिव्यापी एडिट लागू करता है और नई लाइन id लौटाता है, ताकि एजेंट को फाइल दोबारा न पढ़नी पड़े। Octocode, हमारा कोड-सर्च सर्वर, डिफ़ॉल्ट रूप से चार टूल उजागर करता है (सिमेंटिक सर्च, स्ट्रक्चरल सर्च, सिग्नेचर व्यू और एक कोड ग्राफ) और छह LSP टूल सिर्फ़ तब जोड़ता है जब आप लैंग्वेज सर्वर कॉन्फ़िगर करें। Octobrain, हमारे मेमोरी सर्वर, में चार हैं। ऊपर की माप में वे लगभग 3.3k, 3.5k और 4.2k डेफिनिशन टोकन्स तक आए: प्रति टूल रेफरेंस फाइल सिस्टम सर्वर से ज़्यादा, और सभी तब तक deferred जब तक किसी टास्क को वे न चाहिएँ। एजेंट को फाइल सिस्टम एक्सेस देते समय व्यापक सुरक्षा सीमा के लिए, हमारी [फाइल सिस्टम सुरक्षा गाइड](/blog/give-an-ai-agent-a-filesystem-safely) देखें।

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

— Don

---

_एक नियमित टास्क पर माप आज़माएँ और पहले-बाद के आँकड़े अपनी सर्वर कॉन्फ़िगरेशन के पास रखें। [Octofs](https://github.com/Muvon/octofs) और [Octocode](https://github.com/Muvon/octocode) ओपन सोर्स हैं; अगर आपकी सेटअप में उनकी टूल सतहें ज़रूरत से ज़्यादा संदर्भ खर्च करती हों, तो अपने आँकड़ों के साथ एक इशू खोलें।_