Model Context Protocol (MCP), ലാർജ് ലാംഗ്വേജ് മോഡലുകളെ (LLMs) അളക്കാവുന്നതും സുരക്ഷിതവുമായ ഒരു ലൂപ്പിലൂടെ ബാഹ്യ ടൂളുകൾ ഉപയോഗിക്കാൻ കഴിയുന്ന ഏജന്റുകളാക്കി മാറ്റുന്നതിനുള്ള ഒരു കൃത്യമായ മാനദണ്ഡമായി പുറത്തിറങ്ങിയിരിക്കുന്നു. ഏതൊരു MCP-അറിവുള്ള ഹോസ്റ്റും (host) ഏതൊരു MCP സെർവറും തമ്മിൽ ഒരു പങ്കിട്ട "പ്ലഗ്" (plug) നിർവചിക്കുന്നതിലൂടെ, ഡെവലപ്പർമാർ താൽക്കാലികമായി എഴുതുന്ന കോഡുകൾക്ക് (ad-hoc code) പകരം പ്രവചിക്കാവുന്നതും പരിശോധിക്കാവുന്നതുമായ ഒരു പ്രവർത്തനരീതി (workflow) ഉപയോഗിക്കാൻ ഈ പ്രോട്ടോക്കോൾ അനുവദിക്കുന്നു.
എന്തുകൊണ്ടാണ് LLM-കൾക്ക് ഒരു പ്രോട്ടോക്കോൾ ആവശ്യമായിരിക്കുന്നത്?
ഒരു LLM അതിന്റെ പരിശീലന ഡാറ്റയിൽ നിന്നുള്ള അടുത്ത ടെക്സ്റ്റ് ടോക്കൺ (token) പ്രവചിക്കുക മാത്രമാണ് ചെയ്യുന്നത്. അധിക ലോജിക് ഇല്ലാതെ പുതിയ വസ്തുതകൾ ശേഖരിക്കാനോ, ഒരു ഡാറ്റാബേസിലേക്ക് എഴുതാനോ, അല്ലെങ്കിൽ ഒരു ബാഹ്യ API പ്രവർത്തിപ്പിക്കാനോ അതിന് കഴിയില്ല. ഡെവലപ്പർമാർ ഒരു മോഡലിനെ ഒരു ലൂപ്പിൽ പൊതിഞ്ഞുകൊണ്ട് "ഏജന്റുകൾ" നിർമ്മിച്ചിട്ടുണ്ട്: മോഡൽ ഒരു ടൂളിനായി ആവശ്യപ്പെടുന്നു, ടൂൾ പ്രവർത്തിക്കുന്നു, ഫലം തിരികെ നൽകുന്നു, തുടർന്ന് തുടരണോ അതോ ഉപയോക്താവിന് മറുപടി നൽകണോ എന്ന് മോഡൽ തീരുമാനിക്കുന്നു.
ആ ലൂപ്പ് പ്രവർത്തിക്കുന്നുണ്ടെങ്കിലും, പൊതുവായ നിയമങ്ങൾ ഇല്ലാതെ നിയന്ത്രണാതീതമായ പ്രക്രിയകൾ സൃഷ്ടിക്കാനോ അല്ലെങ്കിൽ ഒരു സിസ്റ്റത്തെ അപ്രതീക്ഷിതമായ കോളുകൾക്ക് വിധേയമാക്കാനോ എളുപ്പമാണ്. ഓരോ പുതിയ ടൂളിനും പ്രത്യേകമായ ഇന്റഗ്രേഷൻ ആവശ്യമായി വരുന്നത് ടോക്കൺ ഉപയോഗം, ബജറ്റ് പരിധികൾ അല്ലെങ്കിൽ പ്രോജക്റ്റുകളിലെ സുരക്ഷാ നയങ്ങൾ എന്നിവ ട്രാക്ക് ചെയ്യുന്നത് പ്രയാസകരമാക്കുന്നു.
ലൂപ്പിന്റെ ഘടനയെയും അതിലൂടെ കൈമാറേണ്ട ഡാറ്റയെയും കോഡിഫൈ ചെയ്യുന്നതിലൂടെ MCP ഈ വിടവുകൾ നികത്തുന്നു.
ഒരു MCP ഏജന്റിന്റെ രണ്ട് ഭാഗങ്ങൾ
MCP ഒരു ഏജന്റിനെ നിർവ്വചനമായി (definition) – ഏജന്റിന് എന്ത് ചെയ്യാൻ കഴിയുമെന്ന് വിവരിക്കുന്ന ടെംപ്ലേറ്റ് – എന്നും ഒരു ഇൻസ്റ്റൻസ് (instance) – ഒരു ഉപയോക്താവിന്റെ അഭ്യർത്ഥനയുടെ യഥാർത്ഥ നിർവ്വഹണം – എന്നും വേർതിരിക്കുന്നു.
ഏജന്റ് നിർവ്വചനം (ടെംപ്ലേറ്റ്)
- Host loop – ask-tool-read-decide ചക്രം നിയന്ത്രിക്കുന്ന ഓർക്കസ്ട്രേറ്റർ.
- System context – മോഡലിന്റെ പെരുമാറ്റത്തെ രൂപപ്പെടുത്തുന്ന പേഴ്സണയും (persona) ഉയർന്ന തലത്തിലുള്ള നിർദ്ദേശങ്ങളും.
- MCP server set – ഹോസ്റ്റിന് വിളിക്കാവുന്ന ലഭ്യമായ ടൂൾ സ്രോതസ്സുകളുടെ ഒരു കാറ്റലോഗ്.
- Tool policy – ഒരു പ്രത്യേക ഏജന്റിന് അനുവദനീയമായ ടൂളുകളുടെ വ്യക്തമായ പട്ടിക.
- LLM selection – ടെക്സ്റ്റ് റീസണിംഗ് (textual reasoning) നിർമ്മിക്കുന്ന പ്രത്യേക മോഡൽ.
- Termination limits – അനന്തമായ ലൂപ്പുകൾ ഒഴിവാക്കാൻ പരമാവധി ഇറ്ററേഷനുകളും ടോക്കൺ ബജറ്റും.
- Task contract – ഏജന്റ് സ്വീകരിക്കുന്ന ഇൻപുട്ടുകളെക്കുറിച്ചും അത് തിരികെ നൽകുന്ന ഔട്ട്പുട്ട് ഫോർമാറ്റിനെക്കുറിച്ചുമുള്ള ഔദ്യോഗിക വിവരണം.
- Context strategy – ടോക്കൺ പരിധിക്കുള്ളിൽ നിൽക്കുന്നതിന് സംഭാഷണ ചരിത്രം എങ്ങനെ കുറയ്ക്കണം അല്ലെങ്കിൽ സംഗ്രഹിക്കണം എന്നതിനായുള്ള നിയമങ്ങൾ.
ഏജന്റ് ഇൻസ്റ്റൻസ് (പ്രവർത്തിക്കുന്ന ടാസ്ക്)
- Goal – ലൂപ്പ് ആരംഭിക്കുന്ന ഉപയോക്താവിന്റെ അഭ്യർത്ഥന.
- Working context – മുൻപത്തെ ടൂൾ ഫലങ്ങൾ ഉൾപ്പെടെയുള്ള ശേഖരിച്ച ചരിത്രം.
- Credentials – തിരഞ്ഞെടുത്ത ടൂളുകൾ ഉപയോഗിക്കാൻ ആവശ്യമായ ടോക്കണുകളോ പെർമിഷൻ സെറ്റുകളോ.
- Consumed budget – ഇതുവരെ ചിലവായ ടോക്കണുകളുടെയും എടുത്ത സ്റ്റെപ്പുകളുടെയും കണക്ക്.
ഈ ഘടകങ്ങൾ ഒരു ഏജന്റിന് എന്ത് ചെയ്യാൻ അനുവാദമുണ്ട് എന്നും അത് നിലവിൽ എന്ത് ചെയ്യുന്നു എന്നും കാണിക്കുന്നു.
MCP എങ്ങനെ വികസന പ്രക്രിയയെ (Development Flow) മാറ്റുന്നു
MCP-ക്ക് മുമ്പ്, ഒരു വെതർ API ക്വറി ചെയ്യാനും, ഡാറ്റാബേസിൽ നിന്ന് ഒരു വരി എടുക്കാനും, തുടർന്ന് ഒരു റിപ്പോർട്ട് തയ്യാറാക്കാനും ഒരു LLM വേണമെന്ന് ആഗ്രഹിക്കുന്ന ഡെവലപ്പർ, ഓരോ എൻഡ്പോയിന്റിനും പ്രത്യേകമായി കോഡ് (bespoke glue code) എഴുതേണ്ടി വരുമായിരുന്നു. ആ കോഡ് പലപ്പോഴും മോഡലിന്റെ പ്രോംപ്റ്റിനുള്ളിൽ ടൂൾ കോളുകളെ ഒളിപ്പിച്ചു വെക്കുമായിരുന്നു, ഇത് ഏത് അഭ്യർത്ഥനയാണ് ഏത് പ്രതികരണത്തിന് കാരണമായതെന്ന് കാണുന്നത് അസാധ്യമാക്കി.
MCP ഉപയോഗിച്ച്, ഹോസ്റ്റ് സംഭാഷണം മോഡലിന് അയക്കുന്നു, മോഡൽ നിർമ്മിക്കുന്ന ഏതൊരു ടൂൾ അഭ്യർത്ഥനയും പരിശോധിക്കുന്നു, ടൂൾ സ്വയം പ്രവർത്തിപ്പിക്കുന്നു, തുടർന്ന് ഫലം തിരികെ നൽകുന്നു. അധിക കോഡ് വളരെ കുറവാണ്, എന്നാൽ കാഴ്ചപ്പാട് (visibility) പൂർണ്ണമാണ്: ഓരോ റൗണ്ട്-ട്രിപ്പും ഓരോ ടോക്കണും ലോഗ് ചെയ്യപ്പെടുന്നു.
ആ കാഴ്ചപ്പാട് രണ്ട് പ്രായോഗിക നേട്ടങ്ങൾ നൽകുന്നു:
- Cost measurement – ഡെവലപ്പർമാർക്ക് ഒരേ ടാസ്കിനായി കുറഞ്ഞ ചിലവുള്ള ഒരു മോഡലിനെ വലിയൊരു മോഡലുമായി താരതമ്യം ചെയ്യാനും ഓരോ ഇറ്ററേഷനും എത്ര ടോക്കണുകൾ ഉപയോഗിക്കുന്നു എന്ന് കൃത്യമായി കാണാനും കഴിയും.
- Security auditing – ടൂൾ പോളിസിയും ക്രെഡൻഷ്യൽ പരിശോധനകളും മോഡലിന് പുറത്ത് നടക്കുന്നു, ഇത് മോഡൽ അനുമതിയില്ലാത്ത സേവനങ്ങൾ നിശബ്ദമായി ഉപയോഗിക്കുന്നത് തടയുന്നു.
എന്തൊക്കെയാണ് ഇപ്പോഴും നിർവചിക്കപ്പെടാത്തത്?
MCP സംഭാഷണത്തിന്റെ രൂപവും അതിനോടൊപ്പം വരുന്ന മെറ്റാഡേറ്റയും നിർദ്ദേശിക്കുന്നുണ്ടെങ്കിലും, ഒരു ടൂൾ ആന്തരികമായി എങ്ങനെ നടപ്പിലാക്കണം എന്ന് ഇത് നിശ്ചയിക്കുന്നില്ല.
അടുത്തതായി ശ്രദ്ധിക്കേണ്ടവ
- Metric suites – ഈ പരമ്പരയിലെ അടുത്ത ലേഖനം ഡെവലപ്പർമാർ ട്രാക്ക് ചെയ്യേണ്ട സംഖ്യകളുടെ (ടോക്കൺ ചിലവ്, ഇറ്ററേഷൻ എണ്ണം, ഓരോ ടൂളിനും വേണ്ട ലേറ്റൻസി) ഒരു ചെക്ക്ലിസ്റ്റ് വാഗ്ദാനം ചെയ്യുന്നു. ഈ മെട്രിക്സുകൾ ഏതൊരു MCP അധിഷ്ഠിത ഏജന്റും പരിശോധിക്കാനുള്ള മാനദണ്ഡങ്ങളായി മാറും.
ചുരുക്കത്തിൽ
Model Context Protocol LLM ഏജന്റുകൾക്ക് ഒരു പങ്കിട്ട, പരിശോധിക്കാവുന്ന ഘടന നൽകുന്നു, ഇത് ഒരു ഏജന്റിന് എന്ത് ചെയ്യാൻ കഴിയും എന്നതിൽ നിന്നും അത് ഏത് നിമിഷവും എന്ത് ചെയ്യുന്നു എന്നതിൽ നിന്നും വ്യത്യാസപ്പെട്ടിരിക്കുന്നു. അവ്യക്തമായ ടൂൾ-കോളിംഗിനെ സുതാര്യമായ ഒരു ലൂപ്പായി മാറ്റുന്നതിലൂടെ, MCP അത്തരം അളവുകൾ സാധ്യമാക്കുന്നു.