MCP मर चुका है; MCP अमर रहे

 (chrlschn.dev)
19 पॉइंट द्वारा GN⁺ 2026-03-16 | 6 टिप्पणियां | WhatsApp पर शेयर करें
  • CLI एजेंट टूल इंटरफ़ेस के लिए एक नए ट्रेंड के रूप में उभरा है, लेकिन कस्टम CLI भी MCP जैसी ही context समस्या से जूझता है और इसके लिए structured design व कई फ़ायदों का त्याग करना पड़ता है
  • लोकल stdio मोड वाला MCP और Streamable HTTP आधारित remote MCP पूरी तरह अलग use case हैं, और मौजूदा बहस में इस फ़र्क़ को नज़रअंदाज़ किया जा रहा है
  • MCP की Prompts और Resources सुविधाएँ पूरे संगठन में standardized skills और documents को real time में वितरित करने का एक mechanism हैं, जो vibe coding से systematic agentic engineering की ओर बदलाव में अहम हैं
  • केंद्रीकृत MCP server OAuth authentication, telemetry, observability को standardized बनाता है, जिससे organization स्तर की security और tool effectiveness को मापना संभव होता है
  • व्यक्तिगत developers के लिए CLI सही हो सकता है, लेकिन organization और enterprise स्तर पर MCP वह टूल है जो consistency, security और quality को सुनिश्चित करता है — अभी भी और आगे भी

influencer-चालित hype cycle

  • सिर्फ़ 6 महीने पहले तक Model Context Protocol(MCP) इंडस्ट्री का सबसे बड़ा चर्चा-विषय था, और हर vendor MCP-संबंधित product लॉन्च करना चाहता था
  • उस समय भी यह संदेह मौजूद था कि “यह तो बस API है, फिर wrapper की क्या ज़रूरत है”, और वास्तव में कुछ टीमों ने MCP hype cycle को छोड़कर सीधे REST API endpoint के ऊपर साधारण tool wrapper लिखने का रास्ता चुना
  • ज़्यादातर use case में MCP को API को सीधे call करने की तुलना में अनावश्यक overhead माना जाने लगा
  • अब इंडस्ट्री की चर्चा MCP की आलोचना और CLI की प्रशंसा की ओर मुड़ गई है, और यह उस संरचना से जुड़ा है जिसमें AI influencers लगातार नए trend गढ़ते रहते हैं ताकि लोगों की दिलचस्पी बनी रहे
  • Garry Tan, Andrew Ng जैसे प्रसिद्ध लोग भी अक्सर अपने निजी अनुभव को सामान्यीकृत कर देते हैं, और FOMO व hype पैदा करने वाली influencer संस्कृति इस क्षेत्र की चर्चा को विकृत कर रही है
  • ऐसे कई वास्तविक मामले हैं जहाँ CLI एजेंट टूल इंटरफ़ेस के रूप में बेहतर है, लेकिन हर मामले में ऐसा नहीं है

CLI में token बचत: वास्तविकता और सीमाएँ

training data में शामिल CLI tools

  • jq, curl, git, grep, psql, aws जैसी CLI utilities जो LLM के training dataset में शामिल हैं, उन्हें एजेंट बिना अतिरिक्त निर्देश, schema या context के तुरंत इस्तेमाल कर सकता है
  • MCP में tools/list response के भीतर tools को पहले से घोषित करना पड़ता है, इसलिए पहले से ज्ञात CLI tools की तुलना में इसमें overhead होता है
  • जो CLI tools training data में पहले से मौजूद हैं, उन्हें हमेशा MCP पर प्राथमिकता देनी चाहिए

custom CLI की सीमाएँ

  • bespoke custom CLI tools का उपयोग LLM अपने-आप नहीं जानता, इसलिए AGENTS.md या README.md में उसका विवरण देना पड़ता है
  • आप /cli-tools directory तय कर सकते हैं और descriptive names पर निर्भर रह सकते हैं, लेकिन एजेंट इस तरीके में अक्सर गलती करता है और अंततः ज़्यादा documentation की ज़रूरत पड़ती है
  • curl जैसे tools भी जैसे ही custom OpenAPI schema को समझने लगते हैं, token बचत का फ़ायदा गायब हो जाता है

chained extraction और transformation

  • CLI chain के ज़रिए data को खोजकर फिर transform किया जा सकता है, जिससे context window में जाने वाले data की मात्रा कम होती है
  • लेकिन HTML, JSON, XML जैसे formatted content को DOM/CSS, JSONPath, XPath जैसे selector से भी निकाला जा सकता है, इसलिए यह केवल CLI का अनोखा फ़ायदा नहीं है

gradual context consumption

  • जहाँ MCP पूरे toolset और schema को पहले से load करता है, वहीं CLI --help के ज़रिए context को धीरे-धीरे load कर सकता है
  • लेकिन custom CLI tools के मामले में एजेंट को कई turn तक help content खंगालना पड़ता है, और परिणामस्वरूप वह MCP schema जैसी ही जानकारी बिना structure के load करता है
  • काफ़ी जटिल flow में एजेंट अंततः ज़्यादातर tree explore कर लेता है, इसलिए बचत का प्रभाव बहुत कम रह जाता है
  • Vercel के research result के अनुसार, जब पूरे documentation index को AGENTS.md में रखा गया, तो एजेंट की documentation उपयोग करने की क्षमता बेहतर हुई; यानी पूरा schema पहले से देना सही tool चुनने में मददगार है
  • जब Anthropic अभी 10 लाख token context window दे रहा है, तब यह सवाल उठता है कि क्या token बचत अब भी कोई निर्णायक तर्क है

MCP की दोहरी प्रकृति: stdio vs Streamable HTTP

stdio mode की सीमाएँ

  • stdio mode में MCP server एजेंट के साथ लोकल मशीन पर चलता है, और साधारण CLI लिखने की तुलना में अनावश्यक जटिलता जोड़ देता है
  • अधिकांश use case में stdio mode MCP की ज़रूरत नहीं होती

Streamable HTTP का क्रांतिकारी महत्व

  • Streamable HTTP transport वाला MCP उसी logic को केंद्रीकृत server पर चलाने की सुविधा देता है, और organization व enterprise adoption में vibe coding को agentic engineering में बदलने का यह एक केंद्रीय तत्व है
  • ज़्यादातर influencers इन दोनों modes के बीच का अंतर समझ ही नहीं रहे हैं

केंद्रीकृत MCP server के फ़ायदे

समृद्ध backend capabilities

  • केंद्रीकृत server में tools, Postgres instance या Apache AGE आधारित Cypher graph query जैसी समृद्ध platform capabilities का उपयोग कर सकते हैं
  • एजेंट की तरफ़ सिर्फ़ HTTP endpoint और authentication token सेट करना होता है, इसलिए deployment आसान हो जाता है
  • SQLite जैसी local DB भी संभव है, लेकिन पूरे organization की shared state के लिए उसकी सीमाएँ हैं

ephemeral agent runtime

  • GitHub Actions जैसे ephemeral runtime environment में remote MCP server के माध्यम से जटिल backend की ज़रूरत वाले tools को बिना installation के इस्तेमाल किया जा सकता है
  • stateless environment में stateful workloads का प्रबंधन केंद्रीकृत server को सौंपा जा सकता है

authentication और security

  • अगर CLI के ज़रिए secure API access करनी हो, तो हर developer को API key तक सीधे पहुँच चाहिए होती है, जो operations team पर बड़ा बोझ डालती है
  • MCP server के पीछे केंद्रीकरण करने पर developer OAuth के ज़रिए MCP server में authenticate करते हैं, और संवेदनशील API keys व secrets server के पीछे नियंत्रित रहते हैं
  • जब कोई team member संगठन छोड़ता है, तो सिर्फ़ OAuth token revoke करना काफ़ी है; उस व्यक्ति को शुरू से ही दूसरी keys और secrets तक पहुँच नहीं थी

telemetry और observability

  • केंद्रीकृत MCP server पर OpenTelemetry traces और metrics को standard tools से collect किया जा सकता है
  • इससे पता चल सकता है कि कौन-सा tool प्रभावी है, कौन-सा agent runtime इस्तेमाल हो रहा है, और tool failures कहाँ हो रहे हैं
  • CLI tools के साथ भी यह संभव है, लेकिन local deployment में consumers को update करना पड़ता है और हर CLI tool में telemetry scaffolding फिर से बनानी पड़ती है

standardized instant deployment और auto updates

  • distributed tools (packages) API version compatibility की समस्या पैदा करते हैं, लेकिन MCP में Subscriptions और Notifications के माध्यम से server clients को updates की सूचना दे सकता है
  • MCP Prompts server से दिए जाने वाले SKILL.md के बराबर हैं, और MCP Resources server से दिए जाने वाले /docs के बराबर हैं

MCP Prompts और Resources का संगठनात्मक महत्व

  • dynamic content: repository की *.md files static files होती हैं जिन्हें manually update करना पड़ता है, लेकिन server-based prompts और resources को real time में dynamically generate किया जा सकता है
    • ऐसे documents, pricing data, current system state आदि, जो केवल विशेष context में उपयोगी हों, उन्हें tool call के बिना dynamically inject किया जा सकता है
  • automatic consistency updates: repository या package से वितरित *.md files को sync करना पड़ता है, लेकिन MCP prompts के रूप में दिए जाने पर वे हमेशा up to date रहते हैं
    • third-party official docs को भी server के ज़रिए proxy किया जाए तो repository में manual copy/update की ज़रूरत नहीं रहती
  • organization-wide knowledge sharing: security, telemetry best practices, infrastructure deployment considerations जैसी organization-स्तर की सामग्री को हर repository, हर workflow, हर agent frontend (Claude Code, Codex, VS Code Copilot, GitHub Agents, OpenCode आदि) में एकसमान तरीके से वितरित किया जा सकता है
    • microservices environment में एक टीम दूसरी service के documents तक पहुँच सकती है, या service team deployment के समय dynamically skills उपलब्ध करा सकती है
  • OpenCode, Claude Code CLI आदि में MCP prompts और resources के वास्तविक काम करने के उदाहरण मिलते हैं, और सिर्फ़ MCP client configuration से deployment के बाद अलग maintenance की ज़रूरत नहीं पड़ती

निष्कर्ष: organization स्तर पर MCP वर्तमान भी है और भविष्य भी

  • 6 महीने पहले MCP सबसे बड़ा चर्चा-विषय था, और अब उसे context bloat का मुख्य दोषी कहा जा रहा है, लेकिन custom CLI के मिलते-जुलते trade-offs और pitfalls को नज़रअंदाज़ किया जा रहा है
  • जब टीमें vibe coding से agentic engineering की ओर जाने का रास्ता तलाशती हैं, तो वे स्वाभाविक रूप से MCP की design और mission तक पहुँचती हैं
  • Amazon AWS division के हालिया उदाहरण (AI-सहायित बदलावों पर senior engineer approval की ज़रूरत) से भी स्पष्ट है कि अंततः टीमों को AI agents द्वारा बनाए गए software systems को operate और maintain करना ही पड़ता है
  • Garry Tan और Andrew Ng की सलाह व्यक्तिगत, अपेक्षाकृत समान वातावरण में उपयोगी हो सकती है, लेकिन अलग-अलग skill level और अनुभव वाली टीमों को consistent quality पर converge करना हो, तो organization environment में उसे सीधे लागू करना कठिन है
  • भरोसेमंद और maintainable software जारी करने के लिए consistency, security, quality और correctness सुनिश्चित करने वाली engineering discipline चाहिए, और इसी वजह से MCP आज organization और enterprise के लिए उपयुक्त tool है

संबंधित पढ़ाई

6 टिप्पणियां

 
slowandsnow 2026-03-16

cli एक लोकल टूल है, और mcp एक सर्वर है, इसलिए इनका उपयोग बहुत अलग है।
 
cnaa97 2026-03-17

अगर CLI को सर्वर पर चलाएँ, तो क्या वह वही बात नहीं होगी?
 
ng0301 2026-03-16

एदो टेन्सेई MCP !
 
edunga1 2026-03-16

संबंधित दस्तावेज़: MCP मर चुका है. CLI अमर रहे
 
hmmhmmhm 2026-03-16

मुझे उम्मीद है कि mobile apps में भी CLI tools इस्तेमाल किए जा सकें, इसके लिए किसी तरह के CLI sandbox फीचर पर चर्चा और आगे बढ़े। वास्तव में mobile compatibility हासिल करने की कोशिश करते समय आखिरकार bottleneck sandboxing ही मुख्य मुद्दा बनता दिखता है।
 
GN⁺ 2026-03-16
Hacker News की राय

  • आजकल आने वाले ज़्यादातर AI integration features की डिज़ाइन काफ़ी कमजोर लगती है
    basic commands तक standardize नहीं हुए हैं, और documentation की जगह LLM द्वारा बनाया गया गलत help text ही भरा पड़ा है
    आख़िरकार, जिन्हें “AI standards” कहा जा रहा है, वे बार-बार बनेंगे और गायब हो जाएंगे, ऐसा लगता है। LLM मूल रूप से text-based हैं, इसलिए network protocol की तरह सटीक तरीके से काम करना इनके लिए मुश्किल है। इस तरह की text-centric engineering आख़िर में unstable abstraction pyramid बना देती है

  • AI tools में सबसे उपयोगी चीज़ मुझे probabilistic agents को deterministic gate के भीतर लपेटने वाली संरचना लगती है
    इसलिए मैं MCP को HTTP के ऊपर इस्तेमाल करता हूँ। उदाहरण के लिए, NanoClaw WhatsApp messages को deterministic तरीके से filter करता है और API keys को proxy करके security मज़बूत करता है। इस तरह की संरचना AI को ज़्यादा भरोसेमंद बनाती है

    • मैं भी इसी तरह का pattern follow करता हूँ। मेरा autonomous agent Smith, MCP को service mesh से जोड़ता है ताकि policy (OPA) और monitoring को centrally manage किया जा सके
      इस संरचना में security और manageability दोनों बेहतर हैं, और tool catalog से CLI को auto-generate भी किया जा सकता है
      implementation example smith-gateway में देखा जा सकता है
    • agent compromise हो जाए तब भी boundary बनी रहनी चाहिए। हम task unit के हिसाब से scope-limited cryptographic delegation tokens इस्तेमाल करते हैं, और MCP tool boundary पर उनकी verification करते हैं
      open source core tenuo में देखा जा सकता है
    • आजकल अच्छी AI tooling की कुंजी आज़ादी देना नहीं, बल्कि constraints देना है
      MCP, AI के decision-making और system के deterministic execution को साफ़ तौर पर अलग करता है। मैं Claude Code और MCP server साथ में इस्तेमाल करता हूँ; creative problem solving AI करता है और execution predictable path से होता है, इसलिए यह बहुत efficient है

  • MCP, AI apps के बीच communication के लिए एक fixed protocol specification है
    यह पुराने “integration” तरीके की तरह apps के बीच APIs को जबरन नहीं जोड़ता, बल्कि HTTP·FTP·SMTP की तरह reusable communication abstraction देता है
    AI को अलग-अलग services के साथ interact करना है, तो ऐसी common language की ज़रूरत है, ऐसा मेरा मानना है
    specification modelcontextprotocol.io/specification/2025-11-25 पर देखी जा सकती है

    • लेकिन कुछ लोग कहते हैं, “यह समस्या को गलत तरह से पहचानकर दिया गया समाधान है”
      असल में ज़रूरत नए protocol की नहीं, बल्कि gradually explorable CLI या API specification की है। उनका दावा है कि MCP बस उस दौर का अस्थायी उपाय है जब शुरुआती agents CLI चला नहीं पाते थे
    • एक और राय है: “अगर AI सच में AI है, तो HTTP या FTP को समझने के लिए अलग protocol की ज़रूरत ही क्यों है?”
      इस नज़रिए में MCP, आख़िरकार तकनीकी अपरिपक्वता का अस्थायी समाधान है
    • “क्या नया protocol बनाना ज़रूरी भी है?” यह बुनियादी सवाल भी उठाया गया
    • MCP पर यह आलोचना भी है कि यह असल में JSON-RPC के ऊपर रखा गया custom API definition भर है, इसलिए इसे मौजूदा तरीकों से ज़्यादा standard या reusable कहना मुश्किल है
    • कुछ लोगों का कहना है कि CLI tools भी आख़िरकार “reusable communication abstraction” ही हैं, इसलिए वे MCP से अलग नहीं हैं

  • जब MCP पहली बार आया था, तो वह overengineered कचरा जैसा लगा, इसलिए मैंने उसमें रुचि नहीं ली
    अब तक भी इसका कोई पछतावा नहीं है। LangChain के बारे में भी यही राय है। सिर्फ़ popular होने के कारण किसी चीज़ के पीछे भागना ख़तरनाक है

    • लेकिन अब मैं अपने हर code में MCP interface जोड़ रहा हूँ। इससे LLM के लिए debugging बहुत आसान हो गई है, और यह UI जितना महत्वपूर्ण component बन गया है
      बहुत कम समय निवेश करके भी बड़ा efficiency gain मिल सकता है
    • बेशक, ‘sniff test’ उपयोगी है, लेकिन सिर्फ़ वही काफ़ी नहीं
      कभी-कभी भद्दे tools ही complex integration problems को सरल तरीके से हल करके टिक जाते हैं
      अगर शुरुआत में बदसूरत लगने के कारण उन्हें नज़रअंदाज़ कर दिया जाए, तो बाद में standard infrastructure बनने का मौका छूट सकता है
    • LangChain overengineering नहीं, बल्कि पूरी तरह design-विहीन chaos है
    • कुछ लोग उल्टा यह कहते हैं कि MCP को लोकप्रियता बहुत simple होने की वजह से मिली
      इसे overengineered नहीं, बल्कि clear और intuitive structure माना जाता है
    • कुछ लोग अब भी नहीं जानते कि LangChain आख़िर है क्या

  • remote MCP ठीक लगता है क्योंकि authentication अपने-आप handle हो जाता है, इसलिए service access आसान हो जाता है
    लेकिन CLIs + Skills के मुकाबले इसमें context bloat ज़्यादा है, और pipeline processing या heredoc input जैसी Unix CLI की खूबियाँ खो जाती हैं
    CLI में --help output से अपने-आप skill generate किए जा सकते हैं, इसलिए यह efficient है
    MCP को persistent process चाहिए, जबकि CLI को ज़रूरत पड़ने पर ही चलाया जा सकता है

    • हाँ, CLI को install करना पड़ता है, लेकिन MCP का फ़ायदा यह है कि वह सिर्फ़ configuration से काम कर सकता है

  • मैं अब भी MCP को अनावश्यक layer मानता हूँ
    CLI > MCP इस बात से सहमत हूँ, लेकिन documentation और centralization के फ़ायदे दूसरे तरीकों से भी हासिल किए जा सकते हैं
    उदाहरण के लिए, Skills का इस्तेमाल करके CLI और API दोनों के लिए instructions रखे जा सकते हैं, और वे सिर्फ़ ज़रूरत के समय load होते हैं
    centralized MCP के फ़ायदे भी असल में मौजूदा proxy या AWS SSO से काफ़ी हद तक हासिल किए जा सकते हैं
    आख़िर में, मेरी राय में Skills से documentation देना और वास्तविक interaction को CLI या REST API से कराना बेहतर है

    • लेकिन इसके जवाब में यह तर्क भी दिया गया
      Skills की सामग्री आख़िरकार context में शामिल होकर load बढ़ाती है, और proxy से MCP की functionality पूरी तरह replace नहीं की जा सकती
      MCP में / command और @ references के ज़रिए prompts और resources को activate किया जा सकता है, जो proxy से संभव नहीं है
      संबंधित demo लेख के आख़िर में मौजूद .gif और MCP specification में देखे जा सकते हैं

  • मुझे लगता है MCP consumer environment के लिए ज़्यादा उपयुक्त है
    development environment में यह complex और inefficient है, लेकिन आम users MCP के ज़रिए आसानी से समझ सकते हैं कि model कौन-कौन से काम कर सकता है
    environment setup की ज़रूरत नहीं होती, और GUI में Siri या Google Assistant की तरह responses को visualize भी किया जा सकता है

    • वह GUI response system MCP progress spec में define किया गया है

  • कंपनी के भीतर non-developer users को AI tools देने के नज़रिए से, centralized MCP approach बहुत उपयोगी रही
    brand tone, internal terminology, shared data access और domain context जैसी चीज़ों को consistently manage किया जा सका
    MCP के resource methods के ज़रिए standardized “skills” दिए गए और data connection patterns को control किया गया

  • लेखक कई concepts को अलग-अलग कोणों से देखता है, लेकिन ऐसा लगता है कि वह Token Notation(TOON) जैसे पहले से मौजूद concepts से परिचित नहीं है
    ऐसा प्रभाव पड़ता है मानो वह चाह रहा हो कि ऐसी कोई चीज़ मौजूद हो

  • MCP की असली समस्या maintenance burden है
    उदाहरण के लिए, अगर GitHub integration चाहिए, तो अच्छी तरह documented API के बजाय npm wrapper पर निर्भर होना पड़ता है
    मैं तो बस gh CLI या curl इस्तेमाल करता हूँ। API बदल जाए तो agent नया documentation पढ़कर ख़ुद को ढाल लेता है
    MCP में तब तक इंतज़ार करना पड़ता है जब तक बीच का wrapper update न हो जाए
    security claims भी विरोधाभासी लगते हैं — शुरुआत में यह authentication के बिना आया था, और अब security को फ़ायदे के रूप में पेश करता है
    असल में chroot या scoped token जैसे पुराने तरीके इस समस्या को पहले ही हल कर चुके हैं
    MCP का एकमात्र साफ़ फ़ायदा non-developer OAuth flow में दिखता है। developer tools के लिए तो सीधे बेहतर CLI बनाना ज़्यादा सही लगता है