MCP ആർക്കിടെക്ചർ: ഡയഗ്രങ്ങൾ സഹിതമുള്ള സമ്പൂർണ്ണ സാങ്കേതിക വിശകലനം

ഹോസ്റ്റുകൾ, ക്ലയന്റുകൾ, സെർവറുകൾ, JSON-RPC ഡാറ്റാ ലെയർ, ട്രാൻസ്പോർട്ട് ഓപ്ഷനുകൾ, മൾട്ടി-ടെനന്റ് സജ്ജീകരണങ്ങൾ, സുരക്ഷാ അപകടസാധ്യതകൾ, ഡയഗ്രങ്ങൾ സഹിതമുള്ള എട്ട് ഘട്ട അഭ്യർത്ഥനാ വിശദീകരണം എന്നിവ ഉൾക്കൊള്ളുന്ന MCP ആർക്കിടെക്ചറിന്റെ സാങ്കേതിക വിശകലനം.

Diagram of MCP architecture: an AI application exchanges requests with an MCP server, which provides tools, resources, and prompts.

MCP ആർക്കിടെക്ചർ എന്നത് MCP (Model Context Protocol) സാധ്യമാക്കുന്ന ഘടകങ്ങളുടെയും ആശയവിനിമയ നിയമങ്ങളുടെയും അടിസ്ഥാന കൂട്ടമാണ്. MCP ഒരു ഓപ്പൺ സോഴ്സ് സ്റ്റാൻഡേർഡാണ്, അത് പ്രവർത്തിക്കുന്ന അടിസ്ഥാന ഇൻഫ്രാസ്ട്രക്ചറാണ് MCP ആർക്കിടെക്ചർ.

ഏതൊരു MCP ആർക്കിടെക്ചറിലും മൂന്ന് പ്രധാന ഘടകങ്ങൾ ഉൾപ്പെടുന്നു, അവയെ അടിസ്ഥാനമാക്കിയാണ് അത് നിർമ്മിച്ചിരിക്കുന്നതും: ഒരു ഹോസ്റ്റ്, ഒരു ക്ലയന്റ്, ഒരു സെർവർ. MCP-യുടെ ആശയവിനിമയ ചട്ടക്കൂട് ഒരു ഡാറ്റാ ലെയറും ഒരു ട്രാൻസ്പോർട്ട് ലെയറും ചേർന്നതാണെന്ന് പലപ്പോഴും വിവരിക്കപ്പെടുന്നു. സന്ദേശങ്ങൾ എങ്ങനെ ഫോർമാറ്റ് ചെയ്യണമെന്നതിനുള്ള നിയമങ്ങളുടെ കൂട്ടമാണ് ഡാറ്റാ ലെയർ (MCP അഭ്യർത്ഥനകൾ JSON-RPC 2.0-ലാണ് അയയ്ക്കുന്നത്). ട്രാൻസ്പോർട്ട് ലെയർ ആ സന്ദേശങ്ങൾ കൈമാറുന്നു, ബാഹ്യ കണക്ഷനുകൾക്കായി Streaming HTTP ഉപയോഗിക്കുന്നു.

എന്താണ് MCP ആർക്കിടെക്ചർ?

MCP ആർക്കിടെക്ചർ എന്നത് Model Context Protocol നടപ്പിലാക്കുന്ന ഒരു സെർവർ ചട്ടക്കൂടാണ്. AI മോഡലുകളെ ടൂളുകളുമായി, ഡാറ്റാബേസുകൾ പോലുള്ള റിസോഴ്സുകളുമായി, ഇൻപുട്ട് കോൺടെക്സ്റ്റ് വിപുലീകരിക്കുന്ന പ്രോംപ്റ്റുകളുമായി ബന്ധിപ്പിക്കുന്നതിനുള്ള ഒരു ഓപ്പൺ സ്റ്റാൻഡേർഡാണ് ഈ പ്രോട്ടോക്കോൾ. ഇവയെ മൊത്തത്തിൽ “പ്രിമിറ്റീവുകൾ” എന്ന് വിളിക്കുന്നു. ആത്യന്തികമായി, ക്ലയന്റ് ഭാഗത്ത് പതിവ് അപ്‌ഡേറ്റുകൾ ആവശ്യമില്ലാതെ തന്നെ, ലഭ്യമായ ടൂളുകൾ ഏതൊക്കെയെന്ന് കണ്ടെത്താനും വർക്ക്ഫ്ലോകൾ നിർവ്വഹിക്കാനും MCP ആർക്കിടെക്ചർ LLM-കളെ അനുവദിക്കുന്നു.

Anthropic അവതരിപ്പിച്ചതുമുതൽ, AI വർക്ക്ഫ്ലോകളിൽ MCP ആർക്കിടെക്ചർ വ്യാപകമായി ഉപയോഗിക്കപ്പെടുന്നു. പ്രകടനത്തിൽ വിട്ടുവീഴ്ച ചെയ്യാതെ, ഒന്നിലധികം API കണക്ഷനുകളെ അടിസ്ഥാനമാക്കി നിർമ്മിച്ചവ പോലുള്ള, കൂടുതൽ പരിപാലനം ആവശ്യമുള്ള സിസ്റ്റങ്ങളെ ഇത് മാറ്റിസ്ഥാപിക്കുന്നു എന്നതാണ് ഇതിന് പ്രധാന കാരണം. ലഭ്യമായ എല്ലാ പ്രവർത്തനക്ഷമതയും MCP സെർവറിന് പിന്നിലായതിനാൽ, ഒരു കണക്ഷൻ മാത്രമേ ആവശ്യമുള്ളൂ, കൂടാതെ അപ്‌ഡേറ്റുകളും കൂട്ടിച്ചേർക്കലുകളും ക്ലയന്റ് ആപ്ലിക്കേഷന് ഉടനടി ലഭ്യമാകുന്നു.

MCP ആർക്കിടെക്ചർ ഘടകങ്ങൾ: ഹോസ്റ്റുകൾ, ക്ലയന്റുകൾ, സെർവറുകൾ

ഹോസ്റ്റ് ആപ്ലിക്കേഷന്റെ ലോക്കൽ സിസ്റ്റത്തിലോ ഒരു ബാഹ്യ ദാതാവിൽ നിന്നോ തങ്ങൾക്ക് ലഭ്യമായ ടൂളുകൾ, പ്രോംപ്റ്റുകൾ, റിസോഴ്സുകൾ എന്നിവ കണ്ടെത്താനും വിളിക്കാനുമുള്ള ഒരു മാർഗ്ഗം MCP, LLM-കൾക്ക് നൽകുന്നു.

ബാഹ്യ പ്രവർത്തനക്ഷമതയിലേക്ക് ആക്‌സസ് നൽകുന്ന ടൂളുകളുടെ കാര്യത്തിൽ, ഡിസ്കവറി എന്നാൽ ഏതൊക്കെ ടൂളുകൾ ലഭ്യമാണെന്ന് കണ്ടെത്താൻ ഹോസ്റ്റ് MCP സെർവറിലേക്ക് ഒരു tools/list കോൾ നടത്തുന്നതാണ്. തുടർന്ന് LLM-ന് (അല്ലെങ്കിൽ ചില സന്ദർഭങ്ങളിൽ ഹോസ്റ്റിന്) ലഭ്യമായ ടൂളുകളുടെ വിവരണങ്ങൾ വായിക്കാനും ആവശ്യാനുസരണം അവ അഭ്യർത്ഥിക്കാനും കഴിയും. പ്രോംപ്റ്റുകളും റിസോഴ്സുകളും സമാനമായ ഒരു പ്രക്രിയ ഉപയോഗിക്കുന്നു.

സോഫ്റ്റ്‌വെയർ വികസനത്തിൽ ഇതുവരെ സാധാരണമായിരുന്ന, പ്രത്യേകം തയ്യാറാക്കിയ API അധിഷ്ഠിത ആർക്കിടെക്ചറിൽ നിന്ന് ഇത് വ്യത്യസ്തമാണ്; അവിടെ ആപ്പിന് പുറത്തുള്ള പ്രവർത്തനക്ഷമത, കൃത്യമായി ഫോർമാറ്റ് ചെയ്ത അഭ്യർത്ഥനകളോടെ പ്രത്യേക കണക്ഷനുകൾ ഉപയോഗിച്ച് വിളിക്കേണ്ടിയിരുന്നു.

ഹോസ്റ്റ്

ഹോസ്റ്റ് ആപ്ലിക്കേഷനാണ് കേന്ദ്ര ഓർക്കസ്ട്രേഷൻ പ്ലാറ്റ്‌ഫോം, അത് ഒരു LLM-മായി ബന്ധിപ്പിക്കുന്നു. Perplexity, Claude Desktop പോലുള്ള അറിയപ്പെടുന്ന ടൂളുകൾക്ക് ഒരു MCP സിസ്റ്റത്തിനുള്ളിൽ ഹോസ്റ്റുകളായി പ്രവർത്തിക്കാൻ കഴിയും.

ഒരു ലളിതമായ വർക്ക്ഫ്ലോയിൽ, ഉപയോക്താവ് ചാറ്റ് ഇന്റർഫേസ് വഴി ഒരു ചോദ്യം ചോദിക്കുന്നു. തുടർന്ന് ഹോസ്റ്റിന്റെ ഓർക്കസ്ട്രേറ്റർ ഘടകം ചോദ്യത്തിലേക്ക് കോൺടെക്സ്റ്റ് ചേർക്കുന്നു, ഏതൊക്കെ MCP പ്രിമിറ്റീവുകൾ ലഭ്യമാണെന്നും അവയുടെ കഴിവുകളുടെ വിവരണവും LLM-നെ അറിയിക്കുന്നു.

ക്ലയന്റ്

AI ആപ്ലിക്കേഷനിലെ ഒരു സോഫ്റ്റ്‌വെയർ ഘടകമാണ് ക്ലയന്റ്. ഹോസ്റ്റിന്റെയോ LLM-ന്റെയോ നിർദ്ദേശങ്ങളുടെ അടിസ്ഥാനത്തിൽ ആന്തരികവും ബാഹ്യവുമായ MCP സെർവറുകളുമായി ആശയവിനിമയം നടത്താൻ ക്ലയന്റിന് MCP ഒരു സ്റ്റാൻഡേർഡ് ഇന്റർഫേസ് നൽകുന്നു. ഒരു കണക്ഷൻ സ്ഥാപിക്കുക, JSON-RPC സന്ദേശങ്ങൾ ഫോർമാറ്റ് ചെയ്യുക, അഭ്യർത്ഥനകൾ അയയ്ക്കുക, പ്രതികരണങ്ങൾ സ്വീകരിക്കുക എന്നിവയാണ് അതിന്റെ ജോലി.

“MCP ഹോസ്റ്റ്”, “MCP ക്ലയന്റ്” എന്നീ പദങ്ങൾ ചിലപ്പോൾ പരസ്പരം മാറ്റി ഉപയോഗിക്കാറുണ്ട്. എന്നിരുന്നാലും, ഇതൊരു ഉപയോഗപ്രദമായ വേർതിരിവാണ്, കാരണം Perplexity പോലുള്ള ഒരു ഹോസ്റ്റ് ഒരേസമയം ഒന്നിലധികം MCP ക്ലയന്റുകളെ ഓർക്കസ്ട്രേറ്റ് ചെയ്തേക്കാം. സങ്കീർണ്ണമായ ഒരു AI വർക്ക്ഫ്ലോയ്ക്ക് ഡസൻ കണക്കിനോ നൂറുകണക്കിനോ വെവ്വേറെ MCP സെർവറുകളിലേക്ക് ആക്‌സസ് ആവശ്യമായി വന്നേക്കാം, അവ ഓരോന്നും പ്രത്യേക കണക്ഷൻ ഉപയോഗിക്കും.

സെർവർ

AI അധിഷ്ഠിത ടൂളിന് ഉപയോഗിക്കാനാകുന്ന എല്ലാ ടൂളുകളും സെർവർ ലഭ്യമാക്കുന്നു. ആർക്കിടെക്ചറൽ വീക്ഷണകോണിൽ നിന്ന്, MCP സെർവർ വരുന്ന അഭ്യർത്ഥന വ്യാഖ്യാനിക്കുകയും ആവശ്യമുള്ളപ്പോൾ അഭ്യർത്ഥിച്ച പ്രിമിറ്റീവുകളുമായി ബന്ധിപ്പിക്കുകയും ചെയ്യുന്നു.

MCP സെർവറുകൾക്ക് മൂന്ന് വിഭാഗം പ്രിമിറ്റീവുകളിലേക്ക് ആക്‌സസ് നൽകാൻ കഴിയും:

  • ടൂളുകൾ: ഇവ അടിസ്ഥാനപരമായി ബാഹ്യ സോഫ്റ്റ്‌വെയർ പ്രവർത്തനക്ഷമതകളാണ്. ഒരു പരമ്പരാഗത API അധിഷ്ഠിത സമീപനം പരിഗണിക്കുകയാണെങ്കിൽ, ഒരു വെബ് അനലിറ്റിക്സ് ആപ്ലിക്കേഷൻ ഒരു ബാഹ്യ സെർവറിലേക്കുള്ള ഫോർമാറ്റ് ചെയ്ത അഭ്യർത്ഥന ഉപയോഗിച്ച് ഡാറ്റ വീണ്ടെടുത്തേക്കാം. MCP ആർക്കിടെക്ചറിൽ, ഒരു ദാതാവിൽ നിന്നുള്ള എല്ലാ മൂന്നാം കക്ഷി പ്രവർത്തനക്ഷമതയും ഒരൊറ്റ കണക്ഷൻ വഴി ലഭ്യമാണ്, കൂടാതെ അഭ്യർത്ഥനകൾ സ്റ്റാൻഡേർഡ് ഫോർമാറ്റിംഗ് നിയമങ്ങൾ അനുസരിച്ച് സൃഷ്ടിക്കപ്പെടുന്നു.
  • റിസോഴ്സുകൾ: റീഡ്-ഒൺലി കോൺടെക്സ്റ്റ് നൽകുന്ന ഡാറ്റാ ഉറവിടങ്ങളാണ് റിസോഴ്സുകൾ. ഡാറ്റാബേസ് സ്കീമകൾ ഇതിനൊരു നല്ല ഉദാഹരണമാണ്. ഹോസ്റ്റിന് ലഭ്യമായ വിവിധ വിവര ഉറവിടങ്ങൾ MCP സെർവർ ലഭ്യമാക്കുന്നു. LLM സൃഷ്ടിച്ച ഒരു SQL തിരയൽ പോലെ, ഹോസ്റ്റ് ഡാറ്റാബേസിൽ ക്വറി ചെയ്യുകയാണെങ്കിൽ, അത് ഒരു ടൂൾ അഭ്യർത്ഥനയായി കണക്കാക്കപ്പെടുന്നു.
  • പ്രോംപ്റ്റുകൾ: നിർദ്ദിഷ്ട ടാസ്‌ക്കുകൾ നിർവ്വഹിക്കാൻ LLM-കളെ സഹായിക്കുന്ന, വീണ്ടും ഉപയോഗിക്കാവുന്ന പ്രോംപ്റ്റ് ടെംപ്ലേറ്റുകളാണ് ഇവ. ഒരു ടാസ്‌ക് പൂർത്തിയാക്കാൻ മുൻകൂട്ടി തയ്യാറാക്കിയ നിർദ്ദേശങ്ങൾ ആവശ്യമുള്ളതിനാൽ, ഒരു ഉപയോക്താവോ ഹോസ്റ്റോ ഒരു ടൂളിന് പകരം ഒരു പ്രോംപ്റ്റ് വിളിക്കും. പലപ്പോഴും, “കോഡ് അവലോകനം ചെയ്യുക” അല്ലെങ്കിൽ “ഡാറ്റ വിശകലനം ചെയ്യുക” പോലുള്ള ഓപ്ഷനുകൾ പോലെ, ഒരു ഹോസ്റ്റ് ആപ്ലിക്കേഷനിലെ മുൻകൂട്ടി സജ്ജമാക്കിയ ടാസ്‌ക്കുകൾ ഉപയോക്താവിന് തിരഞ്ഞെടുക്കാവുന്ന പ്രോംപ്റ്റുകളായി സംഭരിക്കപ്പെടുന്നു.

MCP-യും API-യും പരസ്പരം ഒഴിവാക്കുന്ന സാങ്കേതികവിദ്യകളല്ല എന്നതും ശ്രദ്ധിക്കേണ്ടതാണ്. ഒരു ഡിസ്കവറി അഭ്യർത്ഥനയ്ക്കുള്ള പ്രതികരണമായി ലഭ്യമായ API കോളുകൾ MCP സെർവർ ലഭ്യമാക്കിയേക്കാം. ഇവ പരിപാലിക്കേണ്ടത് ക്ലയന്റല്ല, MCP ദാതാവാണ് എന്നതാണ് പ്രധാനം.

MCP ആർക്കിടെക്ചറിലെ ഡാറ്റാ ലെയർ എന്താണ്?

അഭ്യർത്ഥനകൾ, പ്രതികരണങ്ങൾ, അറിയിപ്പുകൾ എന്നിവ എങ്ങനെ ഫോർമാറ്റ് ചെയ്യണമെന്ന് നിർവചിക്കുന്ന നിയമങ്ങളുടെ കൂട്ടമാണ് MCP ആർക്കിടെക്ചറിലെ ഡാറ്റാ ലെയർ. സന്ദേശങ്ങൾക്കുള്ള സ്റ്റാൻഡേർഡ് ഭാഷ JSON-RPC ആണ്.

എല്ലാ MCP ആർക്കിടെക്ചറും ഒരു അടിസ്ഥാന പ്രക്രിയ പിന്തുടരുന്നു: (1) ഹോസ്റ്റിന്റെ ഇനിഷ്യലൈസേഷനും ഡിസ്കവറിയും, (2) MCP സെർവറിന്റെ പ്രതികരണം, (3) ഹോസ്റ്റിന്റെ ഒരു കോൾ (ചിലപ്പോൾ LLM തീരുമാനിക്കുന്നത്); ഓരോ ഘട്ടവും ഒരു പ്രത്യേക JSON സന്ദേശത്തെ പ്രതിനിധീകരിക്കുന്നു.

ടൂൾ ഡിസ്കവറി എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് രണ്ട് ഉദാഹരണങ്ങളിലൂടെ നോക്കാം (ഇവ റിസോഴ്സുകൾക്കും പ്രോംപ്റ്റുകൾക്കും ബാധകമാകാം):

  • 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-ക്ക് രണ്ട് ട്രാൻസ്പോർട്ട് പാതകളുണ്ട്:

  • സ്റ്റാൻഡേർഡ് ഇൻപുട്ട്/ഔട്ട്പുട്ട്: ഹോസ്റ്റ് ആപ്പിന്റെ അതേ ലോക്കൽ എൻവയോൺമെന്റിൽ MCP സെർവർ പ്രവർത്തിക്കുമ്പോഴാണ് ഇത് ഉപയോഗിക്കുന്നത്. ക്ലയന്റ് JSON അഭ്യർത്ഥന സെർവറിന്റെ സ്റ്റാൻഡേർഡ് ഇൻപുട്ടിലേക്ക് എഴുതുന്നു. സെർവർ അത് വായിക്കുകയും അഭ്യർത്ഥിച്ച പ്രവർത്തനം നിർവ്വഹിക്കുകയും പ്രതികരണം സ്റ്റാൻഡേർഡ് ഔട്ട്പുട്ടിലേക്ക് എഴുതുകയും ചെയ്യുന്നു.
  • Streamable HTTP: ഹോസ്റ്റ് ആപ്ലിക്കേഷന് പുറത്ത് MCP സെർവർ പ്രവർത്തിക്കുമ്പോൾ, MCP ക്ലയന്റ് HTTP POST ഉപയോഗിച്ച് സെർവറിലേക്ക് അഭ്യർത്ഥനകൾ അയയ്ക്കുന്നു. സെർവർ ഒന്നുകിൽ ഒരൊറ്റ JSON സന്ദേശം ഉപയോഗിച്ചോ അല്ലെങ്കിൽ ഒരു Server-Sent Events (SSE) സ്ട്രീം ഉപയോഗിച്ചോ പ്രതികരിക്കുന്നു; കാലക്രമേണ ഒന്നിലധികം സന്ദേശങ്ങൾ തിരികെ നൽകാൻ സെർവറിനെ അനുവദിക്കുന്ന, സ്ഥിരമായ ഒരു “ലിസണിംഗ്” ചാനലാണിത്.

എന്താണ് MCP മൾട്ടി-ടെനന്റ് ആർക്കിടെക്ചർ?

ഒന്നിലധികം ഉപയോക്താക്കൾക്ക് (ടെനന്റുകൾക്ക്) ഒരേസമയം സേവനം നൽകാൻ കഴിയുന്ന ഒരു തരം നടപ്പാക്കലാണ് MCP മൾട്ടി-ടെനന്റ് ആർക്കിടെക്ചർ.

ഇവിടെ, ഒരു ടെനന്റ് ഒരു വ്യക്തിയോ, ഒരു കൂട്ടം വ്യക്തികളോ, അല്ലെങ്കിൽ ഒരു സ്ഥാപനമോ ആകാം. ഓരോ ടെനന്റിനും പ്രത്യേക MCP സെർവർ പ്രവർത്തിപ്പിക്കുക, പങ്കിട്ട ഒരൊറ്റ സെർവറിലേക്ക് ആക്‌സസ് നൽകുക, അല്ലെങ്കിൽ ഒരു കേന്ദ്ര ഗേറ്റ്‌വേയ്ക്ക് പിന്നിൽ ഒരു കൂട്ടം സെർവറുകൾ സ്ഥാപിക്കുക എന്നിവ നടപ്പാക്കലിൽ ഉൾപ്പെടാം. ഒരു ഗേറ്റ്‌വേ ഉപയോഗിക്കുമ്പോൾ, ഉപയോക്താവിന്റെ ഐഡന്റിറ്റി അല്ലെങ്കിൽ അഭ്യർത്ഥനയുടെ സ്വഭാവം അടിസ്ഥാനമാക്കി അത് അഭ്യർത്ഥനകളെ ശരിയായ എൻഡ്‌പോയിന്റുകളിലേക്ക് റൂട്ട് ചെയ്യുന്നു.

ഇത് സ്റ്റാൻഡേർഡ് MCP ആർക്കിടെക്ചറിന്റെ അതേ അടിസ്ഥാന തത്വത്തിലാണ് പ്രവർത്തിക്കുന്നത്, എന്നാൽ ഓരോ ഉപയോക്താവിന്റെയും അഭ്യർത്ഥനകൾ അവരുടേതായ വർക്ക്‌സ്‌പെയ്‌സിൽ പ്രവർത്തിക്കുകയും (അതിൽ പങ്കിട്ട റിസോഴ്സുകൾ ഉൾപ്പെട്ടാലും) വെവ്വേറെ ഓതന്റിക്കേറ്റ് ചെയ്യപ്പെടുകയും ചെയ്യുന്നു. എന്റർപ്രൈസ് സാഹചര്യങ്ങളിൽ ഇത് സാധാരണമാണ്, ഒന്നിലധികം MCP സെർവറുകൾ പ്രവർത്തിപ്പിക്കുന്നത് അനാവശ്യമായി ചെലവേറിയതാകുമെന്നതിനാൽ പങ്കിട്ട റിസോഴ്സുകൾക്കാണ് പലപ്പോഴും മുൻഗണന നൽകുന്നത്.

MCP ആർക്കിടെക്ചർ ഡയഗ്രം: ഘട്ടം ഘട്ടമായുള്ള വിശദീകരണം

പ്രായോഗികമായി ഒരു എൻഡ്-ടു-എൻഡ് MCP അഭ്യർത്ഥന എങ്ങനെയിരിക്കും? എട്ട് പ്രധാന ഘട്ടങ്ങളുണ്ട്, അവ ഓരോന്നിലും വ്യത്യസ്തമായ ഒരു ആർക്കിടെക്ചർ ഘടകം ഉൾപ്പെടുന്നു.

ഒരു ടാസ്‌ക് മാനേജ്‌മെന്റ് സേവനവുമായി ബന്ധിപ്പിച്ച നോട്ട്സ് ആപ്ലിക്കേഷന്റെ മുൻ ഉദാഹരണം ഉപയോഗിച്ച്, പ്രായോഗികമായി ഒരു MCP ടൂൾ കോൾ എങ്ങനെയിരിക്കുമെന്ന് ഇതാ:

  1. ടൂൾ ഡിസ്കവറി: നോട്ട്സ് ആപ്ലിക്കേഷൻ (ഹോസ്റ്റ്) ഒരു tools/list അഭ്യർത്ഥനയിലൂടെ സെർവറിൽ ലഭ്യമായ ടൂളുകൾ അഭ്യർത്ഥിക്കാൻ അതിന്റെ MCP ക്ലയന്റ് ഉപയോഗിക്കുന്നു. add-task ടൂളിനുള്ളവ ഉൾപ്പെടെ, അവയുടെ പേരുകളും വിവരണങ്ങളും പ്രതീക്ഷിക്കുന്ന ഇൻപുട്ടുകളും സെർവർ തിരികെ നൽകുന്നു. നിങ്ങൾ ഒരു പ്രോംപ്റ്റ് സമർപ്പിക്കുന്നതിന് മുമ്പുതന്നെ ഇത് സംഭവിച്ചേക്കാം.
  2. ഉപയോക്തൃ ഇൻപുട്ട്: ആപ്പിലെ ചാറ്റ്ബോട്ട് വഴി നിങ്ങൾ LLM അധിഷ്ഠിത നോട്ട്സ് ആപ്ലിക്കേഷനിലേക്ക് ഒരു അഭ്യർത്ഥന സമർപ്പിക്കുന്നു, ഉദാഹരണത്തിന്, “എന്റെ പുതിയ ഡ്രാഫ്റ്റ് അവലോകനം ചെയ്യാൻ ഇടത്തരം മുൻഗണനയോടെ എന്റെ കലണ്ടറിൽ ഒരു ടാസ്‌ക് സൃഷ്‌ടിക്കുക.”
  3. മോഡൽ പ്രോസസ്സിംഗ്: ഹോസ്റ്റ് നിങ്ങളുടെ അഭ്യർത്ഥനയും പ്രസക്തമായ ടൂൾ നിർവചനങ്ങളും LLM-ലേക്ക് അയയ്ക്കുന്നു.
  4. ടൂൾ തിരഞ്ഞെടുക്കൽ: ടൂളും അതിന്റെ ഇൻപുട്ടുകളും വ്യക്തമാക്കിക്കൊണ്ട് LLM ഘടനാപരമായ ഒരു ടൂൾ അഭ്യർത്ഥന സൃഷ്ടിക്കുന്നു: add-task, ഒപ്പം title: Review the draft, priority: Medium എന്നിവ. പ്രവർത്തനം അനുവദനീയമാണോ എന്ന് ഹോസ്റ്റ് പരിശോധിക്കുകയും അഭ്യർത്ഥന MCP ക്ലയന്റിലേക്ക് കൈമാറുകയും ചെയ്യുന്നു, ക്ലയന്റ് ഒരു JSON-RPC സന്ദേശം അയയ്ക്കുന്നു.
  5. അഭ്യർത്ഥന: MCP ക്ലയന്റ് അതിന്റെ MCP സെർവറിലേക്ക് ഒരു tools/call അഭ്യർത്ഥന അയയ്ക്കുന്നു.
  6. ടൂൾ നിർവ്വഹണം: വ്യക്തമാക്കിയ തലക്കെട്ടും മുൻഗണനയും ഉള്ള ഒരു പുതിയ ടാസ്‌ക് സൃഷ്‌ടിക്കാൻ MCP സെർവർ ടാസ്‌ക് മാനേജ്‌മെന്റ് ആപ്ലിക്കേഷന്റെ API വിളിക്കുന്നു.
  7. ഫലം തിരികെ നൽകൽ: സെർവർ ഫലം MCP ക്ലയന്റിലേക്ക് തിരികെ അയയ്ക്കുന്നു, ക്ലയന്റ് അത് ഹോസ്റ്റിലേക്ക് കൈമാറുന്നു. ഹോസ്റ്റ് അത് LLM-ന് നൽകുന്ന വിവരങ്ങളിലേക്ക് ചേർക്കുന്നു.
  8. ഉത്തരം സൃഷ്ടിക്കൽ: ഉപയോക്താവിനായി ഒരു ഉത്തരം സൃഷ്ടിക്കാൻ LLM ഫലം ഉപയോഗിക്കുന്നു, ഉദാഹരണത്തിന്, “ഡ്രാഫ്റ്റ് അവലോകനം ചെയ്യുന്നതിനായി ഇടത്തരം മുൻഗണനയോടെ ഞാൻ ഒരു ടാസ്‌ക് സൃഷ്‌ടിച്ചു.”

പരമ്പരാഗത API ആർക്കിടെക്ചറിൽ നിന്ന് MCP ആർക്കിടെക്ചർ എങ്ങനെ വ്യത്യസ്തമാണ്?

MCP-യും പരമ്പരാഗത API ആർക്കിടെക്ചറും പലപ്പോഴും ഒന്നായി തെറ്റിദ്ധരിക്കപ്പെടാറുണ്ട്, എന്നാൽ അവ പരസ്പരപൂരകമായ സാങ്കേതികവിദ്യകളാണ്. AI അധിഷ്ഠിത ആപ്ലിക്കേഷനുകൾക്കായി പ്രത്യേകമായി രൂപകൽപ്പന ചെയ്തതാണ് MCP. ഒന്നിലധികം ഹാർഡ്-കോഡ് ചെയ്ത API കണക്ഷനുകൾ നടപ്പിലാക്കുന്നതിനും നിയന്ത്രിക്കുന്നതിനുമുള്ള ഉയർന്ന പരിപാലന ഭാരം ഇത് മറികടക്കുന്നു.

ഓരോ പ്രവർത്തനക്ഷമതാ ദാതാവിനും അല്ലെങ്കിൽ ആന്തരിക റിസോഴ്സിനും ഒരു ഹോസ്റ്റ് ആപ്ലിക്കേഷന് ഒരൊറ്റ കണക്ഷൻ നൽകുന്നതിലൂടെ, അമിതമായി വലുതായ കോൺടെക്സ്റ്റ് ഇൻപുട്ട് (എല്ലാ API-കളും ലിസ്റ്റ് ചെയ്യുന്നത്) അല്ലെങ്കിൽ പരിമിതമായ API അധിഷ്ഠിത ആപ്ലിക്കേഷൻ സ്ക്രിപ്റ്റുകൾ എന്ന പ്രശ്നം പരിഹരിക്കാൻ MCP സഹായിക്കുന്നു.

പകരം, MCP-കൾക്ക് അവയുടെ ടൂൾ ലിസ്റ്റിന്റെ ഭാഗമായി API-കൾ (അല്ലെങ്കിൽ, കൃത്യമായി പറഞ്ഞാൽ, API-കളെ വിളിക്കുന്ന പ്രവർത്തനക്ഷമത) ലഭ്യമാക്കാൻ കഴിയും. ഒരു ദാതാവ് അവരുടെ ആപ്പ് അപ്‌ഡേറ്റ് ചെയ്യുകയും ഒരു പുതിയ API വരികയും ചെയ്യുമ്പോഴോ, ഡോക്യുമെന്റേഷൻ മാറുമ്പോഴോ, അവർ MCP സെർവർ അപ്‌ഡേറ്റ് ചെയ്താൽ മതി. ഹോസ്റ്റ് ആപ്പിന്റെ ഭാഗത്ത് കോഡ് മാറ്റങ്ങളൊന്നും ആവശ്യമില്ല.

MCP ആർക്കിടെക്ചർ സുരക്ഷിതമാണോ?

അവതരിപ്പിച്ചതുമുതൽ MCP സുരക്ഷ ഏറെ ചർച്ചാവിഷയമാണ്. ഇത് പൊതുവെ സുരക്ഷിതമായ ഒരു സാങ്കേതികവിദ്യയായി കണക്കാക്കപ്പെടുന്നുണ്ടെങ്കിലും, നിരവധി സുരക്ഷാ അപകടസാധ്യതകളുണ്ട്, അവയിൽ പലതും സങ്കീർണ്ണമായ ആർക്കിടെക്ചർ നടപ്പാക്കലുകളിൽ കൂടുതൽ പ്രകടമാണ്.

MCP ആർക്കിടെക്ചറിന് താഴെപ്പറയുന്ന സാധ്യതയുള്ള ദൗർബല്യങ്ങളുണ്ട്:

  • പ്രോംപ്റ്റ് ഇഞ്ചക്ഷൻ: AI മോഡൽ ഒരു നിർദ്ദേശമായി തെറ്റായി വ്യാഖ്യാനിക്കുന്ന ഒരു ക്ഷുദ്രകരമായ പ്രോംപ്റ്റ് ഒരു ഉപയോക്താവ് ബാഹ്യ ഡാറ്റയിലേക്ക് തിരുകുന്നു.
  • അമിത പ്രിവിലേജുള്ള ആക്‌സസ്: MCP സെർവറുകൾക്ക് ഒരു AI മോഡലിന് ധാരാളം ടൂളുകൾ ലഭ്യമാക്കാൻ സാധ്യതയുണ്ട്, ഇത് സുരക്ഷാ പ്രശ്നങ്ങൾക്കുള്ള സാധ്യത (ബ്ലാസ്റ്റ് റേഡിയസ്) വർദ്ധിപ്പിച്ചേക്കാം.
  • ആകസ്മികമായ ഡാറ്റാ ചോർച്ചകൾ: മോശമായി കോൺഫിഗർ ചെയ്ത നടപ്പാക്കലുകൾ കാരണം API കീകൾ അല്ലെങ്കിൽ ഡാറ്റാബേസ് ക്രെഡൻഷ്യലുകൾ പോലുള്ള സെൻസിറ്റീവ് വിവരങ്ങൾ ഒരു LLM-ലേക്ക് കൈമാറപ്പെടാൻ സാധ്യതയുണ്ട്.
  • ലോക്കൽ സിസ്റ്റം കൃത്രിമത്വം: മറ്റേതൊരു ആപ്ലിക്കേഷനെയും പോലെ, ക്ഷുദ്രകരമായ സ്ക്രിപ്റ്റുകൾ പോലുള്ള ലോക്കൽ സിസ്റ്റം പ്രശ്നങ്ങൾക്ക് ലോക്കൽ MCP സെർവറുകളും ഇരയാകാം; അതിനുപുറമെ, ഏജന്റിക് AI സിസ്റ്റങ്ങളിൽ അവയ്ക്ക് തുടർന്നുള്ള ദോഷകരമായ പ്രത്യാഘാതങ്ങൾ ഉണ്ടാക്കാനും കഴിയും.

ഈ പ്രശ്നങ്ങളൊന്നും മറികടക്കാനാവാത്തവയല്ല. പലപ്പോഴും, സിസ്റ്റം സുരക്ഷ ഉറപ്പാക്കാൻ സ്ഥാപിതമായ നടപടികൾ മാത്രം മതിയാകും. പ്രക്രിയയിൽ ഒരു മനുഷ്യന്റെ മേൽനോട്ടം ഉറപ്പാക്കുക, സെൻസിറ്റീവ് ഡാറ്റയ്ക്ക് ചുറ്റും കർശനമായ നിയന്ത്രണങ്ങൾ നടപ്പിലാക്കുക, സെർവർ ആക്രമണങ്ങൾക്കെതിരെ സംരക്ഷണം ഏർപ്പെടുത്തുക തുടങ്ങിയ നടപടികളെല്ലാം സാധാരണ രീതികളാണ്.

MCP ആർക്കിടെക്ചറിന്റെ ഭാവി എന്ത്?

ഡെവലപ്പർമാർക്ക് ഉപയോഗപ്രദവും ജനപ്രിയവുമായ ഒരു ഓപ്പൺ സ്റ്റാൻഡേർഡാണെന്ന് MCP തെളിയിച്ചിട്ടുണ്ട്. LLM അധിഷ്ഠിത ആപ്ലിക്കേഷനുകളിലെ ഹാർഡ്-കോഡ് ചെയ്ത API-കളുടെ പല പ്രശ്നങ്ങളും ഇത് മറികടക്കുകയും ഡെവലപ്പർമാരുടെ കോഡിംഗ് ഭാരം ഗണ്യമായി കുറയ്ക്കുകയും ചെയ്യുന്നു.

മുന്നോട്ട് പോകുമ്പോൾ, MCP-യുടെ അടിസ്ഥാന ഹോസ്റ്റ്, സെർവർ ആർക്കിടെക്ചർ ഏതാണ്ട് ഉറപ്പായും അതേപടി തുടരും. ഭാവിയിലെ നൂതനാശയങ്ങൾ മൾട്ടി-സ്റ്റെപ്പ് വർക്ക്ഫ്ലോകളിലുടനീളമുള്ള നൂതന ഏജന്റിക് കഴിവുകളെ കേന്ദ്രീകരിച്ചായിരിക്കും.

കൂടാതെ, ആ ഏജന്റിക് പ്രവർത്തനക്ഷമതകൾ നടപ്പിലാക്കുമ്പോൾ കൂടുതൽ ശക്തമായ സുരക്ഷാ സംരക്ഷണങ്ങളും, AI സിസ്റ്റങ്ങൾ കൂടുതൽ വിപുലവും സങ്കീർണ്ണവുമാകുമ്പോൾ, പ്രത്യേകിച്ച് ട്രാൻസ്പോർട്ട് ലെയറിൽ, സ്കെയിൽ ചെയ്യാവുന്ന ആർക്കിടെക്ചറും ആവശ്യമായി വരും.