आपने MCP नहीं कहा

MCP क्या है और यह विवादास्पद क्यों है

• MCP (Model Context Protocol) को एजेंटों/LLMs के लिए टूल्स/APIs को खोजने और कॉल करने का एक मानकीकृत तरीका बताया गया है, जिसमें auth, docs, और structured tool metadata शामिल हैं।
• समर्थक इसे “API + docs” या “self‑documenting RPC” के रूप में देखते हैं, जो टूल्स को खोजने योग्य बनाता है और औसत उपयोगकर्ताओं तथा “consumer AI” UIs (ChatGPT, Claude, आदि) के लिए आसान बनाता है।
• आलोचकों का तर्क है कि इसका बहुत सा हिस्सा OpenAPI या मौजूदा IDLs का विस्तार करके किया जा सकता था; कुछ लोग इसे NIH और “CLI + skills” या REST के साथ अनावश्यक रूप से दोहरावदार मानते हैं।

Pi की दार्शनिक दिशा में बदलाव: “No MCP” से बिल्ट‑इन MCP तक

• Pi को मूल रूप से एक न्यूनतम, अत्यधिक अनुकूलन योग्य, yolo‑style coding harness के रूप में सराहा जाता था: कोई permissions model नहीं, कोई MCP नहीं, एकदम सादा core, और हर चीज़ के लिए extensions।
• कुछ उपयोगकर्ता core में MCP का स्वागत करते हैं क्योंकि MCP enterprises और अन्य harnesses में आम हो गया है; इतनी केंद्रीय क्षमता के लिए extensions का उपयोग करना अजीब लगता था।
• अन्य लोग चिंता करते हैं कि यह feature bloat की शुरुआत है और “यह harness आपका है” से हटकर “opinionated coding product” की ओर झुकाव है, खासकर इसके आसपास मौजूद अन्य commercial offerings के साथ।
• Maintainers जोर देते हैं कि डिफ़ॉल्ट रूप से कुछ भी नया सक्षम नहीं किया गया है; फीचर्स को बंद किया जा सकता है या extensions/forks के रूप में रखा जा सकता है।

Codemode: बस Bash क्यों नहीं?

• Codemode एक sandboxed scripting environment है (अक्सर JS/TS) जो harness स्तर पर tool और MCP कॉल्स को orchestrate करने के लिए उपयोग होता है।
• समर्थक:
  • मॉडल तक कम round trips, कम tokens, बेहतर parallelization।
  • ऐसे environments में काम करता है जहाँ shell access नहीं होता और OS accounts से अलग permission models सक्षम करता है।
  • MCP tools को एक sandbox के अंदर compose करने देता है, बजाय इसके कि हर MCP server का अपना sandbox हो।
• संशयवादी:
  • मॉडल पहले से ही bash/Python को बहुत अच्छी तरह chain कर लेते हैं; codemode जोड़ना पुनराविष्कार और जटिलता जैसा लगता है।
  • स्थानीय coding agents के लिए, sandbox VM/container में एक restricted shell अधिक सरल और पारदर्शी हो सकता है।
  • Codemode मुख्यतः MCP/harness design से पैदा हुई समस्याएँ हल करता है, न कि अंतर्निहित सीमाएँ।

MCP बनाम CLI/Skills/OpenAPI और Enterprise बनाम Local

• “Team/enterprise” पक्ष:
  • HTTP पर MCP केंद्रीकृत auth, OAuth flows, telemetry, revocable skills/prompts, और कई उपयोगकर्ताओं में टूल्स के आसान distribution/versioning देता है।
  • कुछ लोग MCP prompts/resources का उपयोग करके /‑style commands और छोटे साझा state को centrally manage करते हैं।
• “Local/power‑user” पक्ष:
  • CLI + skills debug करने में आसान हैं, bash के माध्यम से composable हैं, और shell tools समर्थित किसी भी harness के साथ काम करते हैं।
  • MCP context को भारी कर सकता है, clients के बीच असंगत रूप से implement होता है, और file upload जैसे बुनियादी मामलों में पीछे है।
• इस पर सहमति है कि MCP बेहतर हो रहा है (stateless HTTP, बेहतर tooling), लेकिन इस पर असहमति है कि क्या यह मूल रूप से आवश्यक है या बस एक और API style।

Sub‑Agents, Context, और Composability

• कुछ लोग context और cost को प्रबंधित करने के लिए sub‑agents और अलग sessions पर बहुत निर्भर रहते हैं; अन्य sub‑agents को opaque, cache‑unfriendly मानते हैं, और लंबे single sessions के साथ custom compaction को प्राथमिकता देते हैं।
• “MCP doesn’t compose” पर बहस होती है:
  • एक दृष्टिकोण: codemode और harness‑level sandboxes कई MCPs की composition की समस्या को काफी हद तक ठीक कर देते हैं।
  • दूसरा: उचित tool design और REST/HATEOAS वर्तमान MCP patterns से बेहतर incremental discovery और composition दे सकते हैं।

मेटा: Hype Cycles और Influencers

• कई टिप्पणियाँ पहले की “MCP is dead, CLI won” लहर की आलोचना करती हैं, जिसे influencer‑driven hype माना गया था, और अब MCP adoption बढ़ने के साथ वह रुख उलट गया है।
• कुछ लोग MCP बनाम CLI को आंशिक रूप से सांस्कृतिक मानते हैं: local‑UNIX‑oriented devs बनाम enterprise और non‑terminal users।
• समग्र भावना: MCP न तो जादुई है न बेकार; यह एक trade‑off है जो कुछ stacks (खासकर enterprise/GUI) के लिए दूसरों (shell के साथ local dev) की तुलना में बेहतर फिट बैठता है।