AI एजेंट में MCP बनाम CLI के असली बेंचमार्क नतीजे: एक ही GitHub टास्क के लिए 1,365 टोकन बनाम 44,026, और एक Playwright टेस्ट जहाँ फ़र्क लगभग ख़त्म हो गया। देखें टोकन कहाँ जाते हैं, MCP कब अपना ओवरहेड सही ठहराता है, और ज़रूरी टूल्स छोड़े बिना बिल कैसे घटाएँ।
आपके एजेंट ने अपना जवाब अभी एक भी शब्द में नहीं लिखा है, और वह पहले ही हज़ारों टोकन खर्च कर चुका है। AI एजेंट के लिए MCP बनाम CLI की असली बहस यही है: सवाल यह नहीं कि कौन सा प्रोटोकॉल ज़्यादा सुव्यवस्थित है, बल्कि यह कि कौन सा कॉन्टेक्स्ट विंडो में असली काम के लिए ज़्यादा जगह छोड़ता है। एक बेंचमार्क में GitHub लुकअप के लिए कमांड लाइन से 1,365 टोकन और MCP से वही लुकअप 44,026 टोकन में मापा गया। दूसरे बेंचमार्क में, जो Playwright पर बना था, लगभग कोई फ़र्क नहीं मिला। दोनों नतीजे असली हैं, और उनका फ़र्क अकेले किसी एक आँकड़े से ज़्यादा बताता है। नीचे देखें कि टोकन कहाँ जाते हैं, मापन क्या दिखाते हैं, MCP कब अब भी अपना वज़न सही ठहराता है, और बिना अंदाज़े के चुनाव कैसे करें।
दोनों तरीके मॉडल को हाथ देते हैं। फ़र्क इसमें है कि मॉडल को पता कैसे चलता है कि वे हाथ क्या कर सकते हैं, और वह इस जानकारी की कीमत कब चुकाता है।
Model Context Protocol एक JSON-RPC मानक है। सेशन शुरू होते ही क्लाइंट जुड़े हर सर्वर से पूछता है कि वह कौन से टूल्स देता है। हर टूल नाम, विवरण और इनपुट स्कीमा के रूप में आता है, और यह सब मॉडल के कॉन्टेक्स्ट में रहता है ताकि वह तय कर सके कि क्या कॉल करना है। फिर हर कॉल और हर नतीजा स्ट्रक्चर्ड JSON के रूप में आता-जाता है।
फ़ायदे असली हैं: टाइप्ड इनपुट, सर्वर की तरफ़ से होने वाली ऑथेंटिकेशन, और ऐसे टूल्स जिन्हें कोई भी कम्पैटिबल क्लाइंट अपने आप खोज सकता है। नुक़सान यह है कि पूरी कैटलॉग का खर्च पहले ही उठाना पड़ता है, चाहे टास्क को एक टूल चाहिए या एक भी नहीं।
CLI तरीके में एजेंट एक शेल कमांड लिखता है, रनटाइम उसे चलाता है, और स्टैंडर्ड आउटपुट सादे टेक्स्ट में वापस आता है। कोई कैटलॉग नहीं और कोई हैंडशेक नहीं। मॉडल अपनी ट्रेनिंग डेटा से पहले ही git, grep, curl और jq जानता है, और अगर कोई फ़्लैग भूल जाए तो वह --help चलाकर एक छोटा पेज पढ़ लेता है।
खर्च सिर्फ़ उन्हीं कमांड्स का दिखता है जो असल में इस्तेमाल होती हैं। डिज़ाइन का यही एक फ़र्क आगे की ज़्यादातर बातें समझा देता है।
💡 त्वरित परिभाषा: टोकन टेक्स्ट का वह हिस्सा है जिसे मॉडल पढ़ता या लिखता है। टूल परिभाषाएँ, कमांड और नतीजे, सब कॉन्टेक्स्ट विंडो में जगह लेते हैं, और अगले टर्न पर इन सबकी गिनती इनपुट में होती है।
एजेंट लूप में टोकन खर्च तीन जगह से आता है: मॉडल को उसके टूल्स के बारे में क्या बताया गया है, वह क्या भेजता है, और वापस क्या आता है। MCP और CLI में मुख्य फ़र्क पहले और तीसरे हिस्से में है।
एक सामान्य MCP सर्वर पहले सवाल से पहले ही हर टूल की परिभाषा बातचीत में डाल देता है। Scalekit के बेंचमार्क के अनुसार GitHub का आधिकारिक सर्वर 43 टूल्स देता है, यानी एक मामूली क्वेरी भी 43 स्कीमा साथ लेकर चलती है। Checkly ने अकेले Playwright सर्वर की परिभाषाएँ 5.9k टोकन में मापीं। Anthropic अपने इंजीनियरिंग लेख में, जो code execution with MCP पर है, इस समस्या को सीधे शब्दों में कहता है: टूल परिभाषाएँ कॉन्टेक्स्ट विंडो को ओवरलोड कर देती हैं।
दूसरा खर्च पकड़ में आना ज़्यादा मुश्किल है। डिफ़ॉल्ट MCP कॉल्स में हर बीच का नतीजा मॉडल से होकर गुज़रता है। Anthropic का उदाहरण एक मीटिंग ट्रांसक्रिप्ट का है, जो एक सेवा से लाकर दूसरी सेवा में लिखा जाता है: टेक्स्ट कॉन्टेक्स्ट से दो बार गुज़रता है, और लंबी रिकॉर्डिंग के लिए यह 50,000 से ज़्यादा टोकन जोड़ सकता है। शेल पाइपलाइन मॉडल तक पहुँचने से पहले उस डेटा को फ़िल्टर, गिन या छोटा कर सकती है।
| खर्च का स्रोत | MCP, डिफ़ॉल्ट सेटअप | CLI |
|---|---|---|
| टूल कैटलॉग | सेशन की शुरुआत में सभी परिभाषाएँ लोड | कोई नहीं, --help मांग पर |
| कॉल का फ़ॉर्मेट | नाम और आर्गुमेंट्स वाला JSON एन्वेलप | एक शेल स्ट्रिंग |
| नतीजे | पूरा रिस्पॉन्स मॉडल को वापस | पाइप, फ़िल्टर या फ़ाइल में लिखा गया |
| टूल खोज | सर्वर अपने टूल्स घोषित करता है | मॉडल कमांड याद रखता है या हेल्प पढ़ता है |
दो सार्वजनिक टेस्ट सबसे साफ़ तस्वीर देते हैं, और वे अलग-अलग दिशाओं में इशारा करते हैं।
Scalekit ने Claude Sonnet 4 के साथ पाँच केवल-पढ़ने वाले GitHub टास्क चलाए, हर तरीके के लिए 25 रन, आधिकारिक GitHub MCP सर्वर के विरुद्ध। उन्होंने सादे CLI, skills नाम की छोटी निर्देश फ़ाइलों वाले CLI और MCP की तुलना की, यानी कुल 75 रन। हर टास्क के टोकन:
| टास्क | CLI | CLI + skills | MCP | MCP बनाम CLI |
|---|---|---|---|---|
| रेपो भाषा और लाइसेंस | 1,365 | 4,724 | 44,026 | 32x |
| PR विवरण और रिव्यू स्थिति | 1,648 | 2,816 | 32,279 | 20x |
| रेपो मेटाडेटा और इंस्टॉल | 9,386 | 12,210 | 82,835 | 9x |
| योगदानकर्ता के मर्ज किए गए PR | 5,010 | 6,107 | 33,712 | 7x |
| नवीनतम रिलीज़ और डिपेंडेंसी | 8,750 | 6,860 | 37,402 | 4x |
पाँचों टास्क का औसत देखें तो CLI के लिए लगभग 5,200 टोकन और MCP के लिए लगभग 46,000, यानी लगभग 9x। Scalekit का अनुमान है कि 10,000 ऑपरेशन प्रति माह पर CLI के लिए लगभग $3.20 और सीधे MCP के लिए $55.20 बैठता है, यानी 17x का फ़र्क। विश्वसनीयता भी उसी दिशा में गई: CLI ने 25 में से 25 रन पूरे किए, MCP ने 25 में से 18 (72%), और सातों विफलताएँ TCP-स्तर के टाइमआउट थीं।
skills वाले कॉलम को भी देखें। आख़िरी टास्क पर skills वाले संस्करण ने सादे CLI से कम टोकन खर्च किए (6,860 बनाम 8,750), शायद इसलिए कि छोटी निर्देश फ़ाइल ने एजेंट की कोशिश-और-गलती बचा दी। सरल लुकअप पर यह ज़्यादा महँगा पड़ा, क्योंकि निर्देश हर बार लोड होते हैं।
⚠️ सीमाएँ पढ़ें: एक मॉडल, एक सेवा, केवल-पढ़ने वाले टास्क। टाइमआउट कनेक्शन की समस्याएँ हैं, तर्क की गलतियाँ नहीं, इसलिए विश्वसनीयता का फ़र्क उस सर्वर सेटअप के बारे में ज़्यादा बताता है, प्रोटोकॉल के बारे में कम।
Checkly ने एक अलग टेस्ट चलाया: एक डेमो शॉप खोलना, एक प्रोडक्ट खोजना, उस पर क्लिक करना, कार्ट में आइटम डालना और सामग्री की जाँच करना। MCP सेशन ने कॉन्टेक्स्ट के 48k से 50k टोकन इस्तेमाल किए। CLI सेशन ने, जिसमें skills इंस्टॉल थे, 45k से 48k। तीन रन के बाद फ़र्क नगण्य था, और इसका सीधा कारण यह है कि Playwright CLI और MCP सर्वर एक ही बैकएंड साझा करते हैं और एक ही स्नैपशॉट फ़ाइलें डिस्क पर लिखते हैं।
Checkly यह भी मानता है कि 2025 में MCP की आलोचना जायज़ थी। इसके दो कारण थे: सर्वर हर परिभाषा पहले से लोड कर देते थे, और हर एक्शन पूरा पेज स्नैपशॉट इनलाइन लौटाता था। अब दोनों में नरमी आ चुकी है, क्योंकि आधुनिक एजेंट हार्नेस MCP टूल्स को तभी लोड करते हैं जब उनकी ज़रूरत हो, और सर्वर स्नैपशॉट डिस्क पर सेव कर सकते हैं। Checkly की चेतावनी दोहराने लायक है: AI की सलाह की एक्सपायरी डेट महीनों में मापी जाती है।
सबक यह नहीं कि किसी एक पक्ष ने गलती की। 32x का आँकड़ा एक ऐसे इम्प्लीमेंटेशन का है जिसमें हर स्कीमा लोड था। लगभग-बराबरी का नतीजा एक ऐसे दूसरे इम्प्लीमेंटेशन का है जो ओवरहेड से बचता है। टोकन खर्च सर्वर कैसे बना है उससे तय होता है, प्रोटोकॉल के लेबल से नहीं।
जब दोनों विकल्प बिना किसी अतिरिक्त सेटअप के चलते हैं, तो CLI अक्सर जीतता है। इसके पीछे दो मुख्य कारण हैं।
हर बड़े मॉडल के ट्रेनिंग डेटा में दशकों के शेल स्क्रिप्ट, README फ़ाइलें और फ़ोरम के जवाब पड़े हैं। एजेंट को git log या grep -r इस्तेमाल करने के लिए स्कीमा की ज़रूरत नहीं होती, और एक लाइन की कमांड नाम, आर्गुमेंट्स ऑब्जेक्ट और बाहरी एन्वेलप वाली JSON कॉल की जगह ले लेती है। जब उसे शक हो, तो --help एक छोटे पेज जितना खर्च होता है, हर सेशन की शुरुआत में पूरी कैटलॉग जितना नहीं।
CLI का सबसे कम आँका गया फ़ायदा कम्पोज़िशन है। हाल में मर्ज हुए pull requests के शीर्षक सूचीबद्ध करने का एक तरीका यह है:
gh pr list --state merged --limit 10 --json title --jq '.[].title'
मॉडल को दस लाइन के शीर्षक दिखते हैं। किसी pull request टूल की डिफ़ॉल्ट MCP कॉल अक्सर हर आइटम के लिए पूरा पेलोड लौटाती है: लेखक, लेबल, URL, टाइमस्टैम्प, रिव्यू स्थिति। इसका ज़्यादातर हिस्सा नज़रअंदाज़ होता है, पर सब कुछ पढ़ा जाता है, और सब कुछ का बिल बनता है।
CLI सेशन को डीबग करना भी आसान है। आप वही कमांड अपने टर्मिनल में चिपकाकर देख सकते हैं कि एजेंट ने असल में क्या देखा।
कच्ची टोकन गिनती एक आयाम है। कुछ काम ऐसी चीज़ें माँगते हैं जो केवल एक प्रोटोकॉल दे सकता है।
शेल कमांड उसी की अनुमतियों से चलती है जिसने उसे लॉन्च किया। अपने लैपटॉप पर यह ठीक है, पर ऐसे प्रोडक्ट में समस्या है जहाँ कई यूज़र अपने-अपने अकाउंट जोड़ते हैं। MCP सर्वर हर यूज़र के लिए सीमित क्रेडेंशियल रख सकता है और केवल वही एक्शन दिखा सकता है जो आप चाहते हैं, जैसे "issues पढ़ें" लेकिन "repository मिटाएँ" नहीं। यह टर्मिनल के बाहर के क्लाइंट्स को भी टूल्स खोजने देता है, डेस्कटॉप असिस्टेंट से लेकर IDE पैनल तक, बिना किसी को बाइनरी इंस्टॉल किए।
स्टेटफ़ुल टूल्स MCP के पक्ष में जाते हैं। एक ब्राउज़र सेशन जिसे दर्जनों टर्न तक बचे रहना है, या एक डेटाबेस कनेक्शन जिसमें ओपन ट्रांज़ेक्शन है, उसे एक-बार वाली शेल कमांड्स से दोबारा बनाना मुश्किल है।
मीडिया जनरेशन इसका अच्छा उदाहरण है। इमेज और वीडियो मॉडल एसिंक्रोनस जॉब्स की तरह चलते हैं: आप अनुरोध भेजते हैं, एक job ID पाते हैं, और नतीजा तैयार होने तक पोल करते हैं। लिखने के समय PicassoIA का कनेक्टर इस प्रवाह को नौ टूल्स में समेटता है: इमेज जनरेशन, इमेज एडिटिंग, दो वीडियो जनरेटर, स्टेटस लुकअप, कैंसल, पिछले जॉब्स की सूची, मॉडल सूची और अकाउंट जाँच। जनरेशन टूल्स job ID के साथ अगले पोल से पहले एक सुझाया गया इंतज़ार भी लौटाते हैं, ताकि एजेंट को पता रहे कब दोबारा देखना है, बिना अंधाधुंध लूप चलाए। इसके पीछे के मॉडल हैं PicassoIA Image, PicassoIA Image Editor Pro, PicassoIA Video और Seedance 2.5 Lite, और हर अकाउंट पर एक साथ पाँच प्रेडिक्शन तक चल सकते हैं।
आप वही मॉडल REST API पर https://api.picassoia.com/v1 के साथ सादे curl से भी इस्तेमाल कर सकते हैं। यह अच्छा काम करता है, पर एजेंट को एंडपॉइंट याद रखना होता है, क्रेडेंशियल जोड़ने होते हैं, और अपना पोलिंग लूप लिखना होता है। MCP टूल्स ये चरण पैक कर देते हैं। यह भी ध्यान दें कि कैटलॉग का आकार मायने रखता है: नौ छोटे टूल्स का वज़न GitHub के 43 से कहीं कम है, इसीलिए एक दुबला सर्वर एक फैले हुए सर्वर से कम चुभता है।
अगर MCP सही विकल्प है, तो आपको डिफ़ॉल्ट बिल स्वीकार करने की ज़रूरत नहीं है।
Anthropic इसे progressive disclosure कहता है: मॉडल को टूल परिभाषाएँ तभी पढ़ने दें जब उसकी ज़रूरत हो, एक साथ सब नहीं। दो तरीके काम करते हैं। एक है फ़ाइल-सिस्टम लेआउट, जिसमें हर टूल एक छोटी फ़ाइल होती है जिसे एजेंट मांग पर खोलता है। दूसरा है एक सर्च फ़ंक्शन, जो केवल प्रासंगिक परिभाषाएँ ढूँढकर लोड करता है। आपका हार्नेस इसे जो भी कहे, जाँचें कि डिफ़र्ड लोडिंग चालू है या नहीं, और केवल वही सर्वर जोड़ें जिनकी मौजूदा प्रोजेक्ट को ज़रूरत है।
Anthropic का बड़ा कदम यह है कि MCP टूल्स को ऐसे कोड के रूप में पेश किया जाए जिसे एजेंट सैंडबॉक्स से कॉल कर सके। एजेंट एक छोटी स्क्रिप्ट लिखता है, स्क्रिप्ट सर्वरों से बात करती है, और मॉडल तक केवल एक सारांश लौटता है। उनके Google Drive से Salesforce वाले उदाहरण में टोकन उपयोग 150,000 से घटकर 2,000 रह गया, यानी 98.7% की बचत।
देखें यह असल में क्या है: CLI जैसा व्यवहार, जहाँ मॉडल के देखने से पहले डेटा फ़िल्टर होता है, MCP की ऑथेंटिकेशन और टाइप्ड इंटरफ़ेस के ऊपर परत के रूप में। दोनों खेमे एक-दूसरे से सीखते हुए आगे बढ़ रहे हैं।
आज लागू करने लायक़ त्वरित उपाय:
डिफ़ॉल्ट सेटिंग्स पर कच्चे टोकन खर्च में CLI ज़्यादातर समय जीतता है, सबसे अच्छे दस्तावेज़ वाले बेंचमार्क में 4x से 32x तक। एक्सेस कंट्रोल, लंबे समय तक बने रहने वाले स्टेट और होस्टेड सेवाओं में MCP जीतता है। और जब MCP टूल्स मांग पर लोड हों और बड़े नतीजे कॉन्टेक्स्ट से बाहर रहें, तो फ़र्क लगभग शून्य तक सिकुड़ सकता है, जैसा Playwright टेस्ट ने दिखाया।
| स्थिति | बेहतर विकल्प | क्यों |
|---|---|---|
| git, फ़ाइलों और बिल्ड के साथ लोकल काम | CLI | परिचित कमांड, फ़िल्टर्ड आउटपुट |
| छोटे स्क्रिप्टेड या CI टास्क | CLI | कोई हैंडशेक नहीं, छोटा फ़ुटप्रिंट |
| डिफ़ॉल्ट सेटिंग्स पर 40+ टूल्स वाला सर्वर | CLI या कोड एक्ज़ीक्यूशन | स्कीमा ओवरहेड हावी रहता है |
| कई यूज़र, हर एक के अपने अकाउंट | MCP | हर यूज़र के लिए सीमित क्रेडेंशियल |
| लंबे ब्राउज़र सेशन | MCP | टर्न के बीच स्टेट बचा रहता है |
| एसिंक्रोनस मीडिया जनरेशन | MCP | Job IDs और पोलिंग संकेत |
CLI चुनें जब टूल पहले से एक कमांड के रूप में मौजूद हो, एजेंट आपकी नियंत्रित मशीन पर चले, और हर टोकन मायने रखता हो।
MCP चुनें जब आपको प्रति-यूज़र अनुमतियाँ, स्थायी स्टेट, या ऐसी होस्टेड सेवा चाहिए जिसका कोई अच्छा कमांड-लाइन टूल न हो।
शक हो तो दोनों मिलाएँ। ज़्यादातर असली सेटअप यही करते हैं: लोकल काम के लिए शेल, कुछ होस्टेड सेवाओं के लिए MCP, और हर एक को उतना ही छोटा रखें जितना टास्क को चाहिए।
आप इन ट्रेड-ऑफ़ को अपने सेटअप पर Claude Sonnet 5 के साथ परख सकते हैं, जो मल्टी-स्टेप कोडिंग और टूल उपयोग के लिए बना है। यह एक त्वरित ऑडिट वर्कफ़्लो है:
low थिंकिंग बंद रखता है और सबसे तेज़ जवाब देता है, जो ट्रायेज के लिए काफ़ी है। जब आप कई सर्वरों पर ट्रेड-ऑफ़ का तर्कपूर्ण हिसाब चाहें, तो high पर जाएँ।wc -c से करें, और सटीक टोकन गिनती के लिए अपने प्रोवाइडर के usage नंबर इस्तेमाल करें।💡 टिप: यही ऑडिट Kimi K2.6 या GPT 5.6 Sol के साथ चलाएँ और देखें कि हर मॉडल किन टूल्स को काटेगा।
इस लेख की हर फ़ोटो एक सरल पैटर्न पर चलती है: एक साफ़ सब्जेक्ट, एक रोशनी का स्रोत, एक कैमरा और लेंस का चुनाव। वही नुस्ख़ा ख़ुद आज़माएँ। सुबह नौ बजे की एक वर्कबेंच, ट्रेल के फ़ोर्क पर एक हाइकर, या टूल्स से भरी अपनी मेज़ का अपना संस्करण बताएँ, और उसे PicassoIA Image पर चलाएँ। नतीजे को PicassoIA Image Editor Pro से निखारें, और जब कोई स्टिल मोशन के लायक़ लगे, तो उसे PicassoIA Video पर भेजें। अपने अगले प्रोजेक्ट का एक प्रॉम्प्ट चुनें और देखें कि क्या सामने आता है।
अपनी भाषा चुनें
