Tools: सिर्फ़ कोड काफ़ी है - Code Is All You Need

 (lucumr.pocoo.org)
20 पॉइंट द्वारा GN⁺ 2025-07-04 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • यह दावा किया जाता है कि MCP शैली की tool integration ही "भविष्य" है, लेकिन वास्तव में composability की कमी और context की अत्यधिक खपत जैसी सीमाओं के कारण सीधे कोड लिखने का तरीका अब भी ज़्यादा कुशल है
  • LLM के दौर में भी automation और दोहराए जाने वाले कामों में code को generate/use करना reliability और verification के लिहाज़ से बेहतर है
  • LLM की ताकत reasoning-आधारित automation से ज़्यादा code generation और repeated execution में है, और code-based process में समस्या पहचान, verification और scalability बेहतर होती है
  • Playwright जैसे कुछ tools (MCP शैली) में हर "reasoning-based" चरण पर uncertainty और debugging की कठिनाई बढ़ती है, जबकि code से script को सीधे generate/modify करने पर repeatability, speed और reliability सभी बेहतर होते हैं
  • LLM द्वारा code generate करना, और फिर किसी दूसरे LLM द्वारा उस code की review/explain करना वाला "code-review-iterate" loop वास्तव में सबसे शक्तिशाली automation flow है

सिर्फ़ कोड काफ़ी है

  • अगर आप मुझे Twitter पर follow करते हैं, तो आपको पता होगा कि हाल में मैं Model Context Protocol(MCP) को लेकर बहुत सकारात्मक नहीं रहा हूँ
  • वजह यह नहीं है कि मुझे इस idea से ही आपत्ति है, बल्कि यह है कि MCP वैसा प्रभावी नहीं है जैसा उसका प्रचार किया गया
  • MCP में दो बड़ी कमियाँ हैं
    • यह सचमुच composable नहीं है
    • बहुत ज़्यादा context देने की ज़रूरत के कारण, सीधे code लिखकर चलाने की तुलना में context की खपत और अधिक होती है
  • इसे एक सरल experiment से देखा जा सकता है
    • उदाहरण के लिए, GitHub MCP का उपयोग करके कोई task कीजिए, फिर वही काम gh CLI tool से कीजिए; दूसरा तरीका context का कहीं बेहतर उपयोग करता है और नतीजे तक भी तेज़ी से पहुँचता है

But MCP is the Future! : लेकिन MCP ही तो भविष्य है?

  • मैं उस feedback के बारे में बात करना चाहता हूँ जो मुझे इस रुख़ पर मिला है कि code बेहतर है
  • मैंने MCP पर agentic coding के संदर्भ में गहराई से प्रयोग किए हैं, और उसे वहीं परखा है जहाँ उसकी सीमाएँ सबसे साफ़ दिखाई देती हैं
  • एक feedback यह था कि "generic code generation के लिए MCP की खास ज़रूरत नहीं है, क्योंकि models वैसे ही code generation में काफ़ी अच्छे हैं।" वहीं कुछ विशेष domains (जैसे किसी financial company के automation task) जैसी end-user-oriented applications में MCP उपयोगी हो सकता है
  • एक और राय यह थी कि भविष्य में models और अधिक tools तक पहुँच पाएँगे और और जटिल काम भी संभाल पाएँगे, इसलिए उस संभावना पर ध्यान देना चाहिए
  • लेकिन मेरी मौजूदा राय यह है: मेरे प्रयोगों के data और वास्तविक अनुभव के अनुसार, आज का MCP हमेशा सीधे code लिखने की तुलना में अधिक कठिन है
    • सबसे बड़ा कारण यह है कि MCP inference पर निर्भर करता है
    • आजकल "LLM से और ज़्यादा tools जोड़ने" की लगभग हर कोशिश में आखिरकार एक ऐसा layer आ ही जाता है जहाँ LLM सभी tools को लेकर काम के अनुसार filter करता है
    • अब तक इससे बेहतर कोई architecture या approach सामने नहीं आई है
  • इसलिए मेरा निष्कर्ष यह है: non-developers के लिए domain-specific automation जैसे विशेष मामलों में भी, अंततः code generation ही composability और reusability के लिहाज़ से हमेशा बेहतर विकल्प है

Replace Yourself With A Shellscript

  • इस समस्या को देखने का एक तरीका यह है: AI के बिना भी, developer के लिए समस्या हल करने का tool code ही होता है
  • अगर आप non-developer हैं, तो code कठिन लग सकता है, और जो कई काम लोग हाथ से करते हैं वे असल में software से automate किए जा सकते हैं
  • व्यावहारिक समस्या यह है कि वह code लिखेगा कौन। अगर आप किसी विशेष environment में हैं और खुद programming नहीं कर सकते, तो नई coding सीखना भी मुश्किल है, और किसी से उम्मीद करना भी कठिन है कि वह आपके लिए custom code लिख दे
  • बेशक कुछ कामों में reasoning (मानवीय निर्णय/लचीलापन) ज़रूरी हो सकता है, लेकिन वास्तविकता में अधिकतर दोहराए जाने वाले और स्पष्ट काम code से automate किए जा सकते हैं
  • "खुद को shell script से replace कर देना" developers का एक पुराना मुहावरा है, और ऐसी automation बहुत पहले से चलती आ रही है
  • LLM और programming के इस दौर में, shell script की जगह LLM से खुद को replace करने की कोशिश हो रही है, लेकिन यहाँ तीन समस्याएँ (cost, speed, reliability) सामने आती हैं
  • इन तीन समस्याओं को हल किए बिना, tools (जैसे MCP) के उपयोग पर विचार करना भी जल्दबाज़ी है
  • यानी सबसे ज़रूरी बात यह सुनिश्चित करना है कि automation वास्तव में scalable तरीके से सही काम कर रही है या नहीं

Automation at Scale : बड़े पैमाने की automation का सार

  • automation का मूल यह है कि दोहराए जा सकने वाले, reusable कामों को code से संभाला जाए
  • जो काम सिर्फ़ एक बार करना है और फिर कभी नहीं, उसे automate करने की ज़रूरत नहीं। automation वहीं से शुरू होती है जहाँ काम बार-बार होना हो और मशीन सचमुच productivity का फ़ायदा दे
  • व्यवहार में, 1-2 बार काम manually करके, उसके working pattern को समझकर, फिर मशीन से उसे हज़ारों बार दोहरवाना ही automation का सार है
  • ऐसी repetitive automation में हमेशा "code" लिखना ही सबसे अच्छा है
    • अगर हर बार LLM से "reasoning" करवाएँ, तो छोटे काम किसी तरह हो सकते हैं, लेकिन verification में लगने वाला समय और मेहनत automation के लाभ को कम कर देती है
    • उदाहरण: LLM से सीधे calculation करवाने के बजाय, LLM से Python code लिखवाकर उसी code से calculation करवाई जाए, तो reliability और scalability दोनों बढ़ती हैं
      • code का उपयोग करने पर formula/logic की खुद review की जा सकती है, और ज़रूरत पड़ने पर सीधे बदला भी जा सकता है, या LLM से यह review कराया जा सकता है कि "क्या यह तरीका सही है"
      • Python calculation ग़लत कर देगा, इसकी चिंता नहीं करनी पड़ती, इसलिए verification और trust के लिहाज़ से code generation वाला तरीका बेहतर है
  • यही तर्क साधारण calculation से आगे बढ़कर वास्तविक development work पर भी लागू होता है
    • उदाहरण: हाल में मैंने इस ब्लॉग के पूरे format को reStructuredText से Markdown में बदलने का काम किया
    • मैं इसे काफ़ी समय से टाल रहा था; एक कारण आलस्य था, लेकिन दूसरा यह भी कि अगर LLM से सीधे conversion करवाता, तो कहीं न कहीं सूक्ष्म omission/mistake या context distortion होने का भरोसा नहीं था
    • इसलिए अंत में मैंने LLM को "सीधा conversion चलाने" के लिए नहीं, बल्कि conversion code generate करने के लिए इस्तेमाल किया, और काम code से किया

LLM → कोड → LLM: iterative verification automation का वास्तविक रूप

  • पहले चरण में, मैंने LLM से reStructuredText को Markdown में बदलने वाला core conversion logic generate करने को कहा
    • यह केवल साधारण conversion नहीं था, बल्कि AST (abstract syntax tree) का सीधा उपयोग करते हुए
      • reStructuredText को AST में parse करना → Markdown AST में convert करना → HTML में render करना
      • ऐसा करने से मध्यवर्ती conversion चरण मिल जाता है, और नतीजों की तुलना व verification आसान हो जाती है
  • दूसरे चरण में, मैंने LLM से existing HTML और नए HTML की तुलना करने वाली script भी लिखवाई
    • conversion के बाद HTML diff का विश्लेषण करते हुए, तुलना से पहले मामूली अंतर (जैसे whitespace, footnote handling आदि) अपने-आप normalize हो जाएँ, ऐसा design किया
    • conversion प्रक्रिया में कौन-सी error types स्वीकार्य हैं, यह भी LLM से ध्यान में रखा गया
    • उदाहरण: भले ही Markdown/reStructuredText libraries का HTML output थोड़ा अलग हो, script में इस तरह संभाला गया कि सिर्फ़ वास्तविक loss/error ही पकड़े जाएँ
  • तीसरे चरण में, मैंने LLM से सैकड़ों files के परिणामों का batch analysis करने वाली script भी अतिरिक्त रूप से लिखवाई
    • इस script से सभी files पर चलाकर, अंतर कम होते जाने तक iterative improvement (agentic loop) चलाया गया
  • पूरी प्रक्रिया कुछ इस तरह थी:
    • शुरुआत में लगभग 10 samples पर चलाया गया और differences काफ़ी कम होने तक iteration की गई
    • संतोषजनक स्थिति आने पर उसे सभी posts पर लागू किया गया, और लगभग 30 मिनट में पूरा काम अपने-आप हो गया
    • मुख्य बात यह नहीं थी कि LLM ने conversion को वास्तव में 'सफल' कर दिया, बल्कि यह थी कि मैं पूरे process को "code" के रूप में verify और review कर सकता था, इसलिए उस पर भरोसा कर सका
  • इसके अलावा, एक दूसरे LLM से generated code और changes की जाँच/व्याख्या कराकर और अधिक विश्वास हासिल किया गया
    • यक़ीन था कि conversion बिना data loss के, mechanical correctness के साथ हुआ है, और sample check या fix कभी भी आसान था
    • सबसे बुरी स्थिति में भी Markdown syntax की मामूली गड़बड़ी हो सकती थी, लेकिन असली body content के बिगड़ने जैसी बात नहीं हुई
  • एक और अहम बिंदु यह है कि इस तरीके में inference cost स्थिर रहती है, इसलिए कुल files की संख्या (15 बनाम 150) के हिसाब से बोझ में बहुत बड़ा अंतर नहीं आता
    • final analysis चरण में मामूली differences पहले ही automatically skip हो जाते हैं, इसलिए bulk conversion में iterative verification का भार बहुत नहीं बढ़ता

MCP Cannot Do That

  • इस लंबी चर्चा का सार यह है कि पूरा conversion और automation pipeline "code" पर चलता है
    • human input → code generation → LLM review → iterative improvement, यह संरचना सामान्य tasks पर भी उसी तरह लागू की जा सकती है
  • उदाहरण के लिए, MCP शैली का एक प्रतिनिधि उदाहरण Playwright है
    • यह browser को remotely control करने वाला automation tool है, जिसमें page को पढ़ना, समझना, button दबाना आदि हर चरण में inference दोहराया जाता है
    • इस तरह के tasks को वास्तव में "code approach" से पूरी तरह replace करना आसान नहीं है
  • लेकिन, अगर page structure पहले से पता हो (जैसे मेरी खुद की app के test)
    • LLM से Playwright Python script generate करवाकर उसे चलाना कहीं तेज़ और ज़्यादा reliable है
    • इस तरीके में एक बार script बन जाने पर उसे दर्जनों, सैकड़ों बार दोहराया जा सकता है, और अतिरिक्त inference की ज़रूरत नहीं रहती
    • हर बार real time में screen को interpret करने या buttons की location खोजने की ज़रूरत नहीं होती, और पूरी automation flow को एक साथ चलाया जा सकता है
  • MCP शैली में हर चरण पर abstracted tool call और inference की ज़रूरत पड़ती है, इसलिए LLM को हमेशा सही तरह काम करवाना बहुत मुश्किल होता है, और debugging भी कठिन होती है
    • उदाहरण के लिए, अगर MCP client को shell script में embed करके efficient remote service calls करनी हों, तो व्यवहार में यह तरीका बहुत inefficient और लागू करने में कठिन साबित होता है
  • आखिरकार, मैं इंसान हूँ, MCP client नहीं।
    • code को चलाना और debug करना आसान है, लेकिन MCP calls हर बार अनिश्चित होती हैं और उन पर भरोसा नहीं किया जा सकता
    • वास्तव में मैं LLM द्वारा code generation के दौरान बनाए गए छोटे tools (जैसे Claude Code के snippets) को ही अपने development process के long-term tools के रूप में ज़्यादा उपयोग कर रहा हूँ

यह निष्कर्ष आगे कहाँ ले जाता है?

  • सच कहूँ तो मुझे भी नहीं पता कि यह प्रवाह आगे कहाँ जाएगा। लेकिन अभी वह सही समय है जब "intentional agentic coding" के लिए code generation के तरीकों को और कैसे बेहतर बनाया जाए, इस पर सोचना चाहिए
  • यह अजीब लग सकता है, लेकिन कभी-कभी MCP सचमुच बहुत अच्छा काम भी करता है। फिर भी मौजूदा structure बहुत ज़्यादा "inference" पर निर्भर है, और scalable large-scale automation के लिए एक अनुपयुक्त dead end जैसा महसूस होता है
  • इसलिए शायद उन क्षेत्रों को अधिक स्पष्ट रूप से अलग और abstract करना होगा जहाँ MCP अपनी ताकत दिखा सकता है, और जहाँ code generation approach की भूमिका है
    • इसके लिए बेहतर sandbox (safe execution environment) बनाने होंगे, और agent को API के साथ खुलकर fan out/fan in reasoning करने देने के लिए API design बदलने जैसी कोशिशें भी ज़रूरी होंगी
    • मेरा मानना है कि "जो कुछ code से किया जा सकता है, उसे जितना हो सके code से किया जाए", और बड़े पैमाने पर execution के बाद LLM पूरे परिणाम का judgment/review करे, यही बेहतर संरचना है
  • और अगर code generation process में पर्याप्त contextual information जोड़ दी जाए, ताकि LLM generated script क्या करती है यह non-developers को natural language में समझा सके, तो भविष्य में non-developers भी इस automation flow का आसानी से उपयोग कर पाएँगे
  • निष्कर्षतः, मैं MCP के बजाय LLM की code generation क्षमता का अधिक साहसिक उपयोग करने और नई संभावनाओं के साथ प्रयोग करने की सलाह देता हूँ
  • अगर LLM को code सीधे लिखने दिया जाए, तो हम अपनी कल्पना से कहीं ज़्यादा चीज़ों को automate कर सकते हैं

संदर्भ सामग्री

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

2 टिप्पणियां

 
bluems 2025-07-04

मैं सहमत हूँ, लेकिन यह MCP की समस्या से ज़्यादा उसके implementation यानी design direction के optimization जैसा लगता है। एक ही फ़ंक्शन करने पर भी, किस तरह का MCP है उसके अनुसार अंदरूनी तौर पर code और commands generate करके अनावश्यक काम कम किए जा सकते हैं। अगर Github mcp की जगह gh cli mcp या terminal mcp का इस्तेमाल करें, तो tokens तो लगते हैं, लेकिन बहुत कम लगते हैं, और वही असर हासिल किया जा सकता है—मुझे लगता है कि इस हिस्से को नज़रअंदाज़ किया गया है।
 
GN⁺ 2025-07-04
Hacker News राय

  • आम तौर पर मैं सहमत हूँ कि दिशा यही सही है। बड़े पैमाने पर LLM का उपयोग अक्सर दो मज़बूत इंटरफ़ेस के बीच की खाई भरने के लिए किया जाता है। विश्वसनीयता का मूल LLM के आउटपुट से नहीं, बल्कि वास्तव में इस बात से आता है कि वे इंटरफ़ेस स्वयं केवल कुछ निश्चित सेटिंग्स की ही अनुमति देते हैं।
    LLM का आउटपुट अक्सर type या DB primary key जैसे अधिक deterministic मानों में जबरन बदला जाता है। LLM का मूल्य इस बात पर बहुत निर्भर करता है कि मौजूदा code और tools मेरे domain के data, logic, और behavior को कितनी अच्छी तरह model करते हैं।
    मुझे व्यक्तिगत रूप से आजकल LLM कुछ हद तक 3D printer जैसा लगता है। दोनों तेज़ prototyping में हिस्सों को जल्दी जोड़ देते हैं, लेकिन अगर scalability और robustness चाहिए तो अंत में engineer या LLM को उन अस्थायी जोड़ियों को metal/code जैसे deterministic support से बदलना पड़ता है।
    3D printer के बारे में पहले जैसी बढ़ा-चढ़ाकर की गई उम्मीदों की तरह LLM भी ऐसा लग सकता है कि वह हर operational reality को बदल देगा, लेकिन वास्तव में वह तभी सच में उपयोगी होता है जब मौजूदा digital modeling एक मज़बूत आधार दे रही हो

    • drone या VR के बढ़ा-चढ़ाकर बताए गए hype cycle भी ऐसे ही थे। सबको लगा था कि drone से हर parcel डिलीवर होगा और हम VR में पूरा दिन बिताएँगे, लेकिन वास्तविक use case उससे कहीं संकरे निकले
    • दिलचस्प राय है, लेकिन LLM के बारे में यह नज़रिया कुछ ज़्यादा ही conservative लगता है। वास्तव में LLM पहले से ही deep research और translation जैसे क्षेत्रों में बड़े पैमाने पर उपयोग हो रहे हैं, और 3D printer की तुलना में कहीं अधिक general-purpose तरीके से फैल चुके हैं
    • "दिशा सही है" वाली बात से मैं सहमत हूँ। हमारी कंपनी में भी, पूरी तरह सही न होने पर, हम अक्सर 'directionally accurate' शब्द का उपयोग करते हैं। मतलब, मोटे तौर पर सही दिशा में होना

  • LLM tools का उपयोग करते हुए मुझे एक बात समझ आई। अगर आप समस्या को sandbox के भीतर इस तरह घटा दें कि LLM tools को बार-बार इस्तेमाल कर उसे हल कर सके, तो उस समस्या को brute force से हल किया जा सकता है। यहाँ असली बात है ऐसे problems की पहचान करना, सही sandbox और सही tools चुनना, और सफलता के मापदंड तय करना।
    इस प्रक्रिया में भी काफ़ी skill और अनुभव चाहिए, लेकिन यह हाथ से बार-बार trial-and-error करने की तुलना में कहीं अधिक उच्च-स्तरीय काम है।
    मुझे यह बात अपने 'assembly Mandelbrot experiment' के दौरान समझ आई।
    (प्रयोग लिंक: https://simonwillison.net/2025/Jul/…)

    • "सफलता के मापदंड तय करना" आखिर में ज़रूर चाहिए। अगर आपको fractal math या x86 assembly नहीं आती, तो "क्या चित्र Mandelbrot जैसा दिखता है?" जैसी visual check के अलावा कोई verification नहीं बचता।
      आदर्श रूप से किसी continuous-function जैसी evaluation metric, या कम-से-कम अलग-अलग input और उनके अपेक्षित output को quantitative रूप में तय करना होगा, तभी सच्चा automation संभव है
    • यह experiment सच में दिलचस्प है। मैं भी LLM के साथ brute-force problem solving के बारे में सोच रहा था।
      उदाहरण के लिए LLM TypeScript generics में कमज़ोर है, लेकिन अगर आप असली TSC चलवा दें तो वह tests के ज़रिए बार-बार verify करके सही होने तक कोशिश कर सकता है। हो सकता है code maintainability घट जाए, लेकिन सैद्धांतिक रूप से यह बहुत रोचक संरचना है।
      ऊपर से Cursor TypeScript errors देख सकता है, इसलिए अगर utility type tests बना दिए जाएँ तो Cursor खुद tests लिखकर समस्या को साधारण iterative brute force से हल भी कर सकता है
    • मेरे अनुभव में LLM से काम के अनुरूप tool इस्तेमाल करवाना अभी भी एक बड़ी चुनौती है। कभी-कभी यह बच्चों को कपड़े धोना सिखाने जैसा लगता है, और तब मन करता है कि मैं खुद ही कर लूँ
    • LLM को सही context देना महत्वपूर्ण है। उदाहरण के लिए, पहले से परिभाषित "cognitive tools" का उपयोग करके context को समृद्ध किया जाए, तो performance में साफ़ सुधार आता है।
      देखने लायक repo: https://github.com/davidkimai/Context-Engineering/…
      मैंने अभी पूरा नहीं देखा, लेकिन काफ़ी प्रभावशाली लगा
    • मैं सोच रहा हूँ कि sandbox में tool loop चलाने का यह तरीका क्या cloud API पर बहुत token खर्च करके ही संभव है।
      क्या यह local model से भी हो सकता है, या फिर Claude Code Pro जैसी subscription से किया जा सकता है?
      Mandelbrot experiment मज़ेदार था, लेकिन वास्तविक जटिल commercial codebase की कठिनाई थोड़ी अलग है

  • मुझे नहीं लगता कि यह MCP की समस्या है। मौजूदा AI स्तर पर human-in-the-loop संरचना कहीं बेहतर है।
    LLM कुछ खास tasks में मज़बूत होते हैं, लेकिन अक्सर local minima में फँस जाते हैं। इसलिए web interface में आगे-पीछे करते हुए "program लिखो → जाँचो और hint दो → test" वाला loop चलाने पर quality स्पष्ट रूप से बेहतर होती है।
    10,000 lines के अस्त-व्यस्त code को 400 lines के साफ़ code में बदला जा सकता है। अभी के लिए यही वास्तविकता है।
    बेशक कई कंपनियाँ या developers "programmer को ही LLM से replace" करना चाहेंगे, लेकिन व्यवहारिक रूप से अभी यह संभव नहीं है।
    असली असर यह है कि programmer की काम की गति कई गुना बढ़ जाती है, या beginners LLM की मदद से जल्दी productive काम कर पाते हैं। लेकिन "agentic coding" अभी अच्छी तरह काम नहीं करती।
    मौजूदा स्थिति में LLM को सहकर्मी या सहायक की तरह इस्तेमाल करना ही सही है। अभी की हकीकत यह है कि यह autonomous feedback के बिना काम करने वाला "AI agent" नहीं है

    • मैं खुद अपना product developer हूँ, सारा code अकेले संभालता हूँ और claude-code को tool की तरह इस्तेमाल करता हूँ। उम्मीद है कि किसी दिन Claude पूरा coding workload संभाल ले, लेकिन हम अभी वहाँ तक नहीं पहुँचे हैं।
      मैं type-safe, functional, compiled language में काम कर रहा हूँ, इसलिए output मुझे हमेशा खुद पढ़ना पड़ता है; कम सख्त language होती तो शायद और चिंता होती।
      फिर भी समय की बचत बहुत है। खासकर tasks को तोड़कर बड़े goal को संभालना आसान हो गया है, यह बात मुझे बहुत पसंद है

  • मैंने सचमुच GitHub MCP से tasks करके देखे हैं, और वही काम अगर gh CLI से किया जाए तो gh CLI context का कहीं अधिक कुशल उपयोग करती है, इसलिए गति बहुत तेज़ हो जाती है।
    मेरे पास "devops" folder में CLAUDE.md file है, जो common bash commands का संग्रह है।
    जब कोई नया task पूरा होता है, तो मैं Claude से उसमें एक example जोड़ने को कहता हूँ, और बाद में मिलते-जुलते queries पर Claude उसे एक ही बार में हल कर देता है।
    CLAUDE.md की शुरुआती सामग्री साझा कर रहा हूँ:

    • यह file Claude Code को code tasks के दौरान guidance देती है
    • खास तौर पर GCP-संबंधित DevOps commands (Cloud Composer, Logging, Kubernetes, Cloud Run) को document करती है
    • मुख्य command examples: environment details देखना, DAG manage करना, Airflow logs जाँचना आदि
      (विशिष्ट commands का सारांश)
    • कभी-कभी मुझे उलझन होती है। जब ज़रूरी command cheat-sheet file पहले से हो, तब AI से सिर्फ उसे चलवाने के लिए इंतज़ार करना inefficient लगता है
    • जानकारी के लिए, उन commands वाले section को अगर एक साधारण stdio MCP server बना कर Claude Code से जोड़ा जाए, तो हर task को tool बनाया जा सकता है और input schema भी परिभाषित किया जा सकता है। इसके लिए पहले से capability देने वाला MCPServer open source भी है (उदाहरण: https://github.com/inercia/MCPShell)
    • मैं भी इसी तरह की command collection file Emacs org-mode में खुद उपयोग करता हूँ। fold/unfold करना आसान होता है, इसलिए efficient है, और code snippets (shell, elisp आदि) तुरंत execute भी किए जा सकते हैं
    • मैं जानना चाहता हूँ कि क्या आप LLM को production/test environment में privileged API calls की अनुमति सीधे दे रहे हैं, या सिर्फ sanity-check किए जा सकने वाले example commands ले रहे हैं। ठोस use case जानने में दिलचस्पी है
    • मैंने भी मिलती-जुलती संरचना अपनाई थी, लेकिन claude.md धीरे-धीरे बहुत बड़ा हो गया और असुविधाजनक लगने लगा। इसलिए मैंने custom prompts को app की तरह पैकेज कर स्थिति सुधारी, लेकिन app deterministic होने के कारण अनजान स्थितियों से निपटने में कमज़ोर है। दूसरी ओर, CC भले धीमा हो, पर अज्ञात स्थितियों को संभाल सकता है।
      इसलिए, समस्या आने पर command में app test और fix command जोड़ देने से यह self-healing software जैसा बन गया

  • अब तक MCP के जितने उपयोग देखे, उनमें सबसे प्रभावशाली Bruce Hauman का clojure-mcp लगा।
    यह LLM को (a) bash, (b) persistent Clojure REPL, और (c) structural editing tools देता है।
    इसकी वजह से Clojure code edit करते समय यह साधारण text diff-आधारित approach की तुलना में कहीं अधिक कुशलता से काम करता है।
    अगर सही test suite हो, तो file edit, reload, और test repeat करने का flow इंसानी काम के काफ़ी क़रीब चला जाता है, जो मुझे चौंकाने वाला लगा

    • मुझे भी clojure-mcp अब तक देखे गए MCP उपयोगों में सबसे शानदार लगता है।
      यह code debug, individual expressions evaluate करने, function return type document करने जैसी प्रमुख सुविधाएँ देता है।
      मुझे लगा कि शक्तिशाली REPL वाली languages इन capabilities में बहुत बेहतर होती हैं, और clojure-mcp की संभावना देखकर AI के बारे में मेरा नज़रिया काफ़ी बदल गया
    • संदर्भ के लिए official repo link: https://github.com/bhauman/clojure-mcp

  • GitHub CLI वाला उदाहरण MCP की ताकत को पूरी तरह नहीं दिखाता।
    gh CLI जैसे tools, जिनकी documentation अच्छी तरह उपलब्ध है, उनमें LLM आसानी से code generate कर लेता है, इसलिए स्वाभाविक है कि वह उन्हें बेहतर इस्तेमाल करे।
    लेकिन MCP की असली ताकत internal-only tools या लगभग बिना online documentation वाले niche API में दिखती है।
    सारे documents को context में ठूँसने का तरीका एक विकल्प है, लेकिन ऐसे मामलों में MCP कहीं अधिक efficient हो सकता है।
    अगर कोई अच्छा MCP tool सही input के साथ उपयोग किया जाए, तो LLM पर API समझने, authentication संभालने, edge cases manage करने का बोझ बहुत कम हो जाता है।
    GitHub के लिए शायद MCP की विशेष ज़रूरत न हो, लेकिन internal या अधूरे APIs वाले माहौल में पहले से बनाए गए MCP tools कहीं ज़्यादा असरदार होते हैं

    • MCP भी आखिरकार documentation को LLM input context में inject करने का ही एक तरीका है। जिन environments को LLM पहले से अच्छी तरह जानता है (Python, JavaScript, bash आदि), वहाँ MCP tool call करने से बेहतर है कि वह अपनी जानी-पहचानी पद्धति उपयोग करे; उल्टा tool definitions context भी खा जाती हैं।
      उदाहरण के लिए sonnet4 में 15 tools से आगे जाते ही सीमा महसूस होने लगती है। सिर्फ official playwright MCP ही काफ़ी tool capacity खर्च कर देता है
    • MCP server authentication वगैरह को सरल बनाता है, लेकिन यह तर्क भी दिया जा सकता है कि internal API को शुरू से ही ऐसे design क्यों नहीं किया गया।
      अंततः MCP का एकमात्र फ़ायदा शायद बस इतना हो कि जब API बहुत कठिन लगे, तो यह फिर से साबित हो कि "असल समस्या इसकी अनावश्यक जटिलता थी"

  • Playwright वाले उदाहरण पर,
    मैंने भी इस हफ़्ते Playwright MCP server के आधार पर agent बनाया था, लेकिन वह धीमा, token के लिहाज़ से inefficient, और reliability में कमज़ोर निकला, इसलिए मैं फिर सीधे Playwright calls पर लौट आया।
    MCP server यह जाँचने के लिए अच्छा है कि क्या-क्या संभव है, लेकिन व्यवहार में API calls अधिक efficient और स्थिर रहते हैं।
    मेरे बनाए personal LinkedIn agent का उदाहरण और demo साझा कर रहा हूँ:

    • Playwright MCP implementation भी मेरे लिए कुछ ज़्यादा ही भारी-भरकम solution था। मुझे यह Playwright API के सिर्फ एक सीमित हिस्से की नकल करने वाली reference implementation जैसा लगा।
      LinkedIn automation के लिए बेहद कठिन platform माना जाता है; personal LinkedIn agent बनाते समय क्या आपको कठिनाइयाँ या सीमाएँ झेलनी पड़ीं, यह जानने की जिज्ञासा है

  • सच कहूँ तो मुझे लगता है सिर्फ terminal ही काफ़ी है।
    मैंने कई महीनों तक MCP रोज़ाना इस्तेमाल किया, लेकिन अब मैं सिर्फ एक iTerm2-आधारित MCP server (terminal) इस्तेमाल करता हूँ।
    ज़रूरत पड़ने पर OpenAPI spec मौजूद है, लेकिन व्यवहार में shell commands और curl से लगभग सब कुछ किया जा सकता है

    • मैंने भी पहली बार यह समझा कि LLM जब bash shell के built-in tools का उपयोग करता है, तो bash से क्या-क्या संभव है इसकी सीमा वास्तव में कितनी दूर तक जाती है

  • "बहुत ज़्यादा context चाहिए" वाली बात का समाधान वास्तव में शुरुआती prompt defaults सही सेट करना है।
    Claude Code और Gemini CLI समेत प्रमुख tools यह सब support करते हैं
    LLM को सारे tools की सूची देकर खुद फ़िल्टर करने देना आदर्श तरीका नहीं है, लेकिन
    नए LLM लगातार बेहतर हो रहे हैं, और व्यवहार में मुझे उपयुक्त MCP function चुनने में कभी बड़ी दिक्कत नहीं हुई।
    cost, speed, और reliability के सवाल पर भी

    • cost: हाल में यह लगातार सस्ता होता जा रहा है। वास्तव में काफ़ी हैरान करने वाला value-for-money है।
    • speed: कई tasks एक साथ कराए जा सकते हैं, इसलिए यह inefficient नहीं है।
      आपको बातचीत में अपना समय सीधे खर्च नहीं करना पड़ता
    • reliability: यह काफ़ी हद तक prompt quality पर निर्भर करती है।
      हाल का उदाहरण दूँ तो Notion, Linear, git, GitHub PR/CI logs जैसे कई external tools LLM ने अपने-आप संभाल लिए,
      और मुझे सिर्फ एक बार PR review करना पड़ा।
      लागत भी 1 डॉलर से कम रही
    • MCP tools जितने बढ़ते हैं, शुरुआती prompt context की खपत उतनी ही बढ़ती जाती है।
      बल्कि tools जोड़ते जाने से शुरू में ज़रूरी जानकारी और बढ़ती है, जिससे गंभीर constraints पैदा हो सकते हैं
    • cost का मुद्दा वास्तव में इतना नहीं कि यह सच में लगातार सस्ता हो रहा है,
      बल्कि यह अभी कुछ हद तक छिपा हुआ है; free और low-cost promotion मॉडल ज़्यादा दिन नहीं चलेंगे।
      उदाहरण के लिए Cursor ने भी $200/month plan ला दिया है, और low-cost plans की service quality गिर रही है।
      free promotions खत्म होने पर चीज़ें अपने मूल स्तर पर लौट आएँगी

  • मैं Julia में काम करता हूँ, और लंबे समय तक चलने वाले session environment से मुझे लाभ मिलता है।
    चूँकि functions पहली बार चलने पर compile होते हैं, इसलिए मैंने MCP बनाया ताकि Claude Code एक persistent Julia kernel (Jupyter) में code भेज सके।
    test code execution बहुत तेज़ हो गया, और CC bespoke bash के बजाय codebase के मौजूदा functions का बेहतर उपयोग करने लगा।
    CCUsage के हिसाब से token usage भी लगभग 50% कम हो गया।
    ज़रूरी नहीं कि यह MCP ही होता, लेकिन मुख्य बात यह है कि codebase में 'विशिष्ट capabilities' जोड़ना, Claude के लिए हर बार custom code लिखने से आसान है

    • मैं जानना चाहता हूँ कि "Claude bespoke bash की जगह सीधे code functions चलाता है" यह सिर्फ इसलिए है क्योंकि kernel में सीधे code भेजा जा सकता है, या इसके पीछे कोई और कारण भी है