MCP ఆర్కిటెక్చర్: రేఖాచిత్రాలతో పూర్తి సాంకేతిక విశ్లేషణ

MCP ఆర్కిటెక్చర్ అనేది MCP (Model Context Protocol)ని సాధ్యం చేసే ప్రాథమిక భాగాలు మరియు కమ్యూనికేషన్ నియమాల సమితి. MCP ఒక ఓపెన్-సోర్స్ ప్రమాణం, మరియు MCP ఆర్కిటెక్చర్ అది నడిచే అంతర్లీన మౌలిక సదుపాయం.

ఏ MCP ఆర్కిటెక్చర్ అయినా మూడు ప్రధాన భాగాలను కలిగి ఉంటుంది, వాటి చుట్టూనే నిర్మించబడుతుంది: హోస్ట్, క్లయింట్ మరియు సర్వర్. MCP కమ్యూనికేషన్ ఫ్రేమ్‌వర్క్‌ను తరచుగా డేటా లేయర్ మరియు ట్రాన్స్‌పోర్ట్ లేయర్‌తో రూపొందినదిగా వివరిస్తారు. డేటా లేయర్ అనేది సందేశాలు ఎలా ఫార్మాట్ చేయబడతాయో నిర్ణయించే నియమాల సమితి (MCP అభ్యర్థనలు JSON-RPC 2.0లో పంపబడతాయి). ట్రాన్స్‌పోర్ట్ లేయర్ ఆ సందేశాలను తీసుకువెళుతుంది, బాహ్య కనెక్షన్‌ల కోసం Streaming HTTPని ఉపయోగిస్తుంది.

MCP ఆర్కిటెక్చర్ అనేది Model Context Protocolను అమలు చేసే సర్వర్ ఫ్రేమ్‌వర్క్. 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 సిస్టమ్‌లో హోస్ట్‌లుగా పనిచేయగలవు.

ఒక సాధారణ వర్క్‌ఫ్లోలో, యూజర్ చాట్ ఇంటర్‌ఫేస్ ద్వారా ఒక ప్రశ్న అడుగుతారు. ఆ తర్వాత హోస్ట్‌లోని ఆర్కెస్ట్రేటర్ భాగం ఆ ప్రశ్నకు కాంటెక్స్ట్‌ను జోడిస్తుంది, ఏ MCP ప్రిమిటివ్‌లు అందుబాటులో ఉన్నాయో వాటి సామర్థ్యాల వివరణతో సహా LLMకు తెలియజేస్తుంది.

క్లయింట్ అనేది 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 టూల్ కాల్ ఎలా ఉంటుందో ఇక్కడ చూడండి:

టూల్ డిస్కవరీ: నోట్స్ అప్లికేషన్ (హోస్ట్) తన MCP క్లయింట్‌ను ఉపయోగించి tools/list అభ్యర్థన ద్వారా సర్వర్‌లో అందుబాటులో ఉన్న టూల్స్‌ను అభ్యర్థిస్తుంది. సర్వర్ వాటి పేర్లు, వివరణలు మరియు అవసరమైన ఇన్‌పుట్‌లను, 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 కనెక్షన్‌లను అమలు చేయడం మరియు నిర్వహించడం వల్ల కలిగే అధిక నిర్వహణ భారాన్ని ఇది అధిగమిస్తుంది.

ప్రతి కార్యాచరణ ప్రొవైడర్ లేదా అంతర్గత రిసోర్స్‌కు హోస్ట్ అప్లికేషన్‌కు ఒకే కనెక్షన్‌ను అందించడం ద్వారా, ఉబ్బిపోయిన కాంటెక్స్ట్ ఇన్‌పుట్ (అన్ని APIలను జాబితా చేయడం) లేదా పరిమిత API-ఆధారిత అప్లికేషన్ స్క్రిప్ట్‌ల సమస్యను పరిష్కరించడంలో MCP సహాయపడుతుంది.

బదులుగా, 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 ఆర్కిటెక్చర్ భవిష్యత్తు ఏమిటి?