MCP आर्किटेक्चर: आकृत्यांसह संपूर्ण तांत्रिक विश्लेषण

MCP आर्किटेक्चर हा घटकांचा आणि संवाद नियमांचा मूलभूत संच आहे, ज्यामुळे MCP (Model Context Protocol) शक्य होते. MCP हे एक ओपन-सोर्स मानक आहे आणि MCP आर्किटेक्चर ही ते ज्यावर चालते ती मूलभूत पायाभूत रचना आहे.

प्रत्येक MCP आर्किटेक्चरमध्ये तीन मुख्य घटक असतात आणि ते त्यांच्याभोवतीच उभारलेले असते: होस्ट, क्लायंट आणि सर्व्हर. MCP च्या संवाद फ्रेमवर्कचे वर्णन अनेकदा डेटा लेयर आणि ट्रान्सपोर्ट लेयर यांनी बनलेले असे केले जाते. डेटा लेयर म्हणजे संदेश कसे फॉरमॅट केले जातात याबद्दलच्या नियमांचा संच (MCP विनंत्या JSON-RPC 2.0 मध्ये पाठवल्या जातात). ट्रान्सपोर्ट लेयर हे संदेश वाहून नेतो आणि बाह्य कनेक्शनसाठी Streaming HTTP वापरतो.

MCP आर्किटेक्चर हे Model Context Protocol अंमलात आणणारे सर्व्हर फ्रेमवर्क आहे. हे एक खुले मानक आहे, जे AI मॉडेल्सना टूल्सशी जोडते, तसेच डेटाबेससारख्या संसाधनांशी आणि इनपुट संदर्भ वाढवणाऱ्या प्रॉम्प्ट्सशीही जोडते. यांना एकत्रितपणे “प्रिमिटिव्ह्ज” म्हणतात. अंतिमतः, MCP आर्किटेक्चरमुळे LLM ना कोणती टूल्स उपलब्ध आहेत हे शोधता येते आणि वर्कफ्लो चालवता येतात, तेही क्लायंटच्या बाजूला नियमित अपडेट्सची आवश्यकता न ठेवता.

MCP आर्किटेक्चरची आकृती: एक AI ॲप्लिकेशन MCP सर्व्हरशी विनंत्यांची देवाणघेवाण करते आणि तो सर्व्हर टूल्स, संसाधने आणि प्रॉम्प्ट्स पुरवतो.

Anthropic ने सादर केल्यापासून MCP आर्किटेक्चर AI वर्कफ्लोमध्ये मोठ्या प्रमाणावर वापरले जात आहे. याचे मुख्य कारण म्हणजे ते कामगिरीशी तडजोड न करता, अनेक API कनेक्शनभोवती उभारलेल्या प्रणालींसारख्या जास्त देखभाल लागणाऱ्या प्रणालींची जागा घेते. सर्व उपलब्ध कार्यक्षमता MCP सर्व्हरच्या मागे असल्यामुळे फक्त एकच कनेक्शन आवश्यक असते आणि अपडेट्स व नवीन भर क्लायंट ॲप्लिकेशनला लगेच उपलब्ध होतात.

MCP मुळे LLM ना होस्ट ॲप्लिकेशनच्या स्थानिक सिस्टमवर किंवा बाह्य प्रदात्याकडून उपलब्ध असलेली टूल्स, प्रॉम्प्ट्स आणि संसाधने शोधण्याचे आणि कॉल करण्याचे साधन मिळते.

बाह्य कार्यक्षमतेचा प्रवेश देणाऱ्या टूल्सच्या बाबतीत, शोध प्रक्रियेत कोणती टूल्स उपलब्ध आहेत हे जाणून घेण्यासाठी होस्ट MCP सर्व्हरला tools/list कॉल करतो. त्यानंतर LLM (किंवा काही बाबतीत होस्ट) उपलब्ध टूल्सची वर्णने वाचू शकतो आणि गरजेनुसार त्यांची विनंती करू शकतो. प्रॉम्प्ट्स आणि संसाधनांसाठीही अशीच प्रक्रिया वापरली जाते.

MCP आर्किटेक्चरच्या घटकांची आकृती: LLM, ऑर्केस्ट्रेटर आणि क्लायंट असलेला होस्ट दोन टप्प्यांत MCP सर्व्हरशी जोडला जातो, आधी शोध आणि नंतर विनंत्या, आणि MCP सर्व्हर टूल्स, संसाधने आणि प्रॉम्प्ट्स उपलब्ध करून देतो.

हे सानुकूल API-आधारित आर्किटेक्चरच्या अगदी उलट आहे, जे सॉफ्टवेअर डेव्हलपमेंटमध्ये रूढ होते. त्यात ॲपबाहेरील कार्यक्षमता अचूक फॉरमॅट केलेल्या विनंत्यांसह समर्पित कनेक्शन वापरून कॉल करावी लागत असे.

होस्ट ॲप्लिकेशन हे केंद्रीय ऑर्केस्ट्रेशन प्लॅटफॉर्म असते आणि ते LLM शी जोडलेले असते. Perplexity आणि Claude Desktop सारखी सुप्रसिद्ध टूल्स MCP सिस्टममध्ये होस्ट म्हणून काम करू शकतात.

साध्या वर्कफ्लोमध्ये वापरकर्ता चॅट इंटरफेसद्वारे प्रश्न विचारतो. त्यानंतर होस्टचा ऑर्केस्ट्रेटर घटक त्या प्रश्नात संदर्भ जोडतो आणि LLM ला कोणते MCP प्रिमिटिव्ह्ज उपलब्ध आहेत, तसेच त्यांच्या क्षमतांचे वर्णन सांगतो.

क्लायंट हा AI ॲप्लिकेशनमधील एक सॉफ्टवेअर घटक आहे. होस्ट किंवा LLM च्या सूचनांनुसार अंतर्गत आणि बाह्य MCP सर्व्हरशी संवाद साधण्यासाठी MCP क्लायंटला एक मानक इंटरफेस देते. कनेक्शन स्थापित करणे, JSON-RPC संदेश फॉरमॅट करणे, विनंत्या पाठवणे आणि प्रतिसाद प्राप्त करणे हे त्याचे काम आहे.

“MCP होस्ट” आणि “MCP क्लायंट” या संज्ञा कधी कधी एकमेकांच्या जागी वापरल्या जातात. तरीही हा फरक उपयुक्त आहे, कारण Perplexity सारखा होस्ट एकाच वेळी अनेक MCP क्लायंट्सचे ऑर्केस्ट्रेशन करू शकतो. गुंतागुंतीच्या AI वर्कफ्लोला डझनभर किंवा अगदी शेकडो वेगवेगळ्या MCP सर्व्हरचा प्रवेश लागू शकतो आणि प्रत्येक सर्व्हरसाठी वेगळे कनेक्शन वापरले जाईल.

Perplexity सारखा MCP होस्ट तीन MCP क्लायंट्सचे ऑर्केस्ट्रेशन करत असल्याची आकृती; प्रत्येक क्लायंट डेटाबेस, फाइल्स किंवा बाह्य API सारख्या स्वतःच्या MCP सर्व्हरशी जोडलेला आहे.

AI-आधारित टूल वापरू शकणारी सर्व टूल्स सर्व्हर उपलब्ध करून देतो. आर्किटेक्चरच्या दृष्टिकोनातून, MCP सर्व्हर येणाऱ्या विनंतीचा अर्थ लावतो आणि गरज असल्यास विनंती केलेल्या प्रिमिटिव्ह्जशी जोडतो.

MCP सर्व्हर तीन प्रकारच्या प्रिमिटिव्ह्जचा प्रवेश देऊ शकतात:

टूल्स: या मूलतः बाह्य सॉफ्टवेअर कार्यक्षमता आहेत. पारंपरिक API-आधारित दृष्टिकोनाचा विचार केला, तर वेब ॲनालिटिक्स ॲप्लिकेशन बाह्य सर्व्हरला फॉरमॅट केलेली विनंती पाठवून डेटा मिळवू शकते. MCP आर्किटेक्चरमध्ये प्रदात्याची सर्व तृतीय-पक्ष कार्यक्षमता एकाच कनेक्शनद्वारे उपलब्ध असते आणि विनंत्या मानक फॉरमॅटिंग नियमांनुसार तयार केल्या जातात.
संसाधने: संसाधने हे केवळ-वाचनीय संदर्भ देणारे डेटा स्रोत आहेत. डेटाबेस स्कीमा हे याचे चांगले उदाहरण आहे. MCP सर्व्हर होस्टला उपलब्ध असलेले विविध माहिती स्रोत उपलब्ध करून देतो. जर होस्टने डेटाबेसवर क्वेरी केली, उदाहरणार्थ LLM ने तयार केलेल्या SQL शोधाद्वारे, तर ती टूल विनंती मानली जाते.
प्रॉम्प्ट्स: हे पुन्हा वापरता येणारे प्रॉम्प्ट टेम्पलेट्स आहेत, जे LLM ना विशिष्ट कामे करण्यास मदत करतात. वापरकर्ता किंवा होस्ट टूलऐवजी प्रॉम्प्ट कॉल करतो, कारण एखादे काम पूर्ण करण्यासाठी तयार सूचनांची आवश्यकता असते. अनेकदा होस्ट ॲप्लिकेशनमधील पूर्वनिर्धारित कामे, जसे की “कोडचे पुनरावलोकन करा” किंवा “डेटाचे विश्लेषण करा” हे पर्याय, प्रॉम्प्ट्स म्हणून साठवलेले असतात आणि वापरकर्ता ते निवडू शकतो.

हेही लक्षात घेण्यासारखे आहे की MCP आणि API ही एकमेकांना वगळणारी तंत्रज्ञाने नाहीत. शोध विनंतीला प्रतिसाद म्हणून उपलब्ध असलेले API कॉल्स MCP सर्व्हर उपलब्ध करून देऊ शकतो. महत्त्वाचे म्हणजे, यांची देखभाल करणे ही क्लायंटची नव्हे, तर MCP प्रदात्याची जबाबदारी असते.

MCP आर्किटेक्चरमधील डेटा लेयर म्हणजे विनंत्या, प्रतिसाद आणि नोटिफिकेशन्स कशा फॉरमॅट केल्या जातात हे ठरवणाऱ्या नियमांचा संच. संदेशांसाठी मानक भाषा JSON-RPC आहे.

प्रत्येक MCP आर्किटेक्चर एका मूलभूत प्रक्रियेचे पालन करते: (1) होस्टकडून इनिशियलायझेशन आणि शोध, (2) MCP सर्व्हरकडून प्रतिसाद आणि (3) होस्टकडून कॉल (कधी कधी तो LLM ठरवते). प्रत्येक टप्पा हा एक स्वतंत्र JSON संदेश असतो.

MCP डेटा लेयरची आकृती: वापरकर्ता होस्ट ॲप्लिकेशनला प्रॉम्प्ट पाठवतो, जिथे LLM हे MCP क्लायंटसोबत काम करते; क्लायंट MCP सर्व्हरला (टूल्स, संसाधने, प्रॉम्प्ट्स) विनंती पाठवतो आणि निकाल प्राप्त करतो, आणि होस्ट वापरकर्त्याला प्रतिसाद परत देतो.

टूल शोध कसा काम करतो ते दोन उदाहरणांमधून पाहूया (ही उदाहरणे संसाधने किंवा प्रॉम्प्ट्सनाही लागू होऊ शकतात):

LLM जनरेशनपूर्वी टूल्स शोधा: होस्ट MCP क्लायंट सुरू करतो, जो tools/list विनंती पाठवतो (MCP सर्व्हरच्या उपलब्ध टूल्सची यादी). जनरेशन प्रक्रियेदरम्यान LLM याचे पुनरावलोकन करते आणि एखादे विशिष्ट टूल, संसाधन किंवा प्रॉम्प्ट आवश्यक आहे का हे ठरवते.
LLM ला शोध चालवण्याचा पर्याय द्या: एजंटिक सिस्टममध्ये होस्ट संदर्भ इनपुटमध्ये search-tools, सारखा शोध पर्याय जोडतो आणि गरज असल्यास LLM शोधाची विनंती करू शकते.

टूल्स, जी बहुतांशी बाह्य ॲप्लिकेशन कार्यक्षमता असतात, सहसा LLM किंवा होस्ट निवडतो. संसाधने आणि प्रॉम्प्ट्सची विनंती सहसा वापरकर्त्याच्या सांगण्यावरून किंवा होस्टकडून केली जाते.

एका काल्पनिक नोट्स ॲप्लिकेशनकडून MCP सर्व्हरला पाठवलेली tools/list विनंती अशी दिसते:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

या उदाहरणात, “id”:101 हे ID वापरून विनंती ओळखते, जेणेकरून क्लायंट प्रतिसाद जुळवू शकेल, आणि “params” फील्डमध्ये क्लायंटबद्दल अतिरिक्त माहिती असते, जसे की क्लायंटचे नाव (notes-app-client) आणि क्षमता.

प्रतिसादात MCP सर्व्हर टूल व्याख्या परत करेल, ज्यात उपलब्ध टूल्सची नावे आणि त्यांच्याशी संबंधित तपशील असतात. उदाहरणार्थ, या यादीत add-task टूल असू शकते, ज्यामुळे नोट्स ॲप्लिकेशनला कनेक्ट केलेल्या टास्क मॅनेजमेंट किंवा कॅलेंडर ॲप्लिकेशनमध्ये टास्क तयार करता येतात आणि प्रत्येक टास्कला शीर्षक व प्राधान्य देता येते.

विनंती अशी दिसू शकते:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

“method” फील्ड MCP सर्व्हरला सांगते की हा टूल कॉल आहे, “name” कोणते टूल कॉल करायचे ते निर्दिष्ट करते आणि “arguments” आवश्यक इनपुट्स पुरवते.

क्लायंट आणि MCP सर्व्हर यांच्यातील कनेक्शनचे काय म्हणजे डेटा लेयर असेल, तर कसे म्हणजे ट्रान्सपोर्ट लेयर. संदेश कोणत्या पद्धतीने प्रवास करतात हे तो ठरवतो: विशिष्ट चॅनेल आणि विनंत्या व प्रतिसाद कसे पोहोचवले जातात हे नियंत्रित करणारे नियम.

MCP मध्ये दोन ट्रान्सपोर्ट मार्ग आहेत:

स्टँडर्ड इनपुट/आउटपुट: MCP सर्व्हर होस्ट ॲपच्याच स्थानिक वातावरणात चालतो तेव्हा हे वापरले जाते. क्लायंट JSON विनंती सर्व्हरच्या स्टँडर्ड इनपुटवर लिहितो. सर्व्हर ती वाचतो, विनंती केलेली क्रिया करतो आणि प्रतिसाद स्टँडर्ड आउटपुटवर लिहितो.
Streamable HTTP: MCP सर्व्हर होस्ट ॲप्लिकेशनच्या बाहेर चालतो तेव्हा MCP क्लायंट HTTP POST वापरून सर्व्हरला विनंत्या पाठवतो. सर्व्हर एकाच JSON संदेशाने किंवा Server-Sent Events (SSE) स्ट्रीमने प्रतिसाद देतो. हा स्ट्रीम एक सतत “ऐकणारा” चॅनेल असतो, ज्यामुळे सर्व्हरला कालांतराने अनेक संदेश परत पाठवता येतात.

MCP मल्टी-टेनंट आर्किटेक्चर हा अंमलबजावणीचा असा प्रकार आहे, जो एकाच वेळी अनेक वापरकर्त्यांना (टेनंट्स) सेवा देऊ शकतो.

येथे टेनंट म्हणजे एखादी व्यक्ती, व्यक्तींचा गट किंवा संस्था असू शकते. अंमलबजावणीत प्रत्येक टेनंटसाठी स्वतंत्र MCP सर्व्हर चालवणे, एकाच सामायिक सर्व्हरचा प्रवेश देणे किंवा सर्व्हरचा संच केंद्रीय गेटवेच्या मागे ठेवणे यांचा समावेश असू शकतो. गेटवे वापरला जातो तेव्हा तो वापरकर्त्याच्या ओळखीनुसार किंवा विनंतीच्या स्वरूपानुसार विनंत्या योग्य एंडपॉइंट्सकडे पाठवतो.

हे मानक MCP आर्किटेक्चरच्याच मूलभूत तत्त्वावर काम करते, पण वैयक्तिक वापरकर्त्यांच्या विनंत्या त्यांच्या स्वतःच्या वर्कस्पेसमध्ये चालतात (त्यात सामायिक संसाधने असली तरीही) आणि त्यांचे प्रमाणीकरण स्वतंत्रपणे केले जाते. एंटरप्राइझ परिस्थितींमध्ये हे सामान्य आहे आणि अनेकदा सामायिक संसाधनांना प्राधान्य दिले जाते, कारण अनेक MCP सर्व्हर चालवणे अनावश्यकपणे खर्चिक ठरेल.

प्रत्यक्षात एंड-टू-एंड MCP विनंती कशी दिसते? यात आठ मुख्य टप्पे असतात आणि प्रत्येक टप्प्यात आर्किटेक्चरचा वेगळा घटक सहभागी असतो.

एंड-टू-एंड MCP विनंतीचा आठ टप्प्यांतील फ्लोचार्ट: टूल शोध, वापरकर्ता इनपुट, मॉडेल प्रोसेसिंग, टूल निवड, विनंती, टूल अंमलबजावणी, निकाल आणि उत्तर निर्मिती.

टास्क मॅनेजमेंट सेवेशी जोडलेल्या नोट्स ॲप्लिकेशनचे आधीचे उदाहरण वापरून, प्रत्यक्षात MCP टूल कॉल कसा दिसतो ते येथे पाहूया:

टूल शोध: नोट्स ॲप्लिकेशन (होस्ट) tools/list विनंतीद्वारे सर्व्हरची उपलब्ध टूल्स मागवण्यासाठी आपला MCP क्लायंट वापरते. सर्व्हर त्यांची नावे, वर्णने आणि अपेक्षित इनपुट्स परत करतो, ज्यात add-task टूलच्या तपशिलांचाही समावेश असतो. तुम्ही प्रॉम्प्ट सबमिट करण्यापूर्वीच हे होऊ शकते.
वापरकर्ता इनपुट: तुम्ही ॲपमधील चॅटबॉटद्वारे LLM-आधारित नोट्स ॲप्लिकेशनला विनंती सबमिट करता, उदाहरणार्थ, “माझ्या नवीन मसुद्याचे पुनरावलोकन करण्यासाठी माझ्या कॅलेंडरमध्ये मध्यम प्राधान्याचा टास्क तयार करा.”
मॉडेल प्रोसेसिंग: होस्ट तुमची विनंती आणि संबंधित टूल व्याख्या LLM कडे पाठवतो.
टूल निवड: LLM टूल आणि त्याचे इनपुट्स निर्दिष्ट करणारी संरचित टूल विनंती तयार करते: add-task, ज्यात title: Review the draft आणि priority: Medium आहेत. होस्ट ही क्रिया परवानगीयोग्य आहे का ते तपासतो आणि विनंती MCP क्लायंटकडे पाठवतो, जो JSON-RPC संदेश पाठवतो.
विनंती: MCP क्लायंट आपल्या MCP सर्व्हरला tools/call विनंती पाठवतो.
टूल अंमलबजावणी: निर्दिष्ट शीर्षक आणि प्राधान्यासह नवीन टास्क तयार करण्यासाठी MCP सर्व्हर टास्क मॅनेजमेंट ॲप्लिकेशनचा API कॉल करतो.
निकाल परत करणे: सर्व्हर निकाल MCP क्लायंटकडे परत पाठवतो आणि क्लायंट तो होस्टकडे देतो. होस्ट तो LLM ला पुरवलेल्या माहितीत जोडतो.
उत्तर निर्मिती: LLM निकालाचा वापर करून वापरकर्त्यासाठी उत्तर तयार करते, उदाहरणार्थ “मसुद्याचे पुनरावलोकन करण्यासाठी मी मध्यम प्राधान्याचा टास्क तयार केला आहे.”

MCP आणि पारंपरिक API आर्किटेक्चर यांच्यात अनेकदा गोंधळ होतो, पण ही परस्परपूरक तंत्रज्ञाने आहेत. MCP खास AI-आधारित ॲप्लिकेशन्ससाठी डिझाइन केले गेले. अनेक हार्ड-कोडेड API कनेक्शन अंमलात आणण्याचा आणि व्यवस्थापित करण्याचा देखभालीचा मोठा भार ते दूर करते.

प्रत्येक कार्यक्षमता प्रदाता किंवा अंतर्गत संसाधनासाठी होस्ट ॲप्लिकेशनला एकच कनेक्शन देऊन, MCP फुगलेल्या संदर्भ इनपुटची (सर्व API ची यादी) किंवा मर्यादित API-आधारित ॲप्लिकेशन स्क्रिप्ट्सची समस्या सोडवण्यास मदत करते.

त्याऐवजी MCP त्यांच्या टूल सूचीचा भाग म्हणून API (किंवा अधिक नेमके सांगायचे तर API कॉल करणारी कार्यक्षमता) उपलब्ध करून देऊ शकतात. प्रदाता जेव्हा आपले ॲप अपडेट करतो आणि नवीन API येतो, किंवा दस्तऐवजीकरण बदलते, तेव्हा तो फक्त MCP सर्व्हर अपडेट करतो. होस्ट ॲपच्या बाजूला कोडमध्ये कोणतेही बदल करावे लागत नाहीत.

MCP सुरक्षा हा त्याच्या आगमनापासून बराच चर्चेचा विषय राहिला आहे. सामान्यतः हे सुरक्षित तंत्रज्ञान मानले जात असले, तरी त्यात अनेक सुरक्षा धोके आहेत आणि त्यांपैकी बरेच गुंतागुंतीच्या आर्किटेक्चर अंमलबजावणीत अधिक ठळकपणे दिसतात.

MCP आर्किटेक्चरमध्ये पुढील संभाव्य कमकुवत बाजू आहेत:

प्रॉम्प्ट इंजेक्शन: वापरकर्ता बाह्य डेटामध्ये असा दुर्भावनापूर्ण प्रॉम्प्ट घालतो, ज्याचा AI मॉडेल सूचना म्हणून चुकीचा अर्थ लावते.
अतिरिक्त विशेषाधिकार असलेला प्रवेश: MCP सर्व्हर AI मॉडेलला मोठ्या संख्येने टूल्स उपलब्ध करून देऊ शकतात, ज्यामुळे सुरक्षा समस्यांची शक्यता (ब्लास्ट रेडियस) वाढू शकते.
अपघाती डेटा लीक: चुकीच्या पद्धतीने कॉन्फिगर केलेल्या अंमलबजावणीमुळे API की किंवा डेटाबेस क्रेडेन्शियल्ससारखी संवेदनशील माहिती LLM पर्यंत पोहोचू शकते.
स्थानिक सिस्टममध्ये फेरफार: स्थानिक MCP सर्व्हर इतर कोणत्याही ॲप्लिकेशनप्रमाणेच दुर्भावनापूर्ण स्क्रिप्ट्ससारख्या स्थानिक सिस्टम समस्यांसमोर तितकेच असुरक्षित असतात. शिवाय, त्यांचे एजंटिक AI सिस्टमवर पुढे हानिकारक परिणाम होऊ शकतात.

यांपैकी कोणतीही समस्या दूर न करता येण्यासारखी नाही. अनेकदा सिस्टमची सुरक्षितता सुनिश्चित करण्यासाठी प्रस्थापित उपाययोजना पुरेशा असतात. प्रक्रियेत मानवी सहभाग ठेवणे, संवेदनशील डेटाभोवती कडक नियंत्रणे लागू करणे आणि सर्व्हर हल्ल्यांपासून संरक्षण करणे या सर्व सामान्य पद्धती आहेत.

MCP हे डेव्हलपर्ससाठी उपयुक्त आणि लोकप्रिय खुले मानक असल्याचे सिद्ध झाले आहे. LLM-आधारित ॲप्लिकेशन्समधील हार्ड-कोडेड API च्या अनेक समस्या ते दूर करते आणि डेव्हलपर्सवरील कोडिंगचा भार लक्षणीयरीत्या कमी करते.

पुढील काळात MCP चे मूलभूत होस्ट आणि सर्व्हर आर्किटेक्चर जवळजवळ निश्चितपणे तसेच राहील. भविष्यातील नवकल्पना बहु-टप्पी वर्कफ्लोमधील प्रगत एजंटिक क्षमतांवर केंद्रित असतील.

याशिवाय, एजंटिक कार्यक्षमता अंमलात आणल्या जात असताना अधिक मजबूत सुरक्षा उपायांची गरज भासेल, आणि AI सिस्टम अधिक व्यापक व गुंतागुंतीच्या होत असताना, विशेषतः ट्रान्सपोर्ट लेयरमध्ये, स्केलेबल आर्किटेक्चरचीही गरज भासेल.

MCP आर्किटेक्चर म्हणजे काय?

MCP आर्किटेक्चरचे घटक: होस्ट, क्लायंट आणि सर्व्हर

होस्ट

क्लायंट

सर्व्हर

MCP आर्किटेक्चरमधील डेटा लेयर म्हणजे काय?

MCP आर्किटेक्चरमधील ट्रान्सपोर्ट लेयर म्हणजे काय?

MCP मल्टी-टेनंट आर्किटेक्चर म्हणजे काय?

MCP आर्किटेक्चर आकृती: टप्प्याटप्प्याने मार्गदर्शन

MCP आर्किटेक्चर पारंपरिक API आर्किटेक्चरपेक्षा कसे वेगळे आहे?

MCP आर्किटेक्चर सुरक्षित आहे का?

MCP आर्किटेक्चरचे भविष्य काय आहे?