नया MCP रोडमैप
Anthropic के अपडेटेड Model Context Protocol (MCP) रोडमैप पर डेवलपर्स की मिश्रित प्रतिक्रियाएँ आ रही हैं; वे stateless, HTTP-based servers और बेहतर agent authorization की दिशा में कदमों का स्वागत करते हैं, लेकिन spec को व्यवहार में overengineered और fragmented भी मानते हैं। कई लोगों का तर्क है कि मौजूदा पैटर्न जैसे REST + OpenAPI (या direct HTTP access के साथ “code mode”) अक्सर सरल और अधिक performant होते हैं, खासकर non-interactive workloads के लिए, जबकि MCP का मूल्य मुख्यतः standardized tool discovery, fine-grained permissions, और enterprise-friendly auth flows में है। इस बात पर व्यापक सहमति है कि लंबे समय तक चलने वाले tokens और manual browser approvals autonomous agents के लिए scale नहीं करते, लेकिन इस पर कम सहमति है कि क्या MCP सही abstraction layer है या केवल AI hype cycle का पीछा करता एक और जटिल protocol।
कोड मोड बनाम MCP
- कई टिप्पणीकार MCP-आधारित सेटअप से “कोड मोड” की ओर जा रहे हैं (जैसे Cloudflare का दृष्टिकोण), और इसके लिए बेहतर रनटाइम प्रदर्शन, जटिल टूल कॉल्स की अधिक लचीली ऑर्केस्ट्रेशन, तथा कम प्रोटोकॉल समस्याओं का हवाला दे रहे हैं।
- एक व्यक्ति MCP और कोड मोड के बीच मात्रात्मक बेंचमार्क्स मांगता है; थ्रेड में कोई डेटा नहीं दिया गया है, इसलिए सापेक्ष प्रदर्शन प्रभाव अभी स्पष्ट नहीं है।
प्रमाणीकरण, पहचान, और सुरक्षा
- रोडमैप का DPoP, Workload Identity Federation, और OAuth-आधारित मानकों पर फोकस बहस छेड़ता है।
- आलोचक इसे जरूरत से ज़्यादा जटिल इंजीनियरिंग मानते हैं और तर्क देते हैं कि secret managers (जैसे 1Password) में रखे गए लंबे समय तक चलने वाले टोकन अधिक सरल हैं।
- अन्य लोग जवाब देते हैं कि लंबे समय तक चलने वाले credentials, खासकर एजेंटों के हाथों में, कई संगठनों के लिए स्वीकार्य नहीं हैं; revoke, delegation, और compliance के लिए जटिल प्रोटोकॉल आवश्यक माने जाते हैं।
- enterprise-managed, non-interactive agent auth एक प्रमुख लक्ष्य है; manual browser approvals को scaling bottleneck माना जाता है।
- “sub-entities” (विशेषीकृत agents) के लिए fine-grained, role-like permissions को आवश्यक लेकिन UX के लिहाज़ से चुनौतीपूर्ण माना जाता है।
प्रोटोकॉल डिज़ाइन, ट्रांसपोर्ट, और स्टेट
- कई लोग “MCP over HTTP” की ओर बढ़ने और MCP को किसी भी अन्य HTTP workload की तरह मानने का स्वागत करते हैं; bespoke v1 protocol को व्यापक रूप से fragmented और confusing कहा जाता है।
- stdio के भविष्य को लेकर भ्रम है; थ्रेड से सबसे अच्छा अनुमान HTTP over stdio है, लेकिन इसे अस्पष्ट बताया गया है।
- कुछ लोग HTTP को universal IPC layer के रूप में पसंद नहीं करते और transport-agnostic core protocol चाहते हैं; अन्य लोग नोट करते हैं कि gRPC विकल्प भारी लगते हैं।
- v1 के stateful design को deployment-अनुकूल नहीं और परीक्षण में कठिन कहा जाता है; statelessness की ओर बदलाव की सराहना की जाती है।
MCP बनाम REST, Skills, और OpenAPI
- कई टिप्पणीकार तर्क देते हैं कि अच्छी तरह से प्रलेखित REST API के साथ skills/markdown विवरण या OpenAPI spec पहले से ही agents के लिए अच्छी तरह काम करता है।
- MCP का मुख्य अतिरिक्त मूल्य इस प्रकार बताया गया है:
- टूल्स की केंद्रीकृत, स्वचालित discovery और updates।
- API और tool definitions के बीच कड़ा alignment।
- Fine-grained, per-tool authorization और capabilities की आसान gating।
- अन्य लोग जवाब देते हैं कि enterprises पहले से ही हज़ारों HTTP endpoints manage करते हैं और MCP बिना स्पष्ट लाभ के churn और संभावित breaking changes जोड़ता है।
जटिलता, अपनापन, और वास्तविक उपयोग
- कुछ लोग MCP को HTTP और auth का बहुत अधिक हिस्सा निगलने की कोशिश के कारण “jumping the shark” मानते हैं; वे न्यूनतम JSON-RPC-जैसे उपयोग पर टिके रहने की योजना बनाते हैं।
- प्रारंभिक MCP rollout में कई आंशिक रूप से overlapping standards, context-heavy designs, और असंगत client support शामिल होने पर निराशा है, जिससे भरोसा टूटा है।
- फिर भी कुछ लोग MCP को संकीर्ण, interactive use cases के लिए आशाजनक मानते हैं (जैसे privileged APIs को securely wrap करना, elicitation के माध्यम से privileged actions, और context bloat कम करने के लिए tool catalogs को छोटा करना)।