Claude Code में MCP context: tool रखें या command चलाएं?
निश्चित token बचत माने बिना Claude Code के context पर MCP server के प्रभाव को जांचने की reversible विधि।
विषय-सूची
Claude Code में MCP context: tool रखें या command चलाएं?
जब Claude Code को working directory के बाहर के system—जैसे ticket, internal API, database या observability data—तक पहुंच चाहिए, MCP server उपयोगी होता है। लेकिन उसके साथ tool के नाम, description, input schema और संभावित action भी session में आते हैं। इसलिए सही सवाल यह है कि किसी खास task में बार-बार external access चाहिए या छोटा local action पर्याप्त है।
एक लंबा response देखकर सारे server बंद न करें। ऐसा छोटा, repeatable task चुनें जिसका external side effect न हो, मौजूदा स्थिति मापें और केवल एक server को सीमित या हटाएं। turns की संख्या, वास्तव में जरूरी calls और verify किया जा सकने वाला result, context बड़ा लगने की भावना से बेहतर evidence हैं।
अगर आप Claude Code का अलग API workflow जांच रहे हैं, तो BetterToken की मौजूदा guide खोलें, एक ही prompt और model से दो runs करें, फिर Dashboard में समय, model, status, input/output/cache Token और दिखाया गया usage तुरंत compare करें। इससे अतिरिक्त context की आशंका एक verify किए जा सकने वाले A/B test में बदल जाती है। एक read-only test से शुरू करें और API Key को repository में न रखें।
अतिरिक्त context कहां से आता है
Claude Code MCP documentation MCP को external tools और data से जोड़ने का तरीका बताती है। Model के लिए केवल बाद में आने वाला call result महत्वपूर्ण नहीं होता। पहले call से पहले भी उसे tool का काम, parameter और सीमा समझनी होती है। बहुत सारे बिना filter किए tools वाला broad server, विचार करने के लिए अधिक विकल्प देता है।
फिर भी MCP का कोई fixed “token cost” नहीं है। नतीजा server, enabled tools, prompt, model, session history और tool result पर निर्भर है। कम से कम इन स्थितियों को अलग रखें:
- task के लिए अनावश्यक कई tool schemas पहले ही उपलब्ध हैं;
- एक call इतना बड़ा result देता है कि अगले turns में उसे पढ़ना पड़ता है;
- बहुत broad result repeated search या file read कराता है;
- tool हटाने पर external validation खो जाती है और agent अनुमान लगाने लगता है।
इनमें से कोई भी observation अकेले हर token का कारण सिद्ध नहीं करता। repository का आकार और पहले की history भी तुलना बदलते हैं।
सबसे छोटा उपयोगी interface चुनें
| स्थिति | पहले चुनें | कारण |
|---|---|---|
| ticket बार-बार पढ़ना और update करना | narrow tracker MCP | external object model को लगातार उपयोग करना है। |
| local process status एक बार देखना | local command या status file | जरूरी fact workspace में ही है। |
| कई tasks में internal API पढ़ना | small scope वाला read-only MCP | access repeatable और reviewable रहता है। |
| repository का एक document खोलना | search और file read | external tool catalog की जरूरत नहीं। |
| external system बदलना | पहले manual या read-only check | authorization, idempotency और result check जरूरी हैं। |
Server की लोकप्रियता नहीं, काम की frequency और data boundary तय करती है। एक Git status के लिए command छोटा हो सकता है। लेकिन schema वाले external data पर कई जुड़े हुए काम करने हों तो command सुरक्षित interface की जगह नहीं लेता।
एक ही task पर छोटा comparison करें
बिना external side effect वाला task चुनें: बदली हुई file का owner ढूंढना, local status देखना या test project के खुले items पढ़ना। अलग-अलग tasks की तुलना न करें और असाधारण रूप से लंबे एक session से सामान्य निष्कर्ष न निकालें।
- छोटा prompt, working directory और expected result लिखें। उदाहरण: “बदली हुई files दिखाओ और repository बदले बिना एक अगला step बताओ।”
- मौजूदा MCP profile के साथ task चलाएं। केवल सुरक्षित observations लिखें: turns, इस्तेमाल हुए tools, result और time। API Key,
.envया पूरा sensitive output नोट में न रखें। /mcpमें ठीक एक server disable करें। उसका configuration सुरक्षित रहता है और वह disabled दिखाई देता है। session बंद कर fresh session खोलें,/mcpमें जांचें कि server सूची में है लेकिन connected नहीं है, और वही prompt दोहराएं।- पहले मिला हुआ fact compare करें। क्या agent ने वही जरूरी जानकारी पाई, या किसी उपयोगी tool call की जगह अनुमान लगाया?
/mcpसे server फिर enable करें, नया session खोलें और status जांचें। अगर उसके बिना manual copy करनी पड़ती है या महत्वपूर्ण validation गायब होती है, server वापस रखें। यदि result बचा रहता है और बेकार calls घटती हैं, छोटा configuration रखें।
fresh session जरूरी है क्योंकि पुराने history में tool results पहले से होते हैं। यह test Claude Code की universal performance नहीं मापता; यह आपके सामान्य workflow के लिए निर्णय में मदद करता है।
वास्तव में तुलनीय command
MCP को किसी भी command से replace न करें। उसी local fact के लिए यह read-only command तुलना योग्य हो सकती है:
git status --shortदोनों variants में केवल changed files की list और बिना write वाला अगला step मांगें। prompt और expected list एक ही रहने चाहिए। पहले list, फिर turns, calls और tokens compare करें। यदि MCP ऐसा external fact देता था जो git status में नहीं है, यह replacement equivalent नहीं है। narrow read-only MCP रखें या उसी system के लिए documented command इस्तेमाल करें।
हटाने से पहले tool surface कम करें
एक server कई commands दे सकता है, जबकि project नियमित रूप से केवल एक या दो का उपयोग करता हो। पहले surface सीमित करें:
- पहले comparison में केवल read-only tools enable करें;
- इस repository में न इस्तेमाल होने वाले integrations disable करें;
- development, support और administration के profiles अलग रखें;
- tool description में secrets, लंबे logs या conversation history न डालें;
- rare operation के लिए expected result वाला छोटा documented command रखें।
MCP external data पढ़ सकता है या action शुरू कर सकता है। उसका configuration scope check या call result की verification की जगह नहीं लेता। Model का text response यह प्रमाण नहीं है कि external operation सही तरह पूरी हुई।
usage और cost सही तरीके से compare करें
API test के लिए अपना BetterToken API Key लेकर Claude Code configure किया जा सकता है; वर्तमान मान Claude Code guide में देखें। BetterToken अलग API access है, Claude subscription नहीं। Key user के अपने account में बनती और manage होती है; उसे repository, handoff या experiment note में नहीं रखना चाहिए।
BetterToken Dashboard में समय, model, status, input, output और cache tokens तथा संबंधित usage दिखता है। हर run के लिए model, date और time, input, output, cache, दिखाया गया cost और turns एक पंक्ति में लिखें। दोनों runs में model और prompt एक ही रखें।
Dashboard cost दिखाए तो observed difference = MCP के साथ cost − MCP के बिना cost निकालें। केवल tokens दिखें तो पहले current pricing page खोलें, date, model और cache rules लिखें, और cost = input/1,000,000 × Pinput + output/1,000,000 × Poutput + cache/1,000,000 × Pcache केवल तब लगाएं जब cache का अलग price दिखाया गया हो। खाली या अस्पष्ट field zero नहीं है; पुराना rate फिर से न इस्तेमाल करें। यह दो runs का observation है, कोई fixed MCP price नहीं।
निर्णय सही क्रम में जांचें
- जरूरी external fact। replacement को ticket, status, API record या document वास्तव में लेना चाहिए, अनुमान नहीं लगाना चाहिए।
- Correctness और access boundary। expected result से मिलाएं और नए secret या व्यापक scope के बिना test को read-only रखें।
- बची हुई validation। जांचें कि replacement ने वह check तो नहीं हटाया जो tool पहले करता था; model response external proof नहीं है।
- फिर cost। उसी prompt की fresh session में turns, calls, input/output/cache tokens और Dashboard cost compare करें।
पहले तीन में से कोई point fail हो तो कम usage workflow को बेहतर नहीं बनाता: tasks अब एक जैसे नहीं हैं या खोई validation कोई व्यक्ति कर रहा है।
चुनाव कब फिर से देखें
अगर server हटाने से जरूरी external fact नहीं मिलता, unverified suggestions आते हैं या किसी को हर prompt में वही data manually copy करना पड़ता है, तो उसे वापस enable करें। अगर required result verify बना रहता है और unnecessary calls कम होती हैं तो छोटा profile रखें। अच्छा MCP profile अक्सर शांत दिखता है: हर enabled tool का एक repeatable काम होता है; बाकी के लिए छोटा command, document या manual check होता है।
