- 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 बेहतर होगी
अभी कोई टिप्पणी नहीं है.