MCP: कमज़ोरियाँ और संभावनाएँ

मशीन कम्युनिकेशन प्रोटोकॉल (MCP) एक ऐसी अवधारणा है जिसने तकनीकी जगत में, विशेष रूप से लार्ज लैंग्वेज मॉडल्स (LLMs) के क्षेत्र में काफी ध्यान आकर्षित किया है। जबकि यह LLMs और बाहरी संसाधनों के बीच बातचीत को सुव्यवस्थित करने का वादा करता है, एक नज़दीकी नज़र कई अंतर्निहित मुद्दों और सीमाओं को प्रकट करती है जिन पर सावधानीपूर्वक विचार करने की आवश्यकता है। यह विश्लेषण MCP के आसपास की आलोचनाओं पर प्रकाश डालता है, इसकी कमजोरियों, स्केलेबिलिटी चुनौतियों और AI एजेंट विकास के लिए व्यापक निहितार्थों की खोज करता है।

MCP की जिम्मेदारियों को ओवरलोड करना

एक आम आलोचना यह है कि MCP को बहुत अधिक जिम्मेदारी सौंपी जा रही है। लेखक का तर्क है कि MCP को मुख्य रूप से LLMs के लिए बाहरी संसाधनों तक पहुंचने और उनसे बातचीत करने के लिए एक प्रवेश द्वार के रूप में काम करना चाहिए। इसे केवल एक ‘दरवाजे’ या ‘पुल’ के रूप में देखने से इसके उद्देश्य और सीमाओं को स्पष्ट करने में मदद मिलती है।

दुर्घटनाग्रस्त डेटा एक्सपोजर, प्रॉम्प्ट इंजेक्शन कमजोरियों और लागत नियंत्रण कमियों जैसेमुद्दों को सीधे MCP को जिम्मेदार ठहराना दोष का गलत स्थान है। ये ऐसी समस्याएं हैं जिन्हें डेवलपर्स को उन सीमाओं के भीतर संबोधित करना चाहिए जिन्हें वे नियंत्रित करते हैं। डेवलपर्स को दर सीमाओं को लागू करने और उपयोग की निगरानी करने की आवश्यकता है, भले ही उपयोग किए गए प्रोटोकॉल की परवाह किए बिना। इसकी तुलना गति के लिए सड़क को दोष देने से करना उपयुक्त है - बुनियादी ढांचा व्यक्तिगत व्यवहार के लिए जिम्मेदार नहीं है।

अंततः, उठाई गई कई चिंताएँ AI एजेंटों को कार्य सौंपने से संबंधित व्यापक मुद्दे हैं। डेवलपर्स को इन चुनौतियों को अपने विशिष्ट अनुप्रयोगों के भीतर प्रबंधित करने की जिम्मेदारी लेनी चाहिए, बजाय इसके कि API स्वयं सब कुछ संभालने की उम्मीद करें।

LLMs और प्रॉम्प्ट इंजेक्शन की दोधारी तलवार

MCP के आसपास की हालिया चर्चाएं अक्सर तेज चाकू के अंतर्निहित खतरों के बारे में चेतावनियों के समान होती हैं - अगर उन्हें गलत तरीके से संभाला जाए तो वे काट सकते हैं। प्रॉम्प्ट इंजेक्शन, एक महत्वपूर्ण चिंता, LLMs की प्रकृति का परिणाम है। प्रॉम्प्ट इंजेक्शन को खत्म करने के प्रयास उन क्षमताओं को ख़राब करने का जोखिम उठाते हैं जो LLMs को मूल्यवान बनाती हैं।

‘नियंत्रण बनाम डेटा’ पृथक्करण की धारणा, जो पारंपरिक प्रणालियों में आम है, स्वाभाविक रूप से LLMs में मौजूद नहीं है। LLMs अपनी शक्ति और सामान्यता ठीक उसी तरह प्राप्त करते हैं क्योंकि उनमें इस कठोर पृथक्करण का अभाव होता है। यह अंतर्निहित विशेषता उन्हें प्रॉम्प्ट इंजेक्शन हमलों के लिए कमजोर बनाती है।

जबकि रिमोट MCPs एक सेवा के रूप में जोखिम पेश कर सकते हैं, दोष प्रोटोकॉल के साथ नहीं है, बल्कि अविश्वसनीय तीसरे पक्षों को संवेदनशील कार्यों को सौंपने के साथ है। यह सादृश्य एक सनकी रूमबा में चाकू को डक्ट-टेपिंग करने के विचार तक फैला हुआ है - समस्या चाकू स्वयं नहीं है, बल्कि इसे अप्रत्याशित डिवाइस से जोड़ने का निर्णय है।

‘सावधान रहने’ या सुरक्षात्मक गियर के सुझाव, तकनीकी रूप से सटीक होने के बावजूद, मूल मुद्दे को याद करते हैं: एक तेज उपकरण को अनियंत्रित प्रणाली के साथ मिलाने का बुरा निर्णय।

स्केलेबिलिटी चुनौतियाँ

सुरक्षा चिंताओं से परे, MCP को मौलिक स्केलेबिलिटी सीमाओं का सामना करना पड़ता है। लेखक LLM विश्वसनीयता और प्रदान की गई निर्देशात्मक संदर्भ की मात्रा के बीच नकारात्मक संबंध पर प्रकाश डालता है। यह इस आम धारणा को चुनौती देता है कि अधिक डेटा और एकीकरण जोड़ने से स्वचालित रूप से समस्याएं हल हो जाएंगी। जैसे-जैसे उपकरणों और एकीकरणों की संख्या बढ़ती है, एक एजेंट का प्रदर्शन एक साथ प्रत्येक अनुरोध की लागत में वृद्धि करते हुए ख़राब हो सकता है।

लेखक इस बात पर जोर देते हैं कि MCP एक निश्चित सीमा से आगे नहीं बढ़ता है। एक एजेंट के संदर्भ में असीमित संख्या में टूल जोड़ने का प्रयास अनिवार्य रूप से उसकी क्षमताओं पर नकारात्मक प्रभाव डालेगा। यह सीमा MCP की अवधारणा में अंतर्निहित है और इस पर प्रमाणीकरण मुद्दों की तुलना में अधिक ध्यान देने की आवश्यकता है।

उपयोगकर्ता अंततः प्रदर्शन में गिरावट का अनुभव कर सकते हैं क्योंकि वे अधिक MCP सर्वर सक्षम करते हैं, जिससे उनके बीच हस्तक्षेप होता है। यह विशिष्ट पैकेज प्रबंधन प्रणालियों के विपरीत है, जहां गैर-हस्तक्षेप एक मौलिक संपत्ति है।

MCP के साथ मुख्य समस्या यह है कि इसका वास्तविक व्यवहार उपयोगकर्ता की अपेक्षाओं से विचलित होता है। यह पहचानना महत्वपूर्ण है कि MCP एक प्लग-एंड-प्ले समाधान नहीं है जो बिना किसी परिणाम के असीमित संख्या में टूल को मूल रूप से एकीकृत करता है।

UI और टूल प्रबंधन के साथ सीमाओं को संबोधित करना

MCP की सीमाओं के लिए प्रस्तावित समाधानों में से एक यूजर इंटरफेस में सुधार करना है। यदि कोई उपकरण अनजाने में निष्पादित होता है, तो UI को इसे अक्षम करने या इसके इच्छित उपयोग को स्पष्ट करने के लिए इसके विवरण को संशोधित करने का एक आसान तरीका प्रदान करना चाहिए।

लेखक यह भी नोट करते हैं कि संदर्भ वृद्धि अक्सर बेहतर प्रदर्शन और वास्तविक दुनिया के उपयोग क्षमताओं की ओर ले जाती है, जो सख्ती से नकारात्मक संबंध की धारणा का खंडन करती है। हालांकि, वे स्वीकार करते हैं कि कुछ उपयोग मामलों में या खराब डिज़ाइन किए गए संदर्भों के साथ, प्रदर्शन में गिरावट हो सकती है।

उपकरणों के भारी विकल्प को संबोधित करने के लिए, एक ‘विभाजित और जीत’ दृष्टिकोण का सुझाव दिया गया है। इसमें विशेष रूप से किसी दिए गए कार्य के लिए सबसे प्रासंगिक उपकरणों का चयन करने के लिए डिज़ाइन किया गया एक उपकरण जोड़ना शामिल है। यह ‘उपकरण-चयन उपकरण’ एक और LLM कॉल हो सकता है, जिसे ‘पैरेंट’ एजेंट को उपलब्ध उपकरणों का एक सबसेट वापस करने का काम सौंपा गया है। यह स्तरित दृष्टिकोण जटिलता को प्रबंधित करने के लिए अप्रत्यक्षता के अतिरिक्त स्तर जोड़ता है।

हालांकि, संदर्भ में केवल उपकरण होने से मॉडल के आउटपुट को काफी हद तक बदला जा सकता है। जबकि प्रासंगिक रूप से प्रासंगिक उपकरण (पुनर्प्राप्ति-संवर्धित पीढ़ी या RAG जैसी तकनीकों के माध्यम से प्राप्त) फायदेमंद हैं, ‘get_tools’ अनुरोध के पीछे सभी उपकरणों को छिपाना हानिकारक हो सकता है।

MCP एक परिवहन और प्राधिकरण परत के रूप में

MCP मुख्य रूप से टूल-स्तरीय प्राधिकरण पर ध्यान केंद्रित करते हुए एक अनुरोध/प्रतिक्रिया जीवनचक्र के साथ एक परिवहन और वायर प्रारूप के रूप में कार्य करता है। निबंध का तर्क है कि MCP के साथ सबसे बड़ी समस्या AI एजेंटों को कार्यात्मक रूप से टूल लिखने में सक्षम बनाने में इसकी विफलता है।

लेखक का मानना ​​है कि MCP पहली जगह में अनावश्यक हो सकता है, क्योंकि LLMs में पहले से ही OpenAPI विनिर्देशों का उपयोग करके प्रलेखित APIs के साथ बातचीत करने की क्षमता है। गायब तत्व प्राधिकरण है - यह नियंत्रित करने की क्षमता कि कौन से APIs तक AI पहुंच सकता है। MCP के बजाय, लेखक सुझाव देते हैं कि AIs को विशिष्ट समापन बिंदुओं पर प्राधिकरण लागू करते समय HTTP अनुरोध करने की अनुमति दी जाए। यह दृष्टिकोण मौजूदा APIs को पतले MCP टूल से लपेटने की वर्तमान प्रवृत्ति के साथ संरेखित होता है।

MCP का एक विशेष रूप से कष्टप्रद पहलू स्ट्रीमिंग टूल कॉल परिणामों के लिए इसका समर्थन नहीं है। एकल अनुरोध/प्रतिक्रिया जोड़ी ग्राहकों को पृष्ठ संख्या के लिए बार-बार टूल कॉल करने के लिए मजबूर करती है, जिससे लंबी चलने वाली प्रक्रियाएं बाधित होती हैं। स्ट्रीमिंग क्षमता को लागू करना, शायद gRPC का उपयोग करके, MCP की दक्षता में काफी सुधार कर सकता है।

संवेदनशील डेटा को उजागर करने में आसानी

MCP के साथ एक महत्वपूर्ण चिंता संवेदनशील डेटा के आसान एक्सपोजर की संभावना है। इसके अलावा, MCP स्वाभाविक रूप से AI एजेंटों को अधिक विश्वसनीय नहीं बनाता है; यह बस उन्हें अधिक उपकरणों तक पहुंच प्रदान करता है, जो कुछ स्थितियों में विरोधाभासी रूप से विश्वसनीयता को कम कर सकता है।

लेखक स्वीकार करता है कि उन्हें उम्मीद नहीं है कि MCP इन सभी मुद्दों को हल करेगा या इनके लिए जिम्मेदार होगा। बल्कि, MCP इन समस्याओं के लिए एक बड़ा सतह क्षेत्र बनाता है, जिसके लिए ऐप डेवलपर्स और उपयोगकर्ताओं को सतर्क रहने की आवश्यकता होती है।

सादृश्य और शहरी नियोजन

लेखक इस मुद्दे को स्पष्ट करने के लिए शहरी नियोजन के सादृश्य का उपयोग करता है। MCP की तुलना 25mph की गति सीमा वाली छह लेन वाली शहर की सड़क से करना डिज़ाइन और इच्छित उपयोग के बीच विसंगति को उजागर करता है। केवल जुर्माना लगाने या सतही ‘फिक्स’ जोड़ने से खराब डिजाइन की अंतर्निहित समस्या का समाधान नहीं होता है।

प्रभावी शहरी नियोजन में ऐसी सड़कों को डिजाइन करना शामिल है जो स्वाभाविक रूप से गति सीमा के पालन को प्रोत्साहित करें। इसी तरह, MCP को संभावित जोखिमों को स्वाभाविक रूप से कम करने के लिए डिज़ाइन किया जाना चाहिए, न कि केवल बाहरी नियंत्रणों पर निर्भर रहना चाहिए।

LLMs अवांछित कार्रवाई कर रहे हैं

लेख लेख LLMs को सेवाओं पर कार्रवाई करने की अनुमति देने वाले प्रोटोकॉल की व्यापक आलोचना में बदल जाता है। लेखक एक मुख्य समस्या की पहचान करता है: LLMs ऐसी कार्रवाई कर सकते हैं जो उपयोगकर्ता उनसे लेने का इरादा नहीं रखते हैं। वे उन कार्यों के बीच अंतर करते हैं जो LLMs स्वतंत्र रूप से ले सकते हैं और जिनके लिए उपयोगकर्ता संकेत की आवश्यकता होती है।

जबकि अंतिम लक्ष्य LLMs द्वारा पूरे व्यवसायों का प्रबंधन करना हो सकता है, प्रौद्योगिकी अभी तक ऐसी स्वायत्तता के लिए तैयार नहीं है। वर्तमान में, उपयोगकर्ता पहले समीक्षा किए बिना AIs को ईमेल भेजने के लिए भी नहीं चाह सकते हैं।

लेखक उपयोगकर्ता से पुष्टि के लिए संकेत देने के समाधान को अस्वीकार करता है, यह हवाला देते हुए कि उपयोगकर्ता स्वचालित पुष्टि (‘YOLO-मोड’) के पैटर्न में गिरने का जोखिम उठाते हैं जब अधिकांश उपकरण हानिरहित दिखाई देते हैं। यह कार्ड से नकद की तुलना में अधिक खर्च करने वाले लोगों की मनोवैज्ञानिक घटना के समान है - एक समस्या जो मानव व्यवहार में निहित है, न कि प्रौद्योगिकी में।

मौलिक प्रश्न: APIs का उपयोग क्यों नहीं करते?

MCP के बारे में चर्चाओं में एक आवर्ती प्रश्न यह है कि सीधे APIs का उपयोग क्यों नहीं करते।

MCP LLM क्लाइंट को अनुमति देता है जिन्हें उपयोगकर्ता सीधे नियंत्रित नहीं करते हैं (उदाहरण के लिए, क्लाउड, चैटजीपीटी, कर्सर, वीएसकोड) APIs के साथ बातचीत करने के लिए। MCP के बिना, डेवलपर्स को LLM APIs का उपयोग करके कस्टम क्लाइंट बनाने की आवश्यकता होगी, जो मौजूदा क्लाइंट को सदस्यता के साथ उपयोग करने और उन्हें विशिष्ट उपकरणों का उपयोग करने का तरीका सिखाने की तुलना में बहुत अधिक महंगा कार्य है।

एक डेवलपर USB के माध्यम से अपने FM हार्डवेयर सिंथेसाइज़र से कनेक्ट करने के लिए एक MCP सर्वर बनाने के अपने अनुभव को साझा करता है, जिससे AI-संचालित ध्वनि डिजाइन सक्षम होता है।

LLM क्लाइंट एकीकरण और मानकीकरण

मुख्य मुद्दा यह है कि सभी LLM क्लाइंट मूल रूप से सीधे API इंटरैक्शन का समर्थन नहीं करते हैं, जिसमें चैटजीपीटी कस्टम GPT कार्रवाई एक उल्लेखनीय अपवाद है। Anthropic, Google और OpenAI क्लाउड, चैटजीपीटी और कर्सर जैसे LLM-संचालित क्लाइंट के लिए प्रक्रिया को सुव्यवस्थित करने के लिए एक साझा प्रोटोकॉल के रूप में MCP को अपनाने के लिए सहमत हो गए हैं।

MCP LLM क्लाइंट बनाने वालों के लिए प्रक्रिया को सरल बनाता है। यदि आप एक LLM को एक API के साथ इंटरैक्ट करना चाहते हैं, तो आप बस एक API कुंजी प्रदान नहीं कर सकते हैं और इसके काम करने की उम्मीद नहीं कर सकते हैं - आपको एक एजेंट बनाने की आवश्यकता है।

MCP को APIs को दस्तावेज़ करने और उन्हें कॉल करने के तरीके का वर्णन करने के तरीके के रूप में देखा जा सकता है, साथ ही उस दस्तावेज़ को उजागर करने और कॉल को सुविधाजनक बनाने के लिए मानकीकृत टूलिंग भी। यह अनावश्यक जटिलता के बिना APIs को लपेटने के लिए पर्याप्त अमूर्तता प्रदान करता है, लेकिन यह सरलता उपयोगकर्ताओं को ‘अपने पैर में गोली मारने’ की ओर भी ले जा सकती है।

MCP की दक्षता और पुन: प्रयोज्यता

MCP के बिना, डेवलपर्स को हर बार टूल को लागू करने पर LLM को टूल का उपयोग करने का तरीका बार-बार बताना होगा। LLM द्वारा जानकारी भूल जाने या गैर-मानक API व्यवहार के कारण टूल का सही ढंग से उपयोग करने में विफल रहने का जोखिम होता है।

यह लगातार समझाना और दोहराना संदर्भ में टोकन बर्बाद करता है, जिससे लागत और समय बढ़ जाता है। MCP इस प्रक्रिया को आवश्यक सभी जानकारी बंडल करके, टूल उपयोग को अधिक कुशल बनाकर और टूल साझा करने की सुविधा प्रदान करके सुव्यवस्थित करता है।

LLM प्रदाता को ‘यहां एक टूल है जिसका आप उपयोग कर सकते हैं’ और API दस्तावेज़ों के साथ बताकर, उपयोगकर्ता बिना बार-बार रिमाइंडर के कई चैट में उस टूल का पुन: उपयोग कर सकते हैं। यह डेस्कटॉप LLM क्लाइंट को स्थानीय रूप से चल रहे प्रोग्राम से कनेक्ट करने में भी सक्षम बनाता है, OS-विशिष्ट निष्पादन प्रक्रियाओं की समस्या का समाधान करता है।

MCP और स्थानीय संसाधन एक्सेस

MCP LLMs के लिए फ़ाइलों, पर्यावरण चर और नेटवर्क एक्सेस जैसे स्थानीय संसाधनों तक पहुंच की सुविधा प्रदान करता है। इसे स्थानीय रूप से चलाने के लिए डिज़ाइन किया गया है, जो LLM को इन संसाधनों तक नियंत्रित पहुंच प्रदान करता है।

मानक LLM टूल कॉल ‘आकार’ MCP टूल कॉल ‘आकार’ को बारीकी से दर्शाता है, जिससे यह टूल को एजेंटों से कनेक्ट करने के लिए एक सीधा मानक बन जाता है।

MCP AI मॉडल को उजागर किए गए फ़ंक्शन कॉलिंग स्कीमा और अंतर्निहित APIs के बीच एक पुल के रूप में कार्य करता है। यह फ़ंक्शन कॉल को टूल में अनुवाद करता है, जिससे निर्बाध संचार सक्षम होता है।

यदि आप एक टूल प्रदाता हैं, तो MCP AI एजेंट फ्रंटएंड को आपके टूल से कनेक्ट करने के लिए एक मानकीकृत प्रोटोकॉल प्रदान करता है। यह इस प्रश्न का उत्तर देता है कि मानक प्रोटोकॉल केवल HTTP और OpenAPI क्यों नहीं हो सकता है।

MCP एक मेटा-API है जो समापन बिंदुओं और उनके परिचालन विवरणों को विनिर्देश में शामिल करता है, जिससे LLMs को उनके साथ अधिक प्रभावी ढंग से बातचीत करने में सक्षम बनाया जाता है।

विशिष्ट परिदृश्यों में MCP

MCP तब समस्याओं का समाधान कर सकता है जब उपयोगकर्ता प्रश्न पूछते हैं या यह सुनिश्चित नहीं होता है कि कौन से APIs का उपयोग करना है। यह पिछले संदेशों के आधार पर अनुरोधों को भी संसाधित कर सकता है।

एक उपयोगकर्ता ‘X’ प्राप्त करने और उसे एक समापन बिंदु पर भेजने की अपनी इच्छा का अनुभव साझा करता है। उन्होंने पाया कि MCP इस तरह के एक सरल कार्य के लिए अत्यधिक है, यह दर्शाता है कि यह बुनियादी API इंटरैक्शन के लिए हमेशा आवश्यक नहीं है।

MCP की तुलना एजेंटिक अनुभवों के लिए विशेष रूप से डिज़ाइन किए गए नेटवर्क पर संवाद करने वाले सॉफ़्टवेयर बनाने के लिए FastAPI वेब ऐप फ्रेमवर्क से की जाती है। इसे ‘Rails-for-Skynet’ के रूप में देखा जा सकता है, जो AI एजेंट विकास के लिए एक मानकीकृत ढांचा प्रदान करता है।

प्रदाता नियंत्रण के बारे में चिंताएँ

ऐसी चिंताएँ हैं कि MCP को सिस्टम पर प्रदाता-साइड नियंत्रण बढ़ाने के लिए धकेला जा रहा है। LLM प्रदाता अंततः API एक्सेस को प्रतिबंधित कर सकते हैं, जैसे Google ने Gmail के साथ IMAP/SMTP का उपयोग करना मुश्किल बना दिया।

OpenAPI एजेंटों को /openapi.json से API विनिर्देशों को पुनर्प्राप्त करने की अनुमति देता है।

MCP त्वरित इंटरैक्शन को सक्षम करता है, जिससे उपयोगकर्ता इनपुट डेटा तैयार करने, इसे API को भेजने, आउटपुट को पार्स करने और प्रत्येक संदेश के लिए प्रक्रिया को दोहराने में समय बिताने के बजाय सेकंड में कार्य पूरा कर सकते हैं।

सैंडबॉक्सिंग और सुरक्षा जोखिम

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

इसकी तुलना SQL इंजेक्शन से की जाती है - एक साथ मिलकर बनाया गया एक सिस्टम जहां कम से कम देखने योग्य के साथ किसी भी बिंदु पर कमजोरियों का फायदा उठाया जा सकता है।

प्रॉम्प्ट इंटरफ़ेस SQL इंजेक्शन के एक रूप के लिए भी अतिसंवेदनशील है, क्योंकि मॉडल उपयोगकर्ता-दूषित इनपुट से प्रॉम्प्ट के विश्वसनीय भागों को अलग नहीं कर सकता है। इसे हल करने के लिए एन्कोडिंग, डिकोडिंग और मॉडल प्रशिक्षण में मौलिक बदलाव की आवश्यकता है।

यह प्रॉम्प्ट इंजेक्शन और टूल इंजेक्शन दोनों की अनुमति देता है, जिससे संभावित रूप से अविश्वसनीय कोड का निष्पादन हो सकता है।

कंटेनरीकरण और नियंत्रित पहुंच

एक डेवलपर ने एक MCP सर्वर बनाया जो माउंटेड प्रोजेक्ट कोड के साथ एक डॉकर कंटेनर शुरू करता है। यह दृष्टिकोण LLM को सैंडबॉक्स्ड वातावरण के भीतर पूरे यूनिक्स टूलसेट और प्रोजेक्ट-विशिष्ट टूलिंग तक पहुंचने की अनुमति देता है।

चैट-आधारित इंटरफ़ेस के माध्यम से संचालित यह एजेंटिक वर्कफ़्लो पारंपरिक तरीकों की तुलना में अधिक प्रभावी साबित हुआ है।

कुंजी MCP एजेंटों को वही एक्सेस देना है जो उन्हें चाहिए, और कुछ नहीं। सुरक्षा जोखिमों को कम करने के लिए कंटेनरीकरण और पारदर्शी टूल UX महत्वपूर्ण हैं।

वर्चुअल मशीन और इंटरनेट एक्सेस

एजेंटों को एक न्यूनतम लिनक्स इंस्टॉलेशन वाला कंप्यूटर (VM या कंटेनर के रूप में) देने से बेहतर परिणाम मिल सकते हैं, जिससे वे इंटरनेट से जानकारी प्राप्त कर सकते हैं। हालांकि, यह दुर्भावनापूर्ण निर्देशों और डेटा एक्सफिल्ट्रेशन के संबंध में सुरक्षा चिंताएं बढ़ाता है।

विश्वसनीय वेबसाइटों तक एक्सेस को सीमित करने से कुछ जोखिमों को कम किया जा सकता है, लेकिन यहां तक ​​कि विश्वसनीय स्रोत भी दुर्भावनापूर्ण सामग्री की मेजबानी कर सकते हैं। दुर्भावनापूर्ण निर्देशों का सामना करने की संभावना और उत्पादकता लाभ के बीच ट्रेड-ऑफ पर सावधानीपूर्वक विचार किया जाना चाहिए।

कर्मचारियों और AI एजेंटों के बीच अंतर महत्वपूर्ण हैं। कर्मचारी कानून और अनुबंधों के अधीन कानूनी व्यक्ति हैं, जो जवाबदेही प्रदान करते हैं। AI एजेंटों में इस कानूनी ढांचे का अभाव है, जिससे विश्वास करना अधिक कठिन हो जाता है।

MCP विकास के शुरुआती चरण

MCP की घोषणा नवंबर 2024 में ही की गई थी, और RFC सक्रिय रूप से विकसित हो रहा है।

कुछ लोग MCP सहित पूरी AI व्यक्तिगत सहायक अवधारणा को मौलिक रूप से त्रुटिपूर्ण मानते हैं।

1990 के दशक के अंत और 2000 के दशक की शुरुआत में AI सहायकों के लिए शुरुआती धक्का विफल रहा क्योंकि लंबवत एकीकरण और थोक क्रय शक्ति वाले सामग्री एग्रीगेटर्स अधिक प्रभावी साबित हुए। इससे एक्सपेडिया और ईबे जैसे प्लेटफार्मों का उदय हुआ।

मल्टी-एजेंट सिस्टम के लिए प्रोग्रामर को एजेंटों की स्थिति को प्रभावित करने की आवश्यकता होती है, जो एक चुनौतीपूर्ण प्रोग्रामिंग कार्य है।

मुफ्त मूल्य की सीमाएं

‘पार्किंग उपलब्धता द्वारा परिणामों को रैंक करने’ की इच्छा भुगतान किए गए APIs या विज्ञापन-समर्थित फ्रंटएंड के पीछे डेटा तक पहुंचने के मुद्दे को उजागर करती है। कंपनियां अपने पूरे डेटासेट तक API के माध्यम से मुफ्त में पहुंच प्रदान करने की संभावना नहीं है।

हालांकि सभी कंपनियां अपने डेटा को AI एजेंटों में एकीकृत नहीं करेंगी, लेकिन वर्कफ़्लो को पावर देने के लिए विभिन्न उपकरणों को संयोजित करने की क्षमता महत्वपूर्ण बनी हुई है।

जो कंपनियां डेटा खाई बनाए रखने को प्राथमिकता देती हैं, वे संभवतः नई तकनीकों का विरोध करेंगी जो उस खाई को खतरे में डालती हैं।

यदि booking.com के पास एक API होता, तो वे संभवतः अपनी वेबसाइट के समान परिणाम लौटाते, संभवतः JSON या XML प्रारूपण के साथ।

बिचौलिए को बायपास करना

booking.com जैसे बिचौलिए के लिए उपयोगकर्ताओं को उनकी सेवाओं को पूरी तरह से बायपास करने की अनुमति देना बहुत कम समझ में आता है।

हालांकि, व्यक्तिगत होटलों को booking.com को बायपास करना फायदेमंद लग सकता है, एक बिचौलिए जिसे वे अक्सर नापसंद करते हैं।

एक डीप रिसर्च AI विशिष्ट मानदंडों के आधार पर होटलों को स्कैन कर सकता है और booking.com के इंटरफ़ेस और विज्ञापनों को नेविगेट करने की आवश्यकता को दरकिनार करते हुए व्यक्तिगत होटलों द्वारा चलाए जा रहे होटल डिस्कवरी MCP सर्वर के साथ बातचीत कर सकता है।

व्यावहारिक उपयोग के मामले

MCP अधिक संरचित तरीके से इलास्टिकसर्च से लॉग प्राप्त करने या डेटाबेस को क्वेरी करने जैसे कार्यों को सुविधाजनक बना सकता है।

MCP सर्वर कॉन्फ़िगरेशन की स्थिर प्रकृति, जहां नए सर्वर को एक .json फ़ाइल संपादित करने और ऐप को पुनरारंभ करने की आवश्यकता होती है, सीमित हो सकती है।

फाइन-ट्यून्ड मॉडल

MCP को एक छोटे, फाइन-ट्यून्ड मॉडल के रूप में देखा जा सकता है जो कई MCP टूल को समझता है और प्रत्येक बातचीत के लिए सही टूल चुनता है।

कुछ परिदृश्यों के लिए संदर्भ के आधार पर टूल को गतिशील रूप से समायोजित करना आवश्यक हो सकता है।

खुले अंत वाली बातचीत और व्यावसायिक समस्याएं

MCP सामान्य, खुले अंत वाली बातचीत प्रणालियों के लिए उपयुक्त है जिसमें कोई पूर्वनिर्धारित प्रवाह नहीं है। हालांकि, यह हर व्यावसायिक समस्या के लिए एक आकार-फिट-सभी समाधान नहीं है। इसका उद्देश्य लैंगचेन जैसे फ्रेमवर्क को बदलना नहीं है।

MCP का विकल्प, एक खुला समुदाय-संचालित मानक, खंडित, मालिकाना और विक्रेता-लॉक प्रोटोकॉल है। बिना मानक के त्रुटिपूर्ण लेकिन विकसित मानक बेहतर है।

MCP को देखने का सबसे अच्छा तरीका APIs के चारों ओर क्लाइंट रैपर बनाने वाले व्यक्तिगत डेवलपर्स से API प्रदाताओं या समुदाय-रखरखाव वाले रैपर बनाने में बदलाव के रूप में है। यह NPM या PyPi के समान एक बड़ा टूलबॉक्स प्रदान करता है। हालांकि, ऑर्केस्ट्रेशन, सुरक्षा और उपयोग परिभाषा अभी भी आवश्यक है।

लैंगचेन की अगली पीढ़ी को इस बड़े टूलचेस्ट से लाभ होगा, लेकिन नवाचार की अभी भी आवश्यकता है।

उपयोगकर्ता-विशिष्ट उपकरण

कुछ मामलों में, उपकरण उपयोगकर्ता डेटा के लिए विशिष्ट हो सकते हैं, जैसे अपलोड की गई CSV फ़ाइलों को स्लाइस करने और हेरफेर करने के उपकरण।

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

मानक और विकसित हो रही प्रौद्योगिकी

समय के साथ नए मानक उभरते हैं, और मानकों को वास्तव में महत्व दिए जाने के बाद से इतना समय हो गया है कि लोग यह भूल गए हैं कि वे कैसे विकसित होते हैं।

LLM क्लाइंट में ‘टूल’ जोड़ने के लिए यादृच्छिक डेवलपर्स से छोटे सर्वर प्रोग्राम डाउनलोड करना जोखिम भरा हो सकता है।

उठाए गए मुद्दे वैध समस्याएं हैं जिन्हें MCP पारिस्थितिकी तंत्र को संबोधित करने की आवश्यकता है। कुछ समाधान MCP विनिर्देश के भीतर होंगे, जबकि अन्य बाहरी होंगे।

क्लाउड कोड और वास्तविक दुनिया का उपयोग

MCP की सफलता पर परस्पर विरोधी राय हैं। कुछ ने MCP के साथ एकीकृत होने वाली कंपनियों की कहानियां सुनी हैं, जबकि अन्य ने उन उपयोगकर्ताओं से सुना है जिन्होंने इसे निराशाजनक पाया है।

यह प्रचार और शुरुआती अपनाने की कमी को उजागर करता है।

कुछ डेवलपर्स पाते हैं कि अधिकांश उपयोग मामलों के लिए HTTP APIs MCP से बेहतर हैं। उनका तर्क है कि ‘टूल’ का उपयोग क्षमताओं और कार्यक्षमता के लिए API समापन बिंदुओं तक उबलता है।

APIs डिफ़ॉल्ट रूप से स्व-वर्णन नहीं कर रहे हैं, जो REST और HATEOAS समर्थकों के लिए अपने दृष्टिकोण को प्रदर्शित करने के लिए एक छूटे हुए अवसर का प्रतिनिधित्व करते हैं।

MCP लैंगचेन विकल्प के रूप में?

MCP को ‘लैंगचेन गंध’ के रूप में वर्णित किया गया है - एक जरूरी समस्या को हल नहीं करना, अत्यधिक सार होना और अपने फायदे को समझाने में कठिनाई होना।

शायद इसे ‘END OF LINE’ कहने और वानाबे हैकर्स को गेम ग्रिड से निर्वासित करने की आवश्यकता है!

एक महत्वपूर्ण प्रश्न यह है कि क्या ‘सामान्य’ चैटबॉट प्रतिमान बना रहेगा। अपने स्वयं के टूल वाले विशेष ऐप्स को MCP की आवश्यकता नहीं हो सकती है।

इसके विपरीत, जैसे-जैसे LLMs अधिक सक्षम होते जाते हैं, बाहरी टूल कम आवश्यक हो सकते हैं। जब LLM सीधे छवि को संपादित कर सकता है तो आप फोटोशॉप चलाने के लिए MCP क्यों चाहेंगे?

विज्ञान-फाई रोबोट सहायक का सपना साकार नहीं हो सकता है, और विशेष भाषा हेरफेर उपकरण अधिक उपयोगी हो सकते हैं।

उपयोगकर्ता आधार और सुरक्षा जागरूकता

MCP के उपयोगकर्ता आधार में कम तकनीकी व्यक्ति शामिल हैं, जिससे सुरक्षा मुद्दे विशेष रूप से प्रासंगिक हो जाते हैं। सुरक्षा सर्वोत्तम प्रथाओं के बारे में जागरूकता बढ़ाना महत्वपूर्ण है।

ओपनआरपीसी पर आधारित एक्सऑप्स, जिसके लिए परिणाम स्कीमा को परिभाषित करने की आवश्यकता होती है, यह योजना बनाने में मदद करता है कि आउटपुट इनपुट से कैसे कनेक्ट होते हैं, जटिल वर्कफ़्लो के लिए विश्वसनीयता में सुधार होता है।

प्रौद्योगिकी के विकसित होने और समय के साथ व्यवस्थित होने की संभावना है।

अतिरेक और क्लाउड इंफ्रास्ट्रक्चर

कुछ लोग MCP का उपयोग OpenAPI मानक पर करने से होने वाले लाभों पर सवाल उठाते हैं, इसे अनावश्यक मानते हैं।

OpenAPI सिस्टम को कॉल करने के लिए LLM किसका उपयोग करेगा? यह शेल से कैसे बंधेगा? LLM का होस्ट इसे कैसे ऑर्केस्ट्रेट करेगा?

MCP LLMs के लिए टूल कॉल करने का एक संरचित तरीका प्रदान करता है।

MCP सर्वर पहले से ही HTTP सर्वर हैं।

MCP का सबसे बड़ा फायदा OpenAI जैसे LLM प्रदाताओं के लिए है, न कि एप्लिकेशन डेवलपर्स के लिए।

LLMs टूल के बिना दिमाग हैं, और टूल कॉलिंग उन्हें सशक्त बनाती है। हालांकि, सामान्य APIs के साथ, LLM प्रदाताओं के पास उन टूल तक पहुंच नहीं है। MCP उन्हें एक्सेस प्रदान करता है, जिससे उन्हें AI के प्रवेश द्वार के रूप में स्थान मिलता है।

CLI बनाम API

CLI का सीधे उपयोग क्यों न करें, यह देखते हुए कि LLMs को प्राकृतिक भाषा पर प्रशिक्षित किया जाता है और CLIs एक सामान्य मानव-पठनीय और लिखने योग्य समाधान हैं?

MCP बहुत जल्दी उभरा और इसे परिपक्व होने के लिए समय चाहिए। इसमें एक पारंपरिक मानक निकाय द्वारा जांच का अभाव है और यह प्रचार द्वारा संचालित है।

वास्तविक दुनिया के अनुप्रयोगों की कमी है।

MCP के मुख्य अनुप्रयोग

MCP का उपयोग क्लाउड डेस्कटॉप और आला AI चैट ऐप्स, कोड ऑटोमेशन टूल और एजेंट/LLM ऑटोमेशन फ्रेमवर्क में किया जाता है।

यह एक और जल्दबाजी वाली तकनीक है जिसे अगली हाइप-एबल संक्षिप्त शब्द के आने पर संभवतः छोड़ दिया जाएगा।

भाषा मॉडल टूल कॉलिंग प्रोटोकॉल दो प्रकार के होते हैं: जिनके बारे में लोग शिकायत करते हैं और जिनका कोई उपयोग नहीं करता है।

एन्थ्रोपिक ने इस ‘मानक’ को वैक्यूम में विकसित किया, जिससे सुरक्षा मुद्दे सामने आए।

JSON-RPC 2.0

MCP JSON-RPC 2.0 पर बनाया गया है, जो एक हल्का प्रोटोकॉल है जो JSON का उपयोग करके क्लाइंट और सर्वर संचार की अनुमति देता है।

यह एक विशिष्ट पारिस्थितिकी तंत्र के लिए डिज़ाइन किए गए केंद्रीकृत विनिर्देश की तरह लगता है, बिना इसे अर्जित किए सार्वभौमिकता का दावा करता है।

MCP उपयोगी चीजें करने के लिए पर्याप्त शक्तिशाली है, जो सुरक्षा चिंताओं को बढ़ाता है।

यह एक परिपक्व मानक नहीं है और इसे सुरक्षित होने के लिए डिज़ाइन नहीं किया गया था।

जबकि सिफारिशें मौजूद हैं, उन्हें लागू या कार्यान्वित नहीं किया जाता है।

लैंगचेन और टूल कॉलिंग

लैंगचेन कई फ्रेमवर्क में से एक है जो ‘टूल कॉलिंग’ पैटर्न को लागू करता है।

MCP एक भाषा मॉडल के संदर्भ विंडो में बाहरी जानकारी कैसे प्रवेश करती है, इसके लिए एक विनिर्देश है, जिसमें टूल कॉलिंग, टेम्पलेटेड इनपुट, रद्द करना, प्रगति ट्रैकिंग और टूल सर्वर की राज्यता शामिल है।

यह विवरणों को मानकीकृत करने में मदद करता है ताकि कोई भी सहायक/एकिकरण कॉम्बो संगत हो।

जबकि MCP के साथ वैध समस्याएं हैं, आलोचकों को अपनी तर्कों को परिष्कृत करना चाहिए।

प्रमाणीकरण महत्वपूर्ण है और इसे प्रारंभिक संस्करण से नहीं छोड़ा जाना चाहिए था।

बहुत अधिक जटिलताएँ हैं।