MCP खत्म हो चुका है। CLI ज़िंदाबाद

 (ejholmes.github.io)
36 पॉइंट द्वारा GN⁺ 2026-03-02 | 8 टिप्पणियां | WhatsApp पर शेयर करें
  • MCP में इंडस्ट्री की दिलचस्पी तेज़ी से घट रही है, और अब CLI-आधारित approach ज़्यादा व्यावहारिक है
  • LLM पहले से ही command-line tools इस्तेमाल करने में बेहद सक्षम हैं, और अलग protocol के बिना भी सिर्फ documentation और CLI से पर्याप्त काम कर सकते हैं
  • CLI में इंसान और LLM दोनों एक ही environment में run और debug कर सकते हैं, इसलिए समस्या की जड़ समझना आसान होता है
  • composability, auth system, और reliability के लिहाज़ से भी CLI, MCP से अधिक efficient है और maintain करना आसान है
  • MCP initialization instability, बार-बार re-authentication, और permission control की कमी जैसी समस्याओं से real-world कामकाज में लगातार friction पैदा करता है
  • ज़्यादातर मामलों में CLI अधिक सरल और भरोसेमंद विकल्प है, और कंपनियों को MCP server से पहले API और CLI उपलब्ध कराने पर ध्यान देना चाहिए

MCP की सीमाएँ और CLI की बढ़त

  • Anthropic के Model Context Protocol(MCP) की घोषणा के बाद इंडस्ट्री ने तेजी से MCP server बनाने शुरू किए, लेकिन OpenClaw और Pi जैसे प्रमुख tools इसे support नहीं करते, और इसका कोई खास व्यावहारिक लाभ भी नहीं है
    • LLM पहले से ही CLI और documentation के जरिए काम कर सकते हैं
    • MCP नए endpoint और auth system जोड़ता है, लेकिन मौजूदा capabilities को ही दोहराता है
  • LLM, CLI tools इस्तेमाल करने के लिए बहुत अच्छी तरह optimized हैं और इसमें बेहद निपुण हैं
    • उन्होंने लाखों man page, Stack Overflow answers, GitHub shell scripts पर training ली है
    • उदाहरण के लिए, अगर Claude को gh pr view 123 command चलाने को कहा जाए, तो वह उसे सीधे चला सकता है
  • MCP ने एक अधिक साफ़ interface का वादा किया था, लेकिन व्यवहार में हर tool की description, parameters, और कब इस्तेमाल करना है, यह सब उसी तरह document करना पड़ता है

CLI इंसानों के लिए भी उपयोगी है

  • CLI में इंसान और LLM एक ही commands साझा कर सकते हैं
  • अगर Jira में कोई अप्रत्याशित व्यवहार दिखे, तो वही jira issue view command सीधे चलाकर उसे reproduce किया जा सकता है
  • MCP में tools सिर्फ LLM conversation के भीतर मौजूद होते हैं, इसलिए समस्या आने पर JSON transfer logs खंगालने की झंझट होती है
  • Debugging के लिए protocol decoder की ज़रूरत नहीं होनी चाहिए
  • CLI में input और output स्पष्ट होते हैं, इसलिए समस्या ट्रैक करना आसान है

संयोजनीयता (Composability)

  • CLI को jq, grep, file redirection आदि के साथ pipeline में जोड़ा जा सकता है
  • बड़े Terraform plan analysis का उदाहरण:
    • terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'
  • MCP में या तो पूरे plan को context window में dump करना पड़ता है, जो महंगा है और अक्सर संभव भी नहीं होता, या फिर MCP server में खुद custom filtering implement करनी पड़ती है
  • CLI approach पहले से मौजूद और अच्छी तरह documented tools का उपयोग करती है, जिसे इंसान और agent दोनों समझ सकते हैं

Auth की समस्या

  • MCP authentication के मामले में अनावश्यक रूप से बहुत opinionated है
  • CLI tools पहले से verified auth systems इस्तेमाल करते हैं: aws में profiles और SSO, gh में gh auth login, kubectl में kubeconfig
  • चाहे इंसान सीधे इस्तेमाल करे या Claude इसे चलाए, एक ही auth flow लागू होता है
  • Auth समस्या आने पर aws sso login, gh auth refresh जैसे मौजूदा तरीकों से समाधान हो सकता है; MCP-विशेष troubleshooting की ज़रूरत नहीं पड़ती

संचालन संबंधी समस्याएँ: गतिक हिस्सों का अभाव (No Moving Parts)

  • Local MCP server के लिए अलग process को शुरू और बनाए रखना पड़ता है, और Claude Code में यह child process के रूप में बनता है, जिससे कभी-कभी समस्याएँ होती हैं
  • CLI tools सिर्फ डिस्क पर मौजूद binary files होते हैं; इनमें background process, state management, या initialization procedure की ज़रूरत नहीं होती

व्यावहारिक काम में होने वाली असुविधाएँ

  • Initialization instability: MCP server शुरू न होने से Claude Code को बार-बार restart करना पड़ता है, और state reset के बाद फिर कोशिश करनी पड़ती है
  • बार-बार re-authentication: कई MCP tools इस्तेमाल करने पर हर एक के लिए अलग auth करना पड़ता है, जबकि SSO या long-lived credentials वाले CLI में यह समस्या नहीं है
  • Permission control की भद्दी व्यवस्था: Claude Code में MCP tools को नाम के आधार पर allow किया जा सकता है, लेकिन read-only restriction या parameter range तय नहीं की जा सकती
    • CLI में gh pr view को allow कर सकते हैं और gh pr merge के लिए approval माँग सकते हैं; यानी बहुत सूक्ष्म permission control संभव है

MCP कब उपयोगी हो सकता है

  • जब किसी tool का CLI समकक्ष बिल्कुल मौजूद न हो, तब MCP उपयुक्त हो सकता है
  • standardized interface के रूप में इसकी value और CLI की तुलना में MCP के लिए अधिक उपयुक्त use cases होने की संभावना को नकारा नहीं गया है
  • लेकिन अधिकांश कामों में CLI अधिक सरल, debug करने में तेज़, और अधिक भरोसेमंद है

मुख्य सबक और builders के लिए आग्रह

  • सबसे अच्छे tools वे हैं जो इंसान और मशीन दोनों के लिए काम करें; CLI दशकों के design iteration से composable, debug-friendly, और मौजूदा auth systems के साथ integrated बन चुकी है
  • MCP ने बेहतर abstraction बनाने की कोशिश की, लेकिन एक पर्याप्त अच्छी abstraction पहले से मौजूद थी
  • जो कंपनियाँ MCP server में निवेश कर रही हैं लेकिन उनके पास official CLI नहीं है, उन्हें अपनी strategy पर फिर से विचार करना चाहिए;
    अच्छा API → अच्छा CLI इस क्रम में उपलब्ध करा दिया जाए, तो agents उसे खुद ही उपयोग कर लेंगे
  • इससे अनावश्यक protocol complexity घटेगी और productivity व maintainability बेहतर होगी

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

8 टिप्पणियां

 
sonnet 2026-03-03

ऐसा नहीं है कि MCP के कोई फ़ायदे नहीं हैं; बल्कि लोग इस भ्रम से बाहर आए हैं कि जिन उपयोगों में MCP का कोई लाभ नहीं है, वहाँ भी उसे बिना सोचे-समझे इस्तेमाल किया जाए। जब microservices को LLM के लिए खोलना हो तब भी आप CLI नहीं इस्तेमाल करेंगे, और MCP तो एक 'API' protocol ही है।
 
brainer 2026-03-03

तब भी API इस्तेमाल कर सकते हैं। असल में MCP इस्तेमाल करने की वजह long context की सीमा थी, लेकिन अब उस सीमा को ज़्यादातर पार कर लिया गया है।
 
jamsya 2026-03-03

पूरी तरह सहमत हूँ।
aws mcp इंस्टॉल न करने पर भी Claude Code अपने-आप ज़रूरी चीज़ें aws cli से ले आता है 😂
 
GN⁺ 2026-03-02
Hacker News की राय

  • मैं लंबे समय से यह बात कहने से बच रहा था, लेकिन अब मुझे पक्का यक़ीन हो गया है कि MCP का कोई ठोस व्यावहारिक फ़ायदा नहीं है
    मैं ऐसे AI agents चला रहा हूँ जो मेरे पूरे development workflow को shell commands से नियंत्रित करते हैं, और ये पहली बार कोई CLI flag देखने पर भी सिर्फ --help output से उसे अच्छी तरह समझ लेते हैं
    दूसरी ओर, MCP servers हमेशा अस्थिर रहे और उन्हें लगातार manage करना पड़ा
    CLI को jq, grep, file redirection आदि के साथ compose किया जा सकता है, जबकि MCP server द्वारा लौटाए गए format में बंधा रहता है
    आख़िरकार, मुझे लगता है कि MCP को अपनाना तकनीकी कारणों से ज़्यादा सिर्फ़ ‘AI-first’ marketing signal है

    • MCP ने 2024 में तेज़ी से growth की, लेकिन 2025 की शुरुआत में terminal agents (Claude Code) के आने के साथ meta तेज़ी से बदल गया—मैं इसे ऐसा ही मामला मानता हूँ
    • मेरी राय उलटी है; मैं MCP को पसंद करता हूँ. CLI की तुलना में error handling और debugging कहीं ज़्यादा साफ़-सुथरी है, और dangerous flags को सीमित किया जा सकता है या results को pagination में बाँटा जा सकता है
      MCP को बस REST या gRPC की तरह एक wrapper concept समझना चाहिए
    • मैं भी MCP से बचता हूँ. मैंने JIRA MCP इस्तेमाल किया था और वह बहुत खराब था. इसके बजाय जब LLM ने API को सीधे call किया और scripts लिखीं, तो वह कहीं ज़्यादा प्रभावी था
      अभी मुझे लगता है कि LLM CLI tools सबसे आगे हैं
    • हमारी कंपनी internal wiki जैसे web-only tools को MCP के ज़रिए expose करती है ताकि Claude logs और metrics सीधे query कर सके
      लेकिन यह असुविधाजनक है कि MCP results हमेशा context window में चले जाते हैं. अच्छा होता अगर उन्हें filesystem में dump किया जा सकता
    • MCP servers ऐसे transitional artifact लगते हैं जो तब बनाए गए थे जब LLM उतने विकसित नहीं थे. मुझे लगता है कि CLI data पर training करना कहीं बेहतर है

  • MCP ऐसा black-box API है जिसे बिना installation या resource provisioning के तुरंत call किया जा सकता है
    दूसरी ओर, CLI local environment तक पहुँच सकता है, इसलिए वह कहीं ज़्यादा precise है
    jq, duckdb CLI का इस्तेमाल करके बड़े data files का sampling किया जाता है, और Opus 4.6 queries को अपने-आप adjust करते हुए explore करता है
    CLI की real-time responsiveness अच्छी होती है, इसलिए यह exploratory data analysis में खास तौर पर उपयोगी है
    अक्सर इस्तेमाल होने वाले CLI में showboat, br, psql, roborev आदि हैं

    • मेरा अनुभव भी ऐसा ही है. CLI का text input/output LLM training के तरीके से सबसे अच्छी तरह मेल खाता है
      ChatGPT के साथ duckdb इस्तेमाल करना मज़ेदार था; मैं जानना चाहता हूँ कि क्या local DB बनाए रखने के लिए system prompt सेट किया जाता है
    • CLI की जगह अगर Docker container में commands चलाई जाएँ, तो installation की समस्या से बचा जा सकता है. शायद इस approach को automate करने वाला कोई ‘skill’ भी बनाया जा सकता है
    • एक non-native English speaker के रूप में, MCPs जैसा plural इस्तेमाल करना मुझे दिलचस्प लगता है

  • MCP का मतलब तब है जब CLI में मौजूद न होने वाले tools खोजने हों और उन्हें context के हिसाब से call करना हो
    उदाहरण के लिए, मेरे द्वारा बनाया गया echomindr podcasts से founders के decision-making को extract करने वाला DB, MCP के रूप में उपलब्ध कराता है
    जब Claude को startup से जुड़ा सवाल मिलता है, तो वह वास्तविक founder experiences खोजकर जवाब देता है
    CLI तब उपयुक्त है जब इंसान पहले से जानता हो कि कौन-सा tool इस्तेमाल करना है, जबकि MCP discovery-based tool selection के लिए बेहतर है

  • लगता है लेखक ने AI उपयोग को सिर्फ़ developers के नज़रिए से देखा है
    ज़्यादातर users ChatGPT जैसे web-based interfaces से LLM का उपयोग करते हैं
    कंपनियों के लिए marketing, sales और project management tools को जोड़ने में MCP कहीं ज़्यादा उपयुक्त है

  • MCP अपने-आप में बुरा नहीं है, लेकिन stdio MCP को ज़रूरत से ज़्यादा डिज़ाइन किया गया है
    इसके बजाय Streamable HTTP + OAuth Discovery तरीका आजकल AI integration का सबसे कुशल माध्यम है
    उदाहरण के लिए, Sentry MCP में सिर्फ़ एक URL से authentication और data access संभव है
    समस्या MCP में नहीं बल्कि उसके implementation तरीके में है. bash से call करने के बजाय अगर MCP को HTTP endpoint के रूप में expose किया जाए, तो यह कहीं ज़्यादा लचीले ढंग से काम करेगा

    • CLI हो या MCP, दोनों की permission system को API स्तर पर एकसमान तरीके से डिज़ाइन किया जाना चाहिए. Streamable HTTP वाले हिस्से पर थोड़ी और व्याख्या चाहिए
    • मैं भी यही मानता हूँ. centralized authentication और telemetry कहीं ज़्यादा सरल हैं. बस इन्हें सही use case में इस्तेमाल किया जाना चाहिए

  • मेरे कुछ ग्राहकों के पास MCP server नहीं है, लेकिन developers उसकी माँग करते हैं
    आख़िर में हमने Postman API को JSON में export करके दिया, फिर भी developers MCP server चाहते थे
    यह वास्तविकता है कि MCP support marketing checklist की तरह काम कर रहा है

  • यह ब्लॉग developer-केंद्रित नज़रिए की तरफ़ झुका हुआ लगता है
    non-developer tools या services से जुड़ने के लिए MCP कहीं ज़्यादा स्वाभाविक है

    • सही बात. chat interfaces में CLI चलाना संभव नहीं है, और non-developer services के पास CLI होता ही नहीं
    • मैं भी सोच रहा था कि क्या ChatGPT या LeChat जैसे web/mobile interfaces में CLI चलाया जा सकता है
    • non-developer interfaces पहले से ही OpenClaw, Claude Cowork जैसे रूपों में evolve हो रहे हैं

  • “MCP में 5 साल अनुभव वाले लोगों की भर्ती” जैसी job postings आखिरकार बेमानी meme बन गईं

  • CLI के MCP से बेहतर होने का एक कारण यह भी है कि उसके पास information theory की दृष्टि से optimized format होता है
    Unix tools का output इस तरह व्यवस्थित होता है कि संबंधित जानकारी एक-दूसरे के पास रहती है, जिससे LLM का attention mechanism अधिक कुशलता से काम करता है
    JSON को parse करना आसान है, लेकिन उसे पढ़ना और उस पर reasoning करना असुविधाजनक है
    CLI format इंसानों और LLM दोनों के लिए intuitive है
    संबंधित संदर्भ: Entropy and Information Layout

  • MCP और CLI की तुलना कुछ वैसी है जैसे OpenAPI और string(JSON) की तुलना करना
    MCP औपचारिक रूप से परिभाषित है, जबकि CLI (String, List String, Map Int Stream) -> PID स्तर का एक abstract interface है
    अंततः दोनों API ही हैं; असली बात है लक्ष्य हासिल करने के लिए सही tool चुनना

    • लेकिन CLI --help के ज़रिए पूरा documentation देता है, इसलिए अगर LLM इसे समझ सकता है, तो यह मानना मुश्किल है कि MCP standardization ज़रूरी रूप से बेहतर है
    • theory से ज़्यादा वास्तविक उपयोग का अनुभव मायने रखता है. अगर कोई कहता है कि MCP और CLI एक जैसे हैं, तो उसे उदाहरण के तौर पर Playwright CLI और MCP के साथ समान token usage और configurability दिखाने वाला उदाहरण बनाना चाहिए
      नहीं तो व्यवहार में दोनों approaches अलग हैं—यह बात सीधे अनुभव से महसूस होगी
 
develosopher 2026-03-03

अगर किसी ने SaaS बनाया है और AI integration के लिए cli बनाम mcp में से एक चुनने पर सोच रहा है, तो शायद वह पहले mcp चुनेगा। CLI को support करना management points बढ़ाने जैसा है। दोनों साथ रह सकते हैं, लेकिन ऐसा नहीं लगता कि इनमें से कोई गायब हो जाएगा।
 
hanje3765 2026-03-03

ऐसा लगता है कि जैसे-जैसे llm की बुद्धिमत्ता बढ़ी है, mcp की ज़रूरत भी अस्पष्ट हो गई है।
मैंने भी वास्तव में ऐसा ही महसूस किया है।
 
m00nlygreat 2026-03-03

ऐसा लगता है कि remote execution को MCP से और local execution को skills से व्यवस्थित किया जा रहा है।
 
hulryung 2026-03-03

मैंने भी MCP की जगह CLI से सीधे अपने टूल बनाकर इस्तेमाल करना शुरू कर दिया है।