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 एप्लिकेशन का एक सॉफ़्टवेयर घटक है। MCP, क्लाइंट को होस्ट या LLM के निर्देशों के आधार पर आंतरिक और बाहरी MCP सर्वर से संचार करने के लिए एक मानक इंटरफ़ेस देता है। इसका काम कनेक्शन स्थापित करना, JSON-RPC संदेशों को फ़ॉर्मैट करना, अनुरोध भेजना और प्रतिक्रियाएँ प्राप्त करना है।

“MCP होस्ट” और “MCP क्लाइंट” शब्दों का इस्तेमाल कभी-कभी एक-दूसरे की जगह किया जाता है। फिर भी यह अंतर उपयोगी है, क्योंकि Perplexity जैसा होस्ट एक ही समय में कई MCP क्लाइंट को ऑर्केस्ट्रेट कर सकता है। किसी जटिल AI वर्कफ़्लो को दर्जनों या सैकड़ों अलग-अलग MCP सर्वर तक पहुँच की ज़रूरत हो सकती है, और हर सर्वर एक अलग कनेक्शन का उपयोग करेगा।

Perplexity जैसे एक MCP होस्ट का आरेख, जो तीन MCP क्लाइंट को ऑर्केस्ट्रेट करता है; हर क्लाइंट अपने MCP सर्वर से जुड़ा है, जैसे डेटाबेस, फ़ाइलें या कोई बाहरी API।

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

MCP सर्वर तीन श्रेणियों के प्रिमिटिव तक पहुँच दे सकते हैं:

टूल: ये मूल रूप से बाहरी सॉफ़्टवेयर कार्यक्षमताएँ हैं। पारंपरिक API-आधारित तरीके में, कोई वेब एनालिटिक्स एप्लिकेशन किसी बाहरी सर्वर को फ़ॉर्मैट किया गया अनुरोध भेजकर डेटा प्राप्त कर सकता है। MCP आर्किटेक्चर में, किसी प्रदाता की सारी थर्ड-पार्टी कार्यक्षमता एक ही कनेक्शन के ज़रिए उपलब्ध होती है, और अनुरोध मानक फ़ॉर्मैटिंग नियमों के अनुसार बनाए जाते हैं।
रिसोर्स: रिसोर्स ऐसे डेटा स्रोत हैं जो केवल-पढ़ने योग्य संदर्भ देते हैं। डेटाबेस स्कीमा इसका अच्छा उदाहरण हैं। MCP सर्वर होस्ट के लिए उपलब्ध विभिन्न सूचना स्रोतों को सामने रखता है। अगर होस्ट डेटाबेस को क्वेरी करता है, जैसे LLM द्वारा बनाई गई SQL खोज के ज़रिए, तो इसे टूल अनुरोध माना जाता है।
प्रॉम्प्ट: ये दोबारा इस्तेमाल किए जा सकने वाले प्रॉम्प्ट टेम्पलेट हैं जो LLM को खास काम करने में मदद करते हैं। कोई उपयोगकर्ता या होस्ट टूल के बजाय प्रॉम्प्ट को तब कॉल करता है जब किसी काम को पूरा करने के लिए पहले से तैयार निर्देशों की ज़रूरत होती है। अक्सर होस्ट एप्लिकेशन में पहले से सेट काम, जैसे “कोड की समीक्षा करें” या “डेटा का विश्लेषण करें” का विकल्प, प्रॉम्प्ट के रूप में सहेजे जाते हैं, जिन्हें उपयोगकर्ता चुन सकता है।

यह भी ध्यान देने लायक है कि MCP और API परस्पर अनन्य तकनीकें नहीं हैं। MCP सर्वर ऐसी API कॉल उपलब्ध करा सकता है जो डिस्कवरी अनुरोध के जवाब में मिलती हैं। मुख्य बात यह है कि इन्हें बनाए रखने की ज़िम्मेदारी 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 टूल कॉल कैसा दिखता है:

टूल डिस्कवरी: नोट्स एप्लिकेशन (होस्ट) अपने MCP क्लाइंट का उपयोग करके tools/list अनुरोध के ज़रिए सर्वर के उपलब्ध टूल माँगता है। सर्वर उनके नाम, विवरण और अपेक्षित इनपुट लौटाता है, जिनमें add-task टूल की जानकारी भी शामिल है। यह आपके प्रॉम्प्ट सबमिट करने से पहले भी हो सकता है।
उपयोगकर्ता इनपुट: आप ऐप में मौजूद चैटबॉट के ज़रिए LLM-आधारित नोट्स एप्लिकेशन को एक अनुरोध सबमिट करते हैं, जैसे, “मेरे कैलेंडर में मध्यम प्राथमिकता के साथ मेरे नए ड्राफ़्ट की समीक्षा करने का एक टास्क बनाओ।”
मॉडल प्रोसेसिंग: होस्ट आपका अनुरोध और संबंधित टूल परिभाषाएँ LLM को भेजता है।
टूल चयन: LLM एक संरचित टूल अनुरोध बनाता है, जिसमें टूल और उसके इनपुट बताए जाते हैं: add-task, साथ में title: ड्राफ़्ट की समीक्षा करें और priority: मध्यम। होस्ट जाँचता है कि इस कार्रवाई की अनुमति है या नहीं और अनुरोध को 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 आर्किटेक्चर का भविष्य क्या है?