मशीन कम्युनिकेशन प्रोटोकॉल (MCP): त्रुटी आणि संभाव्यतेचे परीक्षण
तंत्रज्ञान जगात, विशेषत: मोठ्या भाषिक मॉडेलमध्ये (LLMs), मशीन कम्युनिकेशन प्रोटोकॉल (MCP) या संकल्पनेने लक्षणीय लक्ष वेधले आहे. हे LLM आणि बाह्य संसाधनांमधील संवाद सुलभ करण्याचे आश्वासन देत असले तरी, बारकाईने पाहिल्यास अनेक अंतर्निहित समस्या आणि मर्यादा दिसून येतात ज्यांचा काळजीपूर्वक विचार करणे आवश्यक आहे. हे विश्लेषण MCP च्या आसपासच्या टीकांवर प्रकाश टाकते, त्याची असुरक्षितता, स्केलेबिलिटीची आव्हाने आणि AI एजंट विकासासाठी व्यापक परिणाम शोधते.
MCP च्या जबाबदाऱ्यांचा अतिभार
एक सामान्य टीका म्हणजे MCP वर जास्त जबाबदारी सोपवली जात आहे. लेखकाचा युक्तिवाद आहे की MCP ने प्रामुख्याने LLM साठी बाह्य संसाधनांमध्ये प्रवेश करण्यासाठी आणि त्यांच्याशी संवाद साधण्यासाठी एक प्रवेशद्वार म्हणून काम केले पाहिजे. याला केवळ ‘दरवाजा’ किंवा ‘पूल’ म्हणून पाहिल्यास त्याचा उद्देश आणि मर्यादा स्पष्ट होतात.
अपघाती डेटा एक्सपोजर, प्रॉम्प्ट इंजेक्शन असुरक्षा आणि खर्च नियंत्रणातील कमतरता यासारख्या समस्या थेट MCP ला देणे हे चुकीचे आहे. या अशा समस्या आहेत ज्या विकसकांनी त्यांच्या नियंत्रणाखाली असलेल्या सीमेमध्ये सोडवल्या पाहिजेत. विकसकांनी दर मर्यादा लागू करणे आणि प्रोटोकॉल वापरला जात आहे की नाही याची पर्वा न करता वापरावर लक्ष ठेवणे आवश्यक आहे. याची तुलना वेग वाढवण्यासाठी रस्त्याला दोष देण्यासारखे आहे – पायाभूत सुविधा वैयक्तिक वर्तनासाठी जबाबदार नाहीत.
अखेरीस, उपस्थित केलेल्या अनेक चिंता AI एजंटना कार्ये सोपवण्याशी संबंधित व्यापक समस्या आहेत. विकसकांनी API कडून सर्वकाही हाताळण्याची अपेक्षा करण्याऐवजी त्यांच्या विशिष्ट ऍप्लिकेशन्समध्ये या समस्यांचे व्यवस्थापन करण्याची जबाबदारी घेणे आवश्यक आहे.
LLM आणि प्रॉम्प्ट इंजेक्शनची दुधारी तलवार
MCP विषयी अलीकडील चर्चा अनेकदा तीक्ष्ण चाकूच्या अंतर्निहित धोक्यांबद्दलच्या इशाऱ्यांसारखी असते – जर व्यवस्थित हाताळले नाही तर ते कापू शकतात. प्रॉम्प्ट इंजेक्शन, एक महत्त्वपूर्ण चिंता, LLM च्या स्वरूपाचा परिणाम आहे. प्रॉम्प्ट इंजेक्शनचा धोका दूर करण्याचा प्रयत्न LLM ला मौल्यवान बनवण्याची क्षमता कमी करतो.
पारंपारिक प्रणालींमध्ये सामान्य असलेल्या ‘नियंत्रण विरुद्ध डेटा’ पृथक्करणाची संकल्पना LLM मध्ये नैसर्गिकरित्या अस्तित्वात नाही. LLM त्यांची शक्ती आणि सामान्यता अचूकपणे मिळवतात कारण त्यांच्यात हे कठोर पृथक्करण नसते. हे अंतर्निहित वैशिष्ट्य त्यांना प्रॉम्प्ट इंजेक्शन हल्ल्यांसाठी असुरक्षित बनवते.
रिमोट MCPs एक सेवा म्हणून धोके निर्माण करू शकतात, परंतु दोष प्रोटोकॉलमध्ये नाही तर संवेदनशील कार्ये अज्ञात तृतीय पक्षांवर सोपवण्यात आहे. ही उपमा बेफिकीर Roomba ला चाकू टेप करण्याच्या कल्पनेपर्यंत विस्तारित आहे – समस्या स्वतः चाकू नाही, तर अनपेक्षित डिव्हाइसला जोडण्याचा निर्णय आहे.
‘काळजी घ्या’ किंवा संरक्षणात्मक गियरच्या सूचना, तांत्रिकदृष्ट्या अचूक असताना, मूळ मुद्दा चुकवतात: तीक्ष्ण साधन अनियंत्रित प्रणालीसह एकत्रित करण्याचा सल्ला नसलेला निर्णय.
स्केलेबिलिटीची आव्हाने
सुरक्षेच्या चिंतेव्यतिरिक्त, MCP ला मूलभूत स्केलेबिलिटी मर्यादांचा सामना करावा लागतो. लेखक LLM विश्वसनीयता आणि प्रदान केलेल्या निर्देशात्मक संदर्भाच्या प्रमाणात नकारात्मक संबंध दर्शवतात. हे अधिक डेटा आणि एकत्रीकरण जोडल्याने स्वयंचलितपणे समस्या सुटतील या सामान्य समजुतीला आव्हान देते. साधनांची आणि एकत्रीकरणांची संख्या वाढल्यामुळे, एजंटची कार्यक्षमता कमी होऊ शकते आणि त्याच वेळी प्रत्येक विनंतीची किंमत वाढू शकते.
लेखक जोर देतात की MCP एका विशिष्ट मर्यादेपेक्षा जास्त वाढत नाही. एजंटच्या संदर्भात अमर्यादित साधने जोडण्याचा प्रयत्न केल्यास त्याच्या क्षमतेवर नकारात्मक परिणाम होईल. ही मर्यादा MCP च्या संकल्पनेत अंतर्निहित आहे आणि प्रमाणीकरण समस्यांपेक्षा जास्त लक्ष देणे आवश्यक आहे.
वापरकर्त्यांना अधिक MCP सर्व्हर सक्षम केल्यावर कार्यक्षमतेत घट जाणवू शकते, ज्यामुळे त्यांच्यात हस्तक्षेप होतो. हे सामान्य पॅकेज व्यवस्थापन प्रणालीच्या अगदी उलट आहे, जिथे गैर-हस्तक्षेप हा एक मूलभूत गुणधर्म आहे.
MCP मधील मूळ समस्या ही आहे की त्याचे वास्तविक वर्तन वापरकर्त्याच्या अपेक्षांपासून विचलित होते. MCP हे प्लग-एंड-प्ले सोल्यूशन नाही हे ओळखणे महत्त्वाचे आहे जे कोणत्याही परिणामांशिवाय अमर्यादित साधनांना अखंडपणे एकत्रित करते.
UI आणि साधन व्यवस्थापनासह मर्यादांचे निराकरण
MCP च्या मर्यादांवर प्रस्तावित केलेल्या उपायांपैकी एक म्हणजे वापरकर्ता इंटरफेस सुधारणे. जर एखादे साधन अनपेक्षितपणे कार्यान्वित केले गेले, तर UI ने ते अक्षम करण्याचा किंवा त्याचा हेतू वापर स्पष्ट करण्यासाठी त्याचे वर्णन सुधारण्याचा एक सोपा मार्ग प्रदान केला पाहिजे.
लेखक हे देखील नमूद करतात की संदर्भातील वाढ अनेकदा सुधारित कार्यक्षमतेस आणि वास्तविक-जगातील उपयोग क्षमतेस कारणीभूत ठरते, ज्यामुळे सक्तीने नकारात्मक संबंधाची कल्पना खंडित होते. तथापि, ते कबूल करतात की काही विशिष्ट परिस्थितीत किंवा खराब डिझाइन केलेल्या संदर्भांमध्ये, कार्यक्षमतेत घट येऊ शकते.
साधनांच्या जबरदस्त निवडीला संबोधित करण्यासाठी, ‘विभाजन आणि जिंका’ दृष्टीकोन सुचविला जातो. यामध्ये दिलेल्या कार्यासाठी सर्वात संबंधित साधने निवडण्यासाठी विशेषतः डिझाइन केलेले साधन जोडणे समाविष्ट आहे. हे ‘साधन-निवडण्याचे साधन’ आणखी एक LLM कॉल असू शकते, ज्याला ‘पॅरेंट’ एजंटला उपलब्ध साधनांचा उपसंच परत करण्याचे काम दिले जाते. हा स्तरित दृष्टीकोन जटिलता व्यवस्थापित करण्यासाठी अप्रत्यक्षतेचे अतिरिक्त स्तर जोडतो.
तथापि, केवळ संदर्भात साधने असल्याने मॉडेलचे आउटपुट लक्षणीयरीत्या बदलू शकते. संदर्भात संबंधित साधने ( retrieval-augmented generation किंवा RAG सारख्या तंत्राद्वारे साध्य केलेले) फायदेशीर असले तरी, ‘get_tools’ विनंतीच्या मागे सर्व साधने लपवणे हानिकारक असू शकते.
MCP एक वाहतूक आणि अधिकृतता स्तर म्हणून
MCP प्रामुख्याने साधन-स्तरीय अधिकृततेवर लक्ष केंद्रित करून, विनंती/प्रतिक्रिया जीवनचक्रासह वाहतूक आणि वायर स्वरूप म्हणून कार्य करते. निबंध असा युक्तिवाद करतो की MCP मधील सर्वात मोठी समस्या AI एजंट्सना कार्यात्मकपणे साधनांची रचना करण्यास सक्षम करण्यात त्याची असमर्थता आहे.
लेखक असा दावा करतात की MCP ची मुळात गरज नाही, कारण LLM मध्ये OpenAPI तपशील वापरून API सोबत संवाद साधण्याची क्षमता आधीच आहे. गहाळ घटक अधिकृतता आहे – AI कोणत्या API मध्ये प्रवेश करू शकते हे नियंत्रित करण्याची क्षमता. MCP ऐवजी, लेखक AI ला विशिष्ट एंडपॉइंटवर अधिकृतता लागू करताना HTTP विनंत्या करण्याची परवानगी देण्याचा सल्ला देतात. हा दृष्टीकोन सध्याच्या API ला पातळ MCP साधनांनी गुंडाळण्याच्या प्रवृत्तीशी जुळतो.
MCP चा एक विशेष त्रासदायक पैलू म्हणजे स्ट्रीमिंग टूल कॉल निकालांसाठी त्याचा समर्थनाचा अभाव. एकल विनंती/प्रतिक्रिया जोडी क्लायंटला पृष्ठांकनासाठी वारंवार साधनांना कॉल करण्यास भाग पाडते, ज्यामुळे दीर्घकाळ चालणाऱ्या प्रक्रिया बाधित होतात. स्ट्रीमिंग क्षमता अंमलात आणल्याने, कदाचित gRPC वापरून, MCP ची कार्यक्षमता लक्षणीयरीत्या सुधारू शकते.
संवेदनशील डेटा उघड करणे सोपे
MCP विषयी एक महत्त्वपूर्ण चिंता म्हणजे संवेदनशील डेटा सहजपणे उघड होण्याची शक्यता. याव्यतिरिक्त, MCP मुळात AI एजंट्सना अधिक विश्वसनीय बनवत नाही; हे त्यांना अधिक साधनांमध्ये प्रवेश देते, जे काही परिस्थितीत विरोधाभासाने विश्वासार्हता कमी करू शकतात.
लेखक कबूल करतात की त्यांना MCP या सर्व समस्या सोडवेल किंवा त्यांसाठी जबाबदार असेल अशी अपेक्षा नाही. त्याऐवजी, MCP या समस्यांसाठी एक मोठे क्षेत्र तयार करते, ज्यासाठी ॲप विकासक आणि वापरकर्त्यांनी सतर्क राहणे आवश्यक आहे.
उपमा आणि शहरी नियोजन
लेखक शहरी नियोजनाची उपमा वापरून हा मुद्दा स्पष्ट करतात. MCP ची तुलना 25mph वेगाच्या मर्यादेसह सहा-लेन शहराच्या रस्त्याशी केल्याने डिझाइन आणि हेतू वापर यांच्यातील डिस्कनेक्ट दिसून येतो. केवळ दंड आकारणे किंवा वरवरच्या ‘दुरुस्त्या’ जोडल्याने खराब डिझाइनची मूळ समस्या सुटत नाही.
प्रभावी शहरी नियोजनामध्ये असे रस्ते डिझाइन करणे समाविष्ट आहे जे नैसर्गिकरित्या वेगाच्या मर्यादेचे पालन करण्यास प्रोत्साहित करतात. त्याचप्रमाणे, MCP ची रचना संभाव्य धोके कमी करण्यासाठी अंतर्निहितपणे केली जावी, केवळ बाह्य नियंत्रणांवर अवलंबून राहू नये.
LLM नको असलेल्या क्रिया करत आहे
हा लेख LLM ला सेवांवर क्रिया करण्याची परवानगी देणाऱ्या प्रोटोकॉलच्या व्यापक टीकेकडे वळतो. लेखक एक मूळ समस्या ओळखतात: LLM अशा क्रिया करू शकतात ज्या वापरकर्त्यांना घ्यायच्या नाहीत. ते LLM स्वतंत्रपणे घेऊ शकणाऱ्या क्रिया आणि ज्यांना वापरकर्त्याच्या प्रॉम्प्टची आवश्यकता आहे त्यांच्यात फरक करतात.
अंतिम ध्येय LLM द्वारे संपूर्ण व्यवसायांचे व्यवस्थापन करणे असले तरी, तंत्रज्ञान अद्याप अशा स्वायत्ततेसाठी तयार नाही. सध्या, वापरकर्त्यांना AI ने पूर्वी पुनरावलोकन केल्याशिवाय ईमेल पाठवावेत असे वाटत नाही.
लेखक वापरकर्त्याकडून पुष्टीकरणासाठी प्रॉम्प्ट करण्याचा उपाय नाकारतात, कारण बहुतेक साधने निरुपद्रवी दिसत असताना वापरकर्ते स्वयंचलित पुष्टीकरण (‘YOLO-mode’) च्या नमुन्यात पडण्याचा धोका असतो. याची तुलना कार्डने रोख रकमेपेक्षा जास्त खर्च करण्याच्या मानसिक घटनेशी केली जाते – मानवी वर्तनात रुजलेली समस्या, तंत्रज्ञानात नाही.
मूलभूत प्रश्नः फक्त APIs का वापरू नये?
MCP विषयीच्या चर्चेत वारंवार विचारला जाणारा प्रश्न म्हणजे APIs चा थेट वापर का करू नये.
MCP वापरकर्त्यांद्वारे थेट नियंत्रित नसलेल्या LLM क्लायंट्सना (उदा. Claude, ChatGPT, Cursor, VSCode) API सोबत संवाद साधण्याची परवानगी देते. MCP शिवाय, विकासकांना LLM API वापरून सानुकूल क्लायंट तयार करावे लागतील, विशिष्ट साधने कशी वापरायची हे शिकवण्यापेक्षा विद्यमान क्लायंट्सना सदस्यता देऊन वापरणे अधिक महाग आहे.
एका विकासकाने USB द्वारे त्यांच्या FM हार्डवेअर सिंथेसायझरशी कनेक्ट होण्यासाठी MCP सर्व्हर तयार करण्याचा अनुभव सामायिक केला, ज्यामुळे AI-आधारित ध्वनी डिझाइन सक्षम होते.
LLM क्लायंट एकत्रीकरण आणि मानकीकरण
मूळ मुद्दा हा आहे की सर्व LLM क्लायंट्स थेट API संवादाला मूळतः समर्थन देत नाहीत, ChatGPT सानुकूल GPT क्रिया हे एक उल्लेखनीय अपवाद आहे. Anthropic, Google आणि OpenAI यांनी Claude, ChatGPT आणि Cursor सारख्या LLM-पॉवर्ड क्लायंट्ससाठी प्रक्रिया सुलभ करण्यासाठी MCP ला सामायिक प्रोटोकॉल म्हणून स्वीकारण्यास सहमती दर्शविली आहे.
MCP LLM क्लायंट तयार करणाऱ्यांसाठी प्रक्रिया सुलभ करते. जर तुम्हाला LLM ला API सोबत संवाद साधायचा असेल, तर तुम्ही फक्त API की देऊ शकत नाही आणि ती कार्य करेल अशी अपेक्षा करू शकत नाही – तुम्हाला एक एजंट तयार करण्याची आवश्यकता आहे.
MCP ला API चे दस्तऐवजीकरण करण्याचा आणि त्यांना कसे कॉल करायचे याचे वर्णन करण्याचा एक मार्ग म्हणून पाहिले जाऊ शकते, त्या दस्तऐवजीकरणाला उघड करण्यासाठी आणि कॉल सुलभ करण्यासाठी मानकीकृत साधनांसह. हे अनावश्यक गुंतागुंत न करता API गुंडाळण्यासाठी पुरेसे अमूर्तता प्रदान करते, परंतु ही साधेपणा वापरकर्त्यांना ‘स्वतःच्या पायावर कुऱ्हाड मारण्यास’ प्रवृत्त करू शकते.
MCP ची कार्यक्षमता आणि पुनर्वापरक्षमता
MCP शिवाय, विकासकांना प्रत्येक वेळी साधन वापरले जाते तेव्हा LLM ला ते कसे वापरायचे हे वारंवार सांगावे लागेल. माहिती विसरल्यामुळे किंवा गैर-मानक API वर्तनामुळे LLM साधन योग्यरित्या वापरण्यात अयशस्वी होण्याचा धोका असतो.
हे सतत स्पष्टीकरण आणि डुप्लिकेशन संदर्भामध्ये टोकन वाया घालवते, खर्च आणि वेळ वाढवते. MCP आवश्यक असलेली सर्व माहिती एकत्र करून ही प्रक्रिया सुलभ करते, साधन वापर अधिक कार्यक्षम बनवते आणि साधन सामायिकरण सुलभ करते.
LLM प्रदात्याला ‘येथे एक साधन आहे जे तुम्ही वापरू शकता’ असे API दस्तऐवजीकरणासह सांगून, वापरकर्ते त्या साधनांचा वारंवार आठवण न करता अनेक चॅटमध्ये पुनर्वापर करू शकतात. हे डेस्कटॉप LLM क्लायंट्सना स्थानिक पातळीवर चालणाऱ्या प्रोग्रामशी कनेक्ट करण्यास देखील सक्षम करते, OS-विशिष्ट अंमलबजावणी प्रक्रियेची समस्या सोडवते.
MCP आणि स्थानिक संसाधन प्रवेश
MCP LLM साठी फायली, पर्यावरण व्हेरिएबल्स आणि नेटवर्क ऍक्सेस सारख्या स्थानिक संसाधनांमध्ये प्रवेश सुलभ करते. हे स्थानिक पातळीवर चालवण्यासाठी डिझाइन केलेले आहे, LLM ला या संसाधनांमध्ये नियंत्रित प्रवेश प्रदान करते.
मानक LLM साधन कॉल ‘आकार’ MCP साधन कॉल ‘आकारा’चे जवळून अनुसरण करतो, ज्यामुळे ते साधनांना एजंट्सशी जोडण्यासाठी सरळ मानक बनते.
MCP AI मॉडेलला उघड केलेल्या फंक्शन कॉलिंग स्कीमा आणि अंतर्निहित API यांच्यातील पूल म्हणून कार्य करते. हे फंक्शन कॉलचे साधनांमध्ये भाषांतर करते, अखंड संप्रेषण सक्षम करते.
जर तुम्ही साधन प्रदाता असाल, तर MCP AI एजंट फ्रंटएंड्सना तुमच्या साधनाशी कनेक्ट करण्यासाठी एक मानकीकृत प्रोटोकॉल ऑफर करते. हे HTTP आणि OpenAPI मानक प्रोटोकॉल का असू शकत नाही या प्रश्नाचे उत्तर देते.
MCP एक मेटा-API आहे जी एंडपॉइंट्स आणि त्यांच्या ऑपरेशनल डिटेल्स तपशीलांमध्ये समाविष्ट करते, ज्यामुळे LLM अधिक प्रभावीपणे संवाद साधू शकतात.
विशिष्ट परिस्थितीत MCP
जेव्हा वापरकर्ते प्रश्न विचारतात किंवा कोणते API वापरायचे याबद्दल अनिश्चित असतात तेव्हा MCP समस्या सोडवू शकते. हे मागील संदेशांवर आधारित विनंत्या देखील process करू शकते.
एका वापरकर्त्याने ‘X’ मिळवण्याची आणि ती एंडपॉइंटला पाठवण्याची इच्छा व्यक्त केली. त्यांना MCP एवढ्या सोप्या कामासाठी जास्त वाटले, हे दर्शवते की मूलभूत API संवादांसाठी ते नेहमीच आवश्यक नसते.
MCP ची तुलना नेटवर्कवर संवाद साधण्यास सक्षम असलेले सॉफ्टवेअर तयार करण्यासाठी FastAPI वेब ॲप फ्रेमवर्कशी केली जाते, जे विशेषत: एजंटिक अनुभवांसाठी डिझाइन केलेले आहे. हे AI एजंट विकासासाठी मानकीकृत फ्रेमवर्क प्रदान करून, ‘Rails-for-Skynet’ म्हणून पाहिले जाऊ शकते.
प्रदाता नियंत्रणाबद्दल चिंता
अशी चिंता आहे की MCP प्रणालीवर प्रदाता-साइड नियंत्रण वाढवण्यासाठी ढकलले जात आहे. LLM प्रदाते Gmail सह IMAP/SMTP वापरणे कठीण केल्याप्रमाणे API ऍक्सेस प्रतिबंधित करू शकतात.
OpenAPI एजंट्सना /openapi.json वरून API तपशील पुनर्प्राप्त करण्यास अनुमती देते.
MCP जलद संवादांना सक्षम करते, वापरकर्त्यांना इनपुट डेटा तयार करण्यात, API ला पाठवण्यात, आउटपुट parse करण्यात आणि प्रत्येक संदेशासाठी प्रक्रिया पुन्हा करण्यात वेळ न घालवता काही सेकंदात कार्ये पूर्ण करण्यास अनुमती देते.
सँडबॉक्सिंग आणि सुरक्षा धोके
सर्वात मोठ्या समस्यांपैकी एक म्हणजे एका MCP सर्व्हर टूलचे आउटपुट समान संदेश थ्रेडमधील इतर साधनांवर कसा परिणाम करू शकते. हे अनपेक्षित परिणाम टाळण्यासाठी साधनांमध्ये सँडबॉक्सिंगची आवश्यकता दर्शवते. Invariant Labs ने टूल वर्णनांसह या समस्येचे निराकरण केले, तर इतरांनी MCP संसाधन संलग्नके वापरली आहेत. सँडबॉक्सिंगच्या अभावामुळे प्रॉम्प्ट इंजेक्शनचा धोका वाढतो.
याची तुलना SQL इंजेक्शनशी केली जाते – एकत्र जोडलेली एक प्रणाली जिथे कमीतकमी निरीक्षणासह कोणत्याही क्षणी असुरक्षिततेचा फायदा घेतला जाऊ शकतो.
प्रॉम्प्ट इंटरफेस SQL इंजेक्शनसाठी देखील असुरक्षित आहे, कारण मॉडेल प्रॉम्प्टच्या विश्वसनीय भागांना वापरकर्त्याने दूषित केलेल्या इनपुटपासून वेगळे करू शकत नाही. हे सोडवण्यासाठी एन्कोडिंग, डिकोडिंग आणि मॉडेल प्रशिक्षणात मूलभूत बदल आवश्यक आहेत.
हे प्रॉम्प्ट इंजेक्शन आणि टूल इंजेक्शन दोन्हीसाठी अनुमती देते, ज्यामुळे संभाव्यतः अविश्वसनीय कोड कार्यान्वित होतो.
कंटेनरायझेशन आणि नियंत्रित ऍक्सेस
एका विकासकाने एक MCP सर्व्हर तयार केला जो प्रोजेक्ट कोड माउंटेड असलेल्या Docker कंटेनरला सुरू करतो. हा दृष्टीकोन LLM ला सँडबॉक्स्ड वातावरणात संपूर्ण Unix टूलसेट आणि प्रोजेक्ट-विशिष्ट टूलिंगमध्ये प्रवेश करण्याची परवानगी देतो.
चॅट-आधारित इंटरफेसद्वारे चालविलेले हे एजंटिक वर्कफ्लो पारंपारिक पद्धतींपेक्षा अधिक प्रभावी ठरले आहे.
MCP एजंट्सना त्यांना आवश्यक असलेला ऍक्सेस देणे आणि त्याहून अधिक काही नाही हे महत्त्वाचे आहे. सुरक्षा धोके कमी करण्यासाठी कंटेनरायझेशन आणि पारदर्शक टूल UX महत्त्वपूर्ण आहेत.
व्हर्च्युअल मशीन आणि इंटरनेट ऍक्सेस
एजंट्सना किमान Linux इंस्टॉलेशन असलेले संगणक देणे (VM किंवा कंटेनर म्हणून) चांगले परिणाम देऊ शकते, ज्यामुळे त्यांना इंटरनेटवरून माहिती मिळवता येते. तथापि, यामुळे दुर्भावनापूर्ण सूचना आणि डेटा एक्स्फिल्ट्रेशन संदर्भात सुरक्षा चिंता वाढतात.
विश्वसनीय वेबसाइट्समध्ये ऍक्सेस मर्यादित केल्याने काही धोके कमी होऊ शकतात, परंतु अगदी विश्वसनीय स्त्रोत देखील दुर्भावनापूर्ण सामग्री होस्ट करू शकतात. दुर्भावनापूर्ण सूचनांना सामोरे जाण्याची शक्यता आणि उत्पादकतेच्या फायद्यांमधील ट्रेड-ऑफचा काळजीपूर्वक विचार केला पाहिजे.
कर्मचारी आणि AI एजंट्समधील फरक महत्त्वपूर्ण आहेत. कर्मचारी हे कायदेशीर व्यक्ती आहेत जे कायदे आणि करारांच्या अधीन आहेत, ज्यामुळे उत्तरदायित्व प्रदान केले जाते. AI एजंट्समध्ये या कायदेशीर फ्रेमवर्कचा अभाव आहे, ज्यामुळे विश्वास ठेवणे अधिक कठीण होते.
MCP विकासाची प्रारंभिक अवस्था
MCP ची घोषणा नोव्हेंबर 2024 मध्ये झाली होती आणि RFC सक्रियपणे विकसित होत आहे.
काहीजण MCP सह संपूर्ण AI वैयक्तिक सहाय्यक संकल्पना मुळात सदोष मानतात.
1990 च्या दशकाच्या उत्तरार्धात आणि 2000 च्या दशकाच्या सुरुवातीला AI सहाय्यकांसाठी केलेला प्रारंभिक प्रयत्न अयशस्वी ठरला कारण उभ्या एकत्रीकरण आणि मोठ्या प्रमाणात खरेदी शक्ती असलेले सामग्री एग्रीगेटर अधिक प्रभावी ठरले. यामुळे Expedia आणि eBay सारख्या प्लॅटफॉर्मचा उदय झाला.
मल्टी-एजंट सिस्टमसाठी प्रोग्रामरला एजंट्सच्या स्थितीवर प्रभाव टाकण्याची आवश्यकता असते, हे एक कठीण प्रोग्रामिंग कार्य आहे.
विनामूल्य मूल्याची मर्यादा
‘पार्किंग उपलब्धतेनुसार निकालांना रँक’ करण्याच्या इच्छेमुळे सशुल्क API किंवा जाहिरात-समर्थित फ्रंटएंड्सच्या मागे डेटा ऍक्सेस करण्याची समस्या दिसून येते. कंपन्या API द्वारे त्यांच्या संपूर्ण डेटासेटमध्ये विनामूल्य ऍक्सेस प्रदान करण्याची शक्यता कमी आहे.
सर्व कंपन्या त्यांचा डेटा AI एजंटमध्ये समाविष्ट करणार नाहीत, परंतु वर्कफ्लोला शक्ती देण्यासाठी विविध साधनांना एकत्र आणण्याची क्षमता महत्त्वपूर्ण आहे.
डेटाचा खंदक राखण्यास प्राधान्य देणाऱ्या कंपन्या त्या खंदकाला धोका देणाऱ्या नवीन तंत्रज्ञानाचा प्रतिकार करतील.
जर booking.com कडे API असेल, तर ते त्यांच्या वेबसाइट प्रमाणेच निकाल देतील, शक्यतो JSON किंवा XML स्वरूपात.
मध्यस्थांना बायपास करणे
booking.com सारख्या मध्यस्थांनी वापरकर्त्यांना त्यांच्या सेवा पूर्णपणे बायपास करण्याची परवानगी देणे अर्थपूर्ण नाही.
तथापि, वैयक्तिक हॉटेल्सना booking.com ला बायपास करणे फायदेशीर वाटू शकते, हा एक मध्यस्थ आहे ज्यांना ते अनेकदा नापसंत करतात.
डीप रिसर्च AI विशिष्ट निकषांवर आधारित हॉटेल्स शोधू शकते आणि booking.com चा इंटरफेस आणि जाहिराती नेव्हिगेट करण्याची आवश्यकता टाळून वैयक्तिक हॉटेल्सद्वारे चालवलेल्या हॉटेल डिस्कव्हरी MCP सर्व्हरशी संवाद साधू शकते.
व्यावहारिक उपयोग प्रकरणे
MCP Elasticsearch मधून लॉग आणणे किंवा डेटाबेसमध्ये अधिक संरचित मार्गाने क्वेरी करणे यासारख्या कार्यांना सुलभ करू शकते.
MCP सर्व्हर कॉन्फिगरेशनची स्थिर प्रकृती, जेथे नवीन सर्व्हरसाठी ‘.json’ फाइल संपादित करणे आणि ॲप रीस्टार्ट करणे आवश्यक आहे, ते मर्यादित असू शकते.
फाइन-ट्यून केलेले मॉडेल
MCP ला एक लहान, फाइन-ट्यून केलेले मॉडेल म्हणून पाहिले जाऊ शकते जे अनेक MCP साधने समजून घेते आणि प्रत्येक संभाषणासाठी योग्य साधने निवडते.
काही परिस्थितीत संदर्भावर आधारित साधनांचे गतिशील समायोजन आवश्यक असू शकते.
ओपन-एंडेड संभाषणे आणि व्यवसाय समस्या
MCP पूर्वनिर्धारित प्रवाहाशिवाय सामान्य, ओपन-एंडेड संभाषण प्रणालीसाठी योग्य आहे. तथापि, हे प्रत्येक व्यवसाय समस्येसाठी एक-आकार-फिट-सर्व सोल्यूशन नाही. हे LangChain सारख्या फ्रेमवर्कला बदलण्याचा हेतू नाही.
MCP चा पर्याय, एक ओपन कम्युनिटी-ड्रिव्हन स्टँडर्ड, खंडित, मालकीचा आणि विक्रेता-लॉक प्रोटोकॉल आहे. सदोष पण विकसित होणारे मानक नसलेल्या मानकांपेक्षा चांगले आहे.
MCP कडे पाहण्याचा सर्वोत्तम मार्ग म्हणजे API च्या आसपास क्लायंट रॅपर तयार करणाऱ्या वैयक्तिक विकासकांकडून API प्रदात्यांकडे किंवा समुदाय-देखभाल केलेल्या रॅपरकडे बदल. हे NPM किंवा PyPi प्रमाणे एक मोठे टूलबॉक्स प्रदान करते. तथापि, ऑर्केस्ट्रेशन, सुरक्षा आणि वापर व्याख्या अजूनही आवश्यक आहेत.
पुढील पिढीतील Langchains ला या मोठ्या टूलचेस्टचा फायदा होईल, परंतु अजूनही नवकल्पना आवश्यक आहे.
वापरकर्ता-विशिष्ट साधने
काही प्रकरणांमध्ये, साधने वापरकर्त्याच्या डेटासाठी विशिष्ट असू शकतात, जसे की अपलोड केलेल्या CSV फायली स्लाइस आणि मॅनिपुलेट करण्याची साधने.
एक वारंवार दुर्लक्षित केलेला मुद्दा म्हणजे MCP मॉडेल संदर्भात खूप जास्त पर्याय देऊ शकते. वाया जाणारा टोकन वापर आणि अनियमित मॉडेल वर्तन टाळण्यासाठी प्राधान्यक्रम आणि मेटाडेटा एक्सपोजर महत्त्वपूर्ण आहेत.
मानके आणि विकसित होणारे तंत्रज्ञान
नवीन मानके कालांतराने उदयास येतात आणि मानकांना खरोखरच महत्त्व देऊन खूप वेळ झाला आहे की लोकांना ते कसे विकसित होतात हे विसरले आहे.
LLM क्लायंटमध्ये ‘साधने’ जोडण्यासाठी यादृच्छिक विकासकांकडून लहान सर्व्हर प्रोग्राम डाउनलोड करणे धोकादायक असू शकते.
उपस्थित केलेल्या समस्या कायदेशीर समस्या आहेत ज्यांचे MCP इकोसिस्टमने निराकरण करणे आवश्यक आहे. काही उपाय MCP स्पेकमध्ये असतील, तर काही बाह्य असतील.
Claude कोड आणि वास्तविक-जगातील वापर
MCP च्या यशावर परस्परविरोधी मते आहेत. काहींनी MCP मध्ये समाकलित होणाऱ्या कंपन्यांच्या कथा ऐकल्या आहेत, तर काहींनी ते निराशाजनक वाटल्याचे वापरकर्त्यांकडून ऐकले आहे.
हे hype आणि लवकर स्वीकारण्याचे नुकसान दर्शवते.
काही विकासकांना असे आढळले आहे की बहुतेक वापराच्या प्रकरणांसाठी HTTP API MCP पेक्षा श्रेष्ठ आहेत. ते असा युक्तिवाद करतात की ‘साधन’ वापर क्षमता आणि कार्यक्षमतेसाठी API एंडपॉइंट्सपर्यंत खाली येतो.
API डीफॉल्टनुसार स्व-वर्णनात्मक नाहीत, REST आणि HATEOAS समर्थकांसाठी त्यांचे दृष्टीकोन दर्शविण्यासाठी गमावलेली संधी दर्शवतात.
MCP एक LangChain पर्याय म्हणून?
MCP चे वर्णन ‘LangChain वास’ असे केले गेले आहे – तातडीची समस्या सोडवणे नाही, जास्त अमूर्त असणे आणि त्याचे फायदे समजावून सांगण्यात अडचण येणे.
कदाचित तेथे ‘END OF LINE’ म्हणण्याची आणि wannabe हॅकर्सना गेम ग्रिडमध्ये हद्दपार करण्याची आवश्यकता आहे!
‘सामान्य’ चॅटबॉट प्रतिमान टिकून राहील का हा एक महत्त्वाचा प्रश्न आहे. स्वतःची साधने असलेल्या विशेष ॲप्सना MCP ची आवश्यकता नसू शकते.
याउलट, LLM अधिक सक्षम होत असल्याने, बाह्य साधनांची आवश्यकता कमी होऊ शकते. LLM थेट प्रतिमा संपादित करू शकत असल्यास, Photoshop चालवण्यासाठी तुम्हाला MCP का हवा आहे?
साय-फाय रोबोट सहाय्यकाचे स्वप्न साकार होणार नाही आणि विशेष भाषा हाताळण्याची साधने अधिक उपयुक्त ठरू शकतात.
वापरकर्ता आधार आणि सुरक्षा जागरूकता
MCP च्या वापरकर्त्यांमध्ये कमी-तांत्रिक व्यक्तींचा समावेश आहे, ज्यामुळे सुरक्षा समस्या विशेषतः संबंधित आहेत. सुरक्षा सर्वोत्तम पद्धतींबद्दल जागरूकता वाढवणे महत्त्वाचे आहे.
परिणाम स्कीमा परिभाषित करण्याची आवश्यकता असलेले OpenRPC वर आधारित Xops, इनपुट आउटपुटशी कसे जोडले जातात याचे नियोजन करण्यास मदत करते, जटिल वर्कफ्लोसाठी विश्वासार्हता सुधारते.
तंत्रज्ञान कालांतराने विकसित होण्याची आणि स्थिर होण्याची शक्यता आहे.
रिडंडंसी आणि क्लाउड इन्फ्रास्ट्रक्चर
काहीजण OpenAPI मानकांपेक्षा MCP वापरण्याचे फायदे विचारतात, ते निरर्थक मानतात.
OpenAPI प्रणालीला कॉल करण्यासाठी LLM काय वापरेल? ते शेलला कसे बांधेल? LLM चा होस्ट ते कसे ऑर्केस्ट्रेट करेल?
MCP LLM ला टूल कॉल करण्याचा एक संरचित मार्ग प्रदान करते.
MCP सर्व्हर आधीपासून HTTP सर्व्हर आहेत.
MCP चा सर्वात मोठा फायदा ॲप्लिकेशन डेव्हलपर्सना नव्हे तर OpenAI सारख्या LLM प्रदात्यांना आहे.
LLM हे साधनांशिवाय मेंदू आहेत आणि टूल कॉलिंग त्यांना सक्षम करते. तथापि, सामान्य API सह, LLM प्रदात्यांना त्या साधनांमध्ये प्रवेश नाही. MCP त्यांना ऍक्सेस देते, त्यांना AI चा प्रवेशद्वार म्हणून स्थान देते.
CLI विरुद्ध API
नैसर्गिक भाषेत LLM प्रशिक्षित केले जात असल्याने आणि CLI हे एक सामान्य मानवी-वाचनीय आणि लेखन करण्यायोग्य सोल्यूशन असल्याने CLI थेट का वापरू नये?
MCP खूप लवकर उदयास आले आणि त्याला परिपक्व होण्याची गरज आहे. यात पारंपारिक मानक संस्थेद्वारे छाननीचा अभाव आहे आणि ते hype द्वारे चालविले जाते.
रिअल-वर्ल्ड ऍप्लिकेशन्सचा अभाव आहे.
MCP ची मुख्य ऍप्लिकेशन्स
MCP चा वापर Claude Desktop आणि niche AI चॅट ॲप्स, कोड ऑटोमेशन टूल्स आणि एजंट/LLM ऑटोमेशन फ्रेमवर्कमध्ये केला जातो.
हे आणखी एक घाईघाईने केलेले तंत्रज्ञान आहे जे पुढील hype-able संक्षिप्त शब्द आल्यावर टाकून दिले जाईल.
दोन प्रकारचे भाषा मॉडेल टूल कॉलिंग प्रोटोकॉल आहेत: ज्याबद्दल लोक तक्रार करतात आणि जे कोणीही वापरत नाही.
Anthropic ने हे ‘मानक’ व्हॅक्यूममध्ये विकसित केले, ज्यामुळे सुरक्षा समस्या निर्माण झाल्या.
JSON-RPC 2.0
MCP JSON-RPC 2.0 वर तयार केले आहे, हा एक हलका प्रोटोकॉल आहे जो JSON वापरून क्लायंट आणि सर्व्हर संप्रेषणास अनुमती देतो.
हे विशिष्ट इकोसिस्टमसाठी डिझाइन केलेले केंद्रीकृत वैशिष्ट्यासारखे वाटते, ते मिळवण्याशिवाय सार्वत्रिकतेचा दावा करते.
MCP उपयुक्त गोष्टी करण्यासाठी पुरेसे शक्तिशाली आहे, ज्यामुळे सुरक्षा चिंता वाढतात.
हे एक परिपक्व मानक नाही आणि ते सुरक्षित करण्यासाठी डिझाइन केलेले नाही.
शिफारशी अस्तित्वात असताना, त्या लागू केल्या जात नाहीत किंवा अंमलात आणल्या जात नाहीत.
Langchain आणि टूल कॉलिंग
Langchain हे ‘टूल कॉलिंग’ पॅटर्न अंमलात आणणाऱ्या अनेक फ्रेमवर्कपैकी एक आहे.
MCP हे एक वैशिष्ट्य आहे जे बाह्य माहिती भाषिक मॉडेलच्या संदर्भ विंडोमध्ये कशी प्रवेश करते, ज्यात टूल कॉलिंग, टेम्पलेटेड इनपुट, रद्द करणे, प्रगतीचा मागोवा घेणे आणि टूल सर्व्हरची स्थिती यांचा समावेश आहे.
हे तपशील मानकीकृत करण्यास मदत करते जेणेकरून कोणतीही सहाय्यक/एकत्रीकरण कॉम्बो सुसंगत असेल.
MCP ला कायदेशीर समस्या असल्या तरी, टीकाकारांनी त्यांचे युक्तिवाद परिष्कृत केले पाहिजेत.
प्रमाणीकरण महत्त्वपूर्ण आहे आणि ते प्रारंभिक आवृत्तीतून वगळले जाऊ नये.
खूप जास्त गुंतागुंत आहेत.