HeadlinesBriefing favicon HeadlinesBriefing.com

MCP हमेशा एक बुरा विचार क्यों था

Hacker News •
×

MCP हमेशा एक बुरा विचार क्यों था

हाल ही में मैं MCP की दुनिया में नवीनतम और महानतम पर केंद्रित एक पूरे दिन के कार्यक्रम में गया। जबकि सभी प्रस्तुतकर्ता अद्भुत थे और अपने काम के प्रति जुनूनी लग रहे थे, मैं ईमानदारी से MCP से थक गया हूँ। यह एक भयानक प्रोटोकॉल है जिसे उस समय के लिए बनाया गया था जब LLMs इतने स्मार्ट नहीं थे, और हम इससे आगे निकल चुके हैं।

संक्षिप्त इतिहास

MCP को नवंबर 2024 में Anthropic टीम द्वारा एक प्रोटोकॉल के रूप में जारी किया गया था जिसे एजेंटों को बाहरी सेवाओं और डेटा स्रोतों से जोड़ने में मदद करने के लिए डिज़ाइन किया गया था। उस समय के मॉडल अभी भी अपेक्षाकृत आदिम थे, कम से कम अभी हमारे पास जो है उसकी तुलना में। हमारे पास तब Claude Code भी नहीं था, और सामान्य-उद्देश्य वाले एजेंटिक वर्कफ़्लो बहुत कम विश्वसनीय थे। उपयोगकर्ताओं ने अपने AI मॉडलों को बाहरी सेवाओं तक पहुँच देने की उपयोगिता देखना शुरू कर दिया। इसने उत्पादकता के एक स्तर को सक्षम किया जिसे हमने पहले कभी नहीं देखा था। हमने MCP अपनाने में विस्फोट देखा, जो अर्थव्यवस्था भर में LLM अपनाने में इसी तरह के, यदि अधिक विस्फोटक नहीं, वृद्धि के साथ मेल खाता था। समय के साथ, MCP Anthropic के प्रबंधन में विकसित होता रहा, इससे पहले कि इसे अंततः 2025 में Linux Foundation के तहत Agentic AI Foundation को दान कर दिया गया।

MCP औद्योगिक परिसर

अपनाने में भारी वृद्धि के साथ, उपयोगकर्ताओं ने अपने सेटअप में कई MCP सर्वर जोड़ना शुरू कर दिया, और वे संदर्भ ब्लोट मुद्दे में चलने लगे। प्रत्येक सर्वर कई टूल के साथ आएगा, प्रत्येक का अपना स्कीमा होगा, जिसने इन सभी मॉडलों के संदर्भ को अधिभारित करना शुरू कर दिया। Harness डेवलपर्स ने इसके आसपास कई तरकीबें खोजीं, जिसमें Composio, Mint MCP, और Pipedream जैसे प्लेटफॉर्म द्वारा अब पेश किए गए सामान्य खोज/निष्पादन पैटर्न शामिल हैं। वे सभी विभिन्न बाहरी सेवाओं के लिए आपके क्रेडेंशियल्स को रखने के लिए एक जगह रखने की समस्या को प्रभावी ढंग से हल करते हैं और अपने एजेंट को टूल का एक न्यूनतम सेट (संदर्भ ब्लोट को कम करने के लिए) देते हैं जिसका उपयोग वह उन तक पहुँचने के लिए कर सकता है। मैं स्पष्ट करना चाहता हूँ कि अल्पावधि के लिए यह एक अच्छी बात है।

MCP के आसपास हमारे द्वारा बनाई गई सभी चीज़ों के साथ, हमने ध्यान में नहीं लिया, या शायद नज़रअंदाज़ कर दिया, कि मॉडल बेहतर हो रहे हैं। अब हमारे पास MCP सर्वरों की निगरानी के लिए समर्पित संपूर्ण सिस्टम हैं, यह सुनिश्चित करने के लिए कि प्रतिक्रियाएँ अच्छी हैं, यह सुनिश्चित करने के लिए कि एजेंट टूल तक आसानी से पहुँच सकते हैं, स्कीमा का पता लगाने के लिए, और यह निर्धारित करने के लिए कि हमें एजेंटों को क्या देना है ताकि वे सही समय पर सही कॉल कर सकें।

आश्चर्य, आश्चर्य, बड़े लैब सही थे

मॉडल बेहतर हो गए। वे अब कंप्यूटर पर कोड निष्पादित करने, बड़े कोडबेस के बारे में तर्क करने, और आम तौर पर पहले से कहीं अधिक स्वायत्त रूप से कार्य करने में सक्षम हैं। उस काम का एक बड़ा हिस्सा कोडिंग उद्देश्यों के लिए स्क्रिप्ट लिखना/चलाना था। एक साइड इफेक्ट (हालांकि क्या यह है?) यह है कि अब वे सीधे API कॉल करने में अच्छे हैं। वे स्क्रिप्ट लिख सकते हैं, कई अलग-अलग सेवाओं को कंपोज़ कर सकते हैं, और उन API को कॉल कर सकते हैं जिन्हें उन्होंने पहले कभी नहीं देखा है, सभी उपयोगी वर्कफ़्लो में उपयोगकर्ता की ओर से न्यूनतम हस्तक्षेप के साथ।

LLM इसमें इतने अच्छे हो गए हैं कि Cloudflare ने Code Mode भी लॉन्च कर दिया, जो MCP का उपयोग करने का एक बेहतर तरीका है, जिसमें LLMs विभिन्न कॉल्स को स्क्रिप्ट में कंपोज़ करते हैं जिन्हें सैंडबॉक्स में निष्पादित किया जा सकता है। लेकिन इससे भी बेहतर, LLMs ने --help कमांड का उपयोग करके CLIs की खोज करना सीख लिया है, इसलिए उन्हें अब कई सेवाओं तक पहुँचने के लिए MCP सर्वरों की आवश्यकता नहीं है जो डॉक्यूमेंटेड API या CLIs के माध्यम से उपलब्ध हैं। अधिकांश रिमोट-सर्विस MCP सर्वर अंततः उन API को लपेटते हैं जो पहले से मौजूद हैं।

अब क्या?

हम अपने अधिकांश MCP सर्वरों को हटा देते हैं। बस इतना ही। टर्मिनल एक्सेस वाले एजेंट अधिकांश MCP सर्वरों को बदल सकते हैं और अक्सर अधिक सक्षम होते हैं।

अभी भी कुछ मुद्दे हैं, जैसे CLIs मशीन-पठनीय प्रतिक्रियाएँ (JSON/XML, आदि) लौटाते हैं, जो बहुत वर्बोज़ होते हैं और टोकन उपयोग पर भारी होते हैं, लेकिन हमारे पास इसे ठीक करने के तरीके हैं। विकल्प का अधिकांश हिस्सा पहले से मौजूद है: डॉक्यूमेंटेड HTTP API, मानक कंटेंट नेगोशिएशन, और परिपक्व प्रमाणीकरण तंत्र। हमें इस बात को मानकीकृत करना शुरू करना चाहिए कि एजेंट HTTP API का सीधे उपयोग कैसे करते हैं। उदाहरण के लिए, एजेंट क्लाइंट खुद को एजेंट के रूप में पहचानने के लिए हेडर संलग्न कर सकते हैं, और सर्वर स्वचालित रूप से उन्हें HTML या ... के बजाय मार्कडाउन या टेक्स्ट के रूप में प्रतिक्रिया डेटा भेज सकते हैं।