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 அறிமுகப்படுத்தியதிலிருந்து, AI பணிப்பாய்வுகளில் MCP கட்டமைப்பு பரவலாகப் பயன்படுத்தப்பட்டு வருகிறது. இதற்கு முக்கியக் காரணம், பல 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 கருவி அழைப்பு எப்படி இருக்கும் என்பது இங்கே:

கருவிக் கண்டறிதல்: குறிப்புகள் பயன்பாடு (ஹோஸ்ட்) ஒரு 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 இணைப்புகளைச் செயல்படுத்துவதிலும் நிர்வகிப்பதிலும் உள்ள அதிகப் பராமரிப்புச் சுமையை இது சமாளிக்கிறது.

ஒவ்வொரு செயல்பாட்டு வழங்குநருக்கும் அல்லது உள் வளத்திற்கும் ஒரே ஒரு இணைப்பை ஹோஸ்ட் பயன்பாட்டிற்கு வழங்குவதன் மூலம், அளவுக்கு மீறிய சூழல் உள்ளீடு (அனைத்து 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 கட்டமைப்பின் அடுத்த கட்டம் என்ன?