क्या MCP हमेशा से ही एक खराब विचार था?
Model Context Protocol (MCP) के आलोचकों का कहना है कि इसे जरूरत से ज़्यादा प्रचारित किया गया और यह अक्सर AI agents को अच्छी तरह से डिज़ाइन किए गए HTTP APIs या CLI tools इस्तेमाल करने देने की तुलना में अधिक टोकन खर्च करता है, खासकर अब जब मॉडल interfaces को समझने में बेहतर हो गए हैं। समर्थकों का जवाब है कि MCP अब भी authentication, least-privilege access, sandboxing, auditability, और standardized tool discovery से जुड़े महत्वपूर्ण समस्याएँ हल करता है—विशेषकर enterprise और multi-user environments में, जहाँ किसी agent को shell access या raw API keys सीधे नहीं दिए जा सकते। यह बहस एक व्यापक विभाजन को दिखाती है: solo या local workflows अक्सर CLIs और direct APIs को प्राथमिकता देते हैं, जबकि organizational और web-based agent use cases बढ़ती संख्या में MCP-style standards और WebMCP जैसे उभरते variants की ओर झुकते हैं।
MCP बनाम CLI / डायरेक्ट APIs
- कई लोग तर्क देते हैं कि CLIs और REST/OpenAPI पहले से ही MCP के लक्षित अधिकांश समस्याएँ हल कर देते हैं; CLIs परिचित, संयोज्य, और अक्सर टोकन में सस्ते होते हैं।
- अन्य लोग कहते हैं कि MCP प्रभावी रूप से “agents के लिए REST” है: टूल्स के लिए एक मानक, खोजने योग्य इंटरफ़ेस, जो आज agents टूल्स को जिस तरह कॉल करते हैं उसके अधिक अनुकूल है।
- कुछ लोग MCP servers को मौजूदा APIs/CLIs के ऊपर पतले wrappers (“सूअर पर लिपस्टिक”) के रूप में देखते हैं, जो नए semantics के बिना अतिरिक्त infra जोड़ते हैं।
सुरक्षा, प्रमाणीकरण, और न्यूनतम विशेषाधिकार
- auth को लेकर MCP के पक्ष में मजबूत भावना है: यह credentials को agents से छिपा सकता है, auth को केंद्रीकृत कर सकता है, और केवल संकीर्ण, सत्यापित operations expose कर सकता है।
- आलोचक जवाब देते हैं कि सही API डिज़ाइन, short-lived scoped tokens, proxies, या sandboxed CLIs वही हासिल कर सकते हैं—MCP uniquely secure नहीं है।
- चिंता यह है कि access control के लिए MCP पर निर्भर रहना सुरक्षा की झूठी भावना पैदा कर सकता है; server-side controls और auditing फिर भी आवश्यक हैं।
टोकन उपयोग, संदर्भ, और प्रदर्शन
- कई लोगों का कहना है कि MCPs direct CLI/API उपयोग की तुलना में अधिक टोकन जलाते हैं (खासकर खराब तरीके से implement किए गए); अन्य कहते हैं कि tight MCP schemas होने पर उल्टा होता है।
- पुराना MCP design जो बहुत अधिक context में लोड करता था, व्यापक रूप से आलोचना का विषय है; नए “stateless / progressive” variants को सुधार माना जाता है।
- CLIs के लिए process-startup overhead को सामान्यतः LLM या network latency की तुलना में नगण्य माना जाता है।
Enterprise, Governance, और वास्तविक उपयोग
- MCP को multi-user, enterprise settings में सबसे मूल्यवान माना जाता है: केंद्रीकृत नियंत्रण, audit logs, secrets का revocation/rotation, runtimes के बीच uniform interface।
- प्रमुख chat apps के MCP plugin stores non-technical users के बीच adoption बढ़ाते हैं; कुछ लोग इसे AI “bubble” का हिस्सा मानते हैं।
मानक, विकल्प, और WebMCP
- कई लोग तर्क देते हैं कि मौजूदा standards (REST, OpenAPI/Swagger, SOAP/WSDL, HTTP headers,
.well-knowndocs) को MCP गढ़ने के बजाय विस्तारित किया जा सकता था। - WebMCP को web apps के लिए एक सरल, अधिक अनुकूल दृष्टिकोण के रूप में सराहा जाता है, जो वहाँ “classic” MCP को संभावित रूप से पीछे छोड़ सकता है।
- उल्लिखित विकल्पों में शामिल हैं: CLI-केंद्रित harnesses, custom sandboxes/VMs, AXI, और अच्छे specs वाले generic “make HTTP request” tools।
समग्र भावना
- सहमति: MCP सार्वभौमिक रूप से बुरा नहीं है, लेकिन इसे जरूरत से ज़्यादा प्रचारित और गलत तरीके से इस्तेमाल किया गया है।
- थ्रेड से एक मोटा नियम: solo/local dev के लिए, CLIs+APIs आम तौर पर पर्याप्त हैं; जब आपको cross-tool standardization, remote access, और centralized governance की आवश्यकता होती है, तब MCP आकर्षक बनता है।