If you have spent years maintaining business logic inside PHP applications, watching Model Context Protocol tutorials ca

വർഷങ്ങളായി PHP ആപ്ലിക്കേഷനുകളിൽ ബിസിനസ് ലോജിക് പരിപാലിച്ചുവരികയാണെങ്കിൽ, Model Context Protocol ട്യൂട്ടോറിയലുകൾ കാണുന്നത് ഒരു പൂട്ടിയ വാതിലിന് പുറത്ത് നിൽക്കുന്നത് പോലെ തോന്നാം. മിക്കവാറും എല്ലാ ഗൈഡുകളും TypeScript അല്ലെങ്കിൽ Python ഉപയോഗിക്കുന്നു എന്ന് അനുമാനിക്കുന്നു. അവ ഔദ്യോഗിക SDK-കൾ, npm ഇൻസ്റ്റാളേഷനുകൾ, pip പാക്കേജുകൾ എന്നിവയെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്. ഇത് വലിയ അളവിലുള്ള ബിസിനസ് ഡാറ്റ—കസ്റ്റമർ റെക്കോർഡുകൾ, ഓർഡർ ഹിസ്റ്ററികൾ, ഇൻവെന്ററി സിസ്റ്റങ്ങൾ—നിലവിലുള്ള AI ടൂളുകൾക്ക് കാണാൻ കഴിയാത്ത രീതിയിൽ PHP കോഡ്ബേസുകളിൽ തന്നെ അവശേഷിപ്പിക്കുന്നു.

നല്ല വാർത്ത എന്തെന്നാൽ, MCP-ക്ക് ഈ SDK-കളുടെ ആവശ്യമില്ല എന്നതാണ്. MCP ഒരു ലൈബ്രറിയല്ല. ഇതൊരു വയർ പ്രോട്ടോക്കോൾ (wire protocol) ആണ്. നിങ്ങളുടെ റൺടൈമിന് സ്റ്റാൻഡേർഡ് ഇൻപുട്ടിൽ നിന്ന് ഒരു വരി ടെക്സ്റ്റ് വായിക്കാനും, JSON പാഴ്സ് ചെയ്യാനും, തിരികെ JSON എഴുതാനും കഴിയുമെങ്കിൽ, അതിന് ഈ പ്രോട്ടോക്കോൾ ഉപയോഗിക്കാൻ കഴിയും. LLM-കൾ നിലവിൽ വരുന്നതിന് വളരെ മുമ്പുതന്നെ PHP ഇത് കൃത്യമായി ചെയ്തുവരുന്നുണ്ട്.

എന്താണ് യഥാർത്ഥത്തിൽ MCP?

MCP എന്നാൽ Model Context Protocol എന്നാണ് അർത്ഥമാക്കുന്നത്. അതിന്റെ അടിസ്ഥാനത്തിൽ, AI അസിസ്റ്റന്റുകളെ ഡാറ്റ, ടൂളുകൾ, എക്സ്റ്റേണൽ API-കൾ എന്നിവയുമായി ബന്ധിപ്പിക്കുന്നതിനുള്ള ഒരു ഓപ്പൺ സ്റ്റാൻഡേർഡാണിത്. ഓരോ അസിസ്റ്റന്റിനും മോഡലിനും വേണ്ടി പ്രത്യേകം ഇന്റഗ്രേഷൻ നിർമ്മിക്കുന്നതിന് പകരം, നിങ്ങൾക്ക് ഒരു കോംപ്ലയന്റ് ഇന്റർഫേസ് (compliant interface) നിർമ്മിക്കാം. MCP മനസ്സിലാക്കുന്ന ഏത് ക്ലയന്റിനും PHP, Laravel അല്ലെങ്കിൽ നിങ്ങളുടെ ഡാറ്റാബേസ് സ്കീമയെക്കുറിച്ച് ഒന്നും അറിയാതെ തന്നെ നിങ്ങളുടെ സെർവറുമായി സംസാരിക്കാൻ കഴിയും.

ഇതിന്റെ പിന്നിൽ, MCP JSON-RPC 2.0 ആണ് ഉപയോഗിക്കുന്നത്. അതായത്, ഓരോ റിക്വസ്റ്റും ഒരു മെത്തേഡ് പേര്, പാരാമീറ്ററുകൾ, ഒരു ID എന്നിവ അടങ്ങിയ ലളിതമായ ഒരു JSON ഒബ്‌ജക്റ്റ് ആണ്. സെർവർ ഒരു റിസൾട്ടോ അല്ലെങ്കിൽ ഒരു എററോ അടങ്ങിയ മറ്റൊരു JSON ഒബ്‌ജക്റ്റ് ഉപയോഗിച്ച് മറുപടി നൽകുന്നു.

ഒരു സെർവർ മൂന്ന് പ്രിമിറ്റീവുകൾ (primitives) പ്രദാനം ചെയ്യുന്നു:

• Tools: മോഡലിന് ചെയ്യാൻ കഴിയുന്ന പ്രവർത്തനങ്ങൾ. ഒരു ടൂൾ ഒരു ഡാറ്റാബേസ് ക്വറി ചെയ്യുകയോ, സ്റ്റാറ്റസ് അപ്ഡേറ്റ് ചെയ്യുകയോ, അല്ലെങ്കിൽ ഒരു തേർഡ് പാർട്ടി API വിളിക്കുകയോ ചെയ്തേക്കാം.
• Resources: ഒരു URI വഴി മോഡലിന് റഫർ ചെയ്യാൻ കഴിയുന്ന സ്റ്റാറ്റിക് അല്ലെങ്കിൽ സെമി-സ്റ്റാറ്റിക് ഡാറ്റ. ഫയലുകൾ, കോൺഫിഗറേഷൻ ഡോക്യുമെന്റുകൾ അല്ലെങ്കിൽ റഫറൻസ് ഡാറ്റാസെറ്റുകൾ എന്നിവ ഇതിന് ഉദാഹരണമാണ്.
• Prompts: ഉപയോക്താവിന് സിസ്റ്റവുമായി സംവദിക്കാൻ സഹായിക്കുന്ന മുൻകൂട്ടി നിശ്ചയിച്ച ടെംപ്ലേറ്റുകൾ.

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

ട്രാൻസ്പോർട്ട് എങ്ങനെ പ്രവർത്തിക്കുന്നു

MCP രണ്ട് ട്രാൻസ്പോർട്ട് രീതികൾ നിർവചിക്കുന്നു, നിങ്ങളുടെ തിരഞ്ഞെടുപ്പ് നിങ്ങൾ എങ്ങനെ PHP ഭാഗം എഴുതുന്നു എന്നതിനെ സ്വാധീനിക്കുന്നു.

stdio ആണ് ഏറ്റവും ലളിതമായ രീതി. MCP ക്ലയന്റ് നിങ്ങളുടെ PHP സ്ക്രിപ്റ്റിനെ ഒരു സബ്പ്രോസസ് (subprocess) ആയി പ്രവർത്തിപ്പിക്കുന്നു. ക്ലയന്റ് നിങ്ങളുടെ സ്ക്രിപ്റ്റിന്റെ സ്റ്റാൻഡേർഡ് ഇൻപുട്ടിലേക്ക് JSON-RPC സന്ദേശങ്ങൾ എഴുതുന്നു, നിങ്ങളുടെ സ്ക്രിപ്റ്റ് സ്റ്റാൻഡേർഡ് ഔട്ട്പുട്ടിലേക്ക് മറുപടികൾ എഴുതുന്നു. ഇവിടെ മാനേജ് ചെയ്യാൻ സോക്കറ്റുകളോ, തുറക്കാൻ പോർട്ടുകളോ, പാഴ്സ് ചെയ്യാൻ ഓതന്റിക്കേഷൻ ഹെഡറുകളോ ഇല്ല. നിങ്ങളുടെ ടൂളും ക്ലയന്റും ഒരേ മെഷീനിൽ ആണെങ്കിൽ, ഇത് തുടങ്ങാൻ പറ്റിയ സ്ഥലമാണ്.

stdio വഴി പ്രവർത്തിക്കുമ്പോൾ നിങ്ങളുടെ PHP പ്രോസസ്സിൽ രണ്ട് കർശനമായ നിയമങ്ങൾ ബാധകമാണ്. ഒന്നാമതായി, നിങ്ങളുടെ ആപ്ലിക്കേഷൻ ഒരിക്കലും പ്രോട്ടോക്കോൾ ഇതര ഡാറ്റ stdout-ലേക്ക് എഴുതരുത്. നിങ്ങൾ ഒരു ഡീബഗ് സ്റ്റേറ്റ്‌മെന്റ് എക്കോ (echo) ചെയ്യുകയോ അല്ലെങ്കിൽ ഒരു PHP നോട്ടീസ് പുറത്തുവരാൻ അനുവദിക്കുകയോ ചെയ്താൽ, അത് ക്ലയന്റിന്റെ പാഴ്സറെ തകരാറിലാക്കും. എല്ലാ ലോഗിംഗും ഡയഗ്നോസ്റ്റിക്സും stderr-ലേക്ക് മാറ്റുക. രണ്ടാമതായി, ഔട്ട്പുട്ട് ബഫറിംഗ് (output buffering) പൂർണ്ണമായും നിർത്തലാക്കുക. PHP സാധാരണയായി stdout ബഫർ ചെയ്യാൻ ഇഷ്ടപ്പെടുന്നു, പ്രത്യേകിച്ച് CGI അല്ലെങ്കിൽ വെബ് സാഹചര്യങ്ങളിൽ, എന്നാൽ CLI സ്ക്രിപ്റ്റുകൾ പോലും ഡാറ്റ ശേഖരിച്ചുവെച്ചേക്കാം. ഓരോ മറുപടിയും ഉടൻ തന്നെ ഫ്ലഷ് (flush) ചെയ്യുക. നിങ്ങൾ സ്ട്രീമുകൾ ഉപയോഗിക്കുകയാണെങ്കിൽ, stream_set_write_buffer(STDOUT, 0) എന്ന് സെറ്റ് ചെയ്യുകയോ അല്ലെങ്കിൽ ഇംപ്ലിസിറ്റ് ബഫറിംഗ് ഓഫ് ചെയ്യുകയോ ചെയ്യുക, അങ്ങനെ നിങ്ങൾ അയക്കുന്ന നിമിഷം തന്നെ ക്ലയന്റിന് ന്യൂലൈൻ (newline) ലഭിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കാം.

Streamable HTTP വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നു. നിങ്ങളുടെ PHP ആപ്ലിക്കേഷൻ ഒരു പെർസിസ്റ്റന്റ് (persistent) HTTP എൻഡ്പോയിന്റായി പ്രവർത്തിക്കുന്നു, സാധാരണയായി POST റിക്വസ്റ്റുകൾ വഴിയാണ് ഇത് ലഭ്യമാകുന്നത്. സെർവർ മറ്റൊരു ഹോസ്റ്റിലാണെങ്കിൽ അല്ലെങ്കിൽ ഒന്നിലധികം ക്ലയന്റുകൾക്ക് എത്തിച്ചേരാൻ കഴിയുന്ന ഒരു ലോങ്ങ്-റണ്ണിംഗ് ഡെമൺ (long-running daemon) നിങ്ങൾക്ക് വേണമെങ്കിൽ ഇത് ഉപയോഗപ്രദമാണ്. PHP-യിൽ, ഇതിനർത്ഥം ഓരോ കോളിന് ശേഷവും അവസാനിക്കുന്ന പരമ്പരാഗത റിക്വസ്റ്റ്-റെസ്പോൺസ് സൈക്കിളിന് പകരം RoadRunner, FrankenPHP അല്ലെങ്കിൽ സമാനമായ ഒരു പ്രോസസ് മാനേജർ ഉപയോഗിച്ച് പ്രവർത്തിപ്പിക്കുക എന്നാണ്.

PHP-യിൽ ഇത് നിർമ്മിക്കാം

തുടങ്ങാൻ നിങ്ങൾക്ക് ഒരു ഫ്രെയിംവർക്ക് ആവശ്യമില്ല. PHP-യിലെ ഒരു മിനിമൽ MCP സെർവർ എന്നത് STDIN-ൽ നിന്ന് വായിക്കുകയും, JSON ഡീകോഡ് ചെയ്യുകയും, ഒരു ഹാൻഡ്‌ലറിലേക്ക് അയക്കുകയും, റിസൾട്ട് എൻകോഡ് ചെയ്യുകയും ചെയ്യുന്ന ഒരു ലൂപ്പ് മാത്രമാണ്.

while ($line = fgets(STDIN)) {
    $request = json_decode($line, true);
    // route to tool or resource handler
    // write JSON-RPC response to STDOUT
}

ആ ലൂപ്പിനുള്ളിൽ, ഒരു മോഡലിന് മനസ്സിലാകുന്ന രീതിയിലുള്ള ഇന്റർഫേസുകൾ നിർമ്മിക്കുക എന്നതാണ് യഥാർത്ഥ ജോലി.

കോഡിൽ നിന്ന് ടൂൾ സ്കീമകൾ (tool schemas) നിർമ്മിക്കുക. ടൂൾ പാരാമീറ്ററുകൾക്കായി JSON Schemas കൈകൊണ്ട് എഴുതുന്നതും അവ യഥാർത്ഥ വാലിഡേഷൻ ലോജിക്കിൽ (validation logic) നിന്ന് വ്യതിചലിക്കുന്നതും വലിയ പ്രശ്നങ്ങൾക്ക് കാരണമാകുന്ന വേഗമേറിയ വഴികളിലൊന്നാണ്. PHP-ക്ക് മികച്ച റിഫ്ലക്ഷൻ (reflection) കഴിവുകളുണ്ട്. നിങ്ങളുടെ മെത്തേഡ് സിഗ്നേച്ചറുകൾ പരിശോധിക്കുക, ഫോമുകളിൽ നിന്നോ കമാൻഡ് ഒബ്‌ജക്റ്റുകളിൽ നിന്നോ നിലവിലുള്ള വാലിഡേഷൻ നിയമങ്ങൾ വായിക്കുക, ആ നിയന്ത്രണങ്ങളിൽ നിന്ന് സ്കീമ നിർമ്മിക്കുക. നിങ്ങളുടെ ഇന്റേണൽ കോഡിന് ഒരു സാധുവായ ഇമെയിൽ ഫോർമാറ്റ് ആവശ്യമാണെങ്കിൽ, നിങ്ങളുടെ MCP സ്കീമയും അത് തന്നെ പറയണം. വാലിഡേഷൻ നിയമങ്ങൾ മാറുമ്പോൾ, സ്കീമയും സ്വയമേവ പുതുക്കപ്പെടുന്നു. വ്യതിയാനങ്ങളോ (drift) നിശബ്ദമായ പരാജയങ്ങളോ (silent failures) ഉണ്ടാവില്ല.

പ്രോട്ടോക്കോൾ പിശകുകളെ ടൂൾ പിശകുകളിൽ നിന്ന് വേർതിരിക്കുക. JSON-RPC-ക്ക് അതിന്റേതായ എറർ സ്പേസ് (error space) ഉണ്ട്. തെറ്റായ JSON, അറിയപ്പെടാത്ത മെത്തേഡുകൾ, അല്ലെങ്കിൽ മിസ്സിംഗ് റിക്വസ്റ്റ് ഐഡികൾ തുടങ്ങിയ പ്രോട്ടോക്കോൾ തകരാറുകൾക്കായി ഇത് ഉപയോഗിക്കുക. ഒരു ടൂൾ ശരിയായി പ്രവർത്തിക്കുമ്പോഴും ബിസിനസ്സ് സംബന്ധമായ ഒരു പ്രശ്നം നേരിടുമ്പോഴും, പേലോഡിനുള്ളിൽ (payload) ഒരു എറർ ഫ്ലാഗ് നൽകിക്കൊണ്ട് സാധാരണ റിസൾട്ട് തിരികെ നൽകുക. ഒരു കസ്റ്റമർ ലുക്കപ്പ് ടൂൾ മാച്ച് ചെയ്യുന്ന റെക്കോർഡുകൾ കണ്ടെത്തുന്നില്ലെങ്കിൽ, അത് പ്രോട്ടോക്കോൾ തകരാറല്ല. {"found": false} എന്നതുപോലെയുള്ള ഒരു സ്ട്രക്ചേർഡ് റിസൾട്ട് നൽകുന്നത് എന്ത് സംഭവിച്ചു എന്ന് മനസ്സിലാക്കാനും അടുത്ത ഘട്ടം തിരഞ്ഞെടുക്കാനും മോഡലിനെ സഹായിക്കും. അത് കൂടുതൽ വിപുലമായ ഒരു സെർച്ച് പരീക്ഷിച്ചേക്കാം, അല്ലെങ്കിൽ കൂടുതൽ വ്യക്തതയ്ക്കായി ഉപയോക്താവിനോട് ചോദിച്ചേക്കാം. പകരം നിങ്ങൾ ഒരു JSON-RPC എറർ നൽകുകയാണെങ്കിൽ, മോഡൽ പലപ്പോഴും കോൺടെക്സ്റ്റ് (context) നഷ്ടപ്പെടുത്തുന്നു.

ദീർഘനേരം എടുക്കുന്ന ജോലികൾക്കായി പ്ലാൻ ചെയ്യുക. PHP നിർമ്മിച്ചിരിക്കുന്നത് ചെറിയ റിക്വസ്റ്റുകൾക്കായുള്ളതാണ്. ഒരു വെബ് റിക്വസ്റ്റ് മുപ്പത് സെക്കൻഡിനുള്ളിൽ ടൈം ഔട്ട് ആയേക്കാം, കൂടാതെ CLI സ്ക്രിപ്റ്റുകൾ പോലും മെമ്മറി അല്ലെങ്കിൽ ക്ഷമ തീർന്നുപോയേക്കാം. ഒരു ടൂളിന് പൂർത്തിയാക്കാൻ മിനിറ്റുകൾ ആവശ്യമാണെങ്കിൽ—ഒരുപക്ഷേ അത് വലിയൊരു റിപ്പോർട്ട് തയ്യാറാക്കുകയോ സിസ്റ്റങ്ങൾക്കിടയിൽ ഡാറ്റ സിങ്ക് ചെയ്യുകയോ ചെയ്യുകയാണെങ്കിൽ—മോഡലിനെ കാത്തുനിൽപ്പിക്കരുത്. ഉടൻ തന്നെ ഒരു ജോബ് ഐഡന്റിഫയർ (job identifier) നൽകുക. തുടർന്ന് ആ ഐഡി ഉപയോഗിച്ച് സ്റ്റാറ്റസ് പരിശോധിക്കുന്നതിനായി രണ്ടാമതൊരു ടൂൾ ലഭ്യമാക്കുക. പ്രോഗ്രസ്സ് (progress) Redis-ലോ, ഒരു ഡാറ്റാബേസ് ടേബിളിലോ, അല്ലെങ്കിൽ ഡാറ്റ കുറവാണെങ്കിൽ ഒരു ഫ്ലാറ്റ് ഫയലിലോ സൂക്ഷിക്കാം. മോഡൽ ഐഡി സ്വീകരിക്കുന്നു, പിന്നീട് പരിശോധിക്കുന്നു, ഒടുവിൽ പൂർത്തിയായ റിസൾട്ട് എടുക്കുന്നു.

മോഡലിന് കീകൾ (Keys) ഉള്ളപ്പോൾ സുരക്ഷ

ഒരു AI മോഡലിന് ഒരു ടൂൾ ഉപയോഗിക്കാനുള്ള അനുമതി നൽകുന്നത് ഒരു മനുഷ്യന് നൽകുന്നത് പോലെയല്ല. ഒരു മോഡൽ വളരെ വേഗത്തിൽ പ്രവർത്തിക്കുന്നു, കൂടാതെ വിവരണങ്ങൾ തെറ്റായി വ്യാഖ്യാനിച്ചേക്കാം. ഓരോ ടൂളിനെയും ഒരു പ്രിവിലേജ് എസ്കലേഷൻ റിസ്ക് (privilege escalation risk) ആയി പരിഗണിക്കുക.

സ്കോപ്പ് (scope) കർശനമായി പരിമിതപ്പെടുത്തുക. ഒരിക്കലും ഒരു ജനറിക് run_sql ടൂൾ വെളിപ്പെടുത്തരുത്. find_customer_by_email അല്ലെങ്കിൽ update_order_status പോലുള്ള പ്രത്യേകവും പരിമിതവുമായ ടൂളുകൾ നിർമ്മിക്കുക. നിങ്ങൾ നിർവചിച്ച പാരാമീറ്ററുകൾ ഉപയോഗിച്ച്, നിങ്ങൾ പേര് നൽകിയ കാര്യങ്ങൾ മാത്രം ചെയ്യാൻ മോഡലിന് കഴിയണം.

റീഡ് (read), റൈറ്റ് (write) പാത്തുകൾ വേർതിരിക്കുക. റീഡ്-ഒൺലി (read-only) ടൂളുകൾക്ക് കുറഞ്ഞ റിസ്ക് ആണ്. ഏതെങ്കിലും വിനാശകരമായ (destructive) പ്രവർത്തനങ്ങളെ ഒരു വ്യക്തമായ കൺഫർമേഷൻ മെക്കാനിസത്തിന് പിന്നിലാക്കുക, അല്ലെങ്കിൽ അവ പൂർണ്ണമായും രണ്ടാമതൊരു സെർവറിലേക്ക് പരിമിതപ്പെടുത്തുക. നിങ്ങളുടെ ക്ലയന്റ് പിന്തുണയ്ക്കുന്നുണ്ടെങ്കിൽ, ഒരു റൈറ്റ് ടൂൾ പ്രവർത്തിക്കുന്നതിന് മുമ്പ് ഒരു മനുഷ്യന്റെ അനുമതി (human approval) ആവശ്യമാക്കുക.

ടൂൾ വിവരണങ്ങൾ (tool descriptions) അധിക നിർദ്ദേശങ്ങൾ പോലെ എഴുതുക, കാരണം അവ അങ്ങനെ തന്നെയാണ്. മോഡൽ എപ്പോൾ ഒരു ടൂൾ വിളിക്കണം എന്നതിനെക്കുറിച്ച് കൃത്യത പാലിക്കുക. ഒരു ടൂൾ വില പരിശോധിക്കാനാണെങ്കിൽ അത് പറയുക. കസ്റ്റമർ ഐഡി പരിശോധിച്ചതിന് ശേഷം മാത്രമേ ഇത് ഉപയോഗിക്കാവൂ എന്നുണ്ടെങ്കിൽ അത് വ്യക്തമായി പറയുക. അവ്യക്തമായ വിവരണങ്ങൾ അവ്യക്തമായ പെരുമാറ്റത്തിലേക്ക് നയിക്കും.

ഔട്ട്‌പുട്ട് ഫിൽട്ടർ ചെയ്യുക. ഒരു മുഴുവൻ Eloquent മോഡലോ Doctrine എൻ്റിറ്റിയോ സീരിയലൈസ് ചെയ്ത് റിസൾട്ടിലേക്ക് ഇടരുത്. മോഡലിന് യഥാർത്ഥത്തിൽ ആവശ്യമുള്ള ഫീൽഡുകൾ മാത്രം നൽകുക. ഇന്റേണൽ ഫീൽഡുകൾ—കോസ്റ്റ് പ്രൈസുകൾ, എംപ്ലോയി നോട്ടുകൾ, ഇന്റേണൽ ആയിരിക്കേണ്ട ഡാറ്റാബേസ് ഐഡികൾ—പുറത്തേക്ക് പോകാൻ പാടില്ലാത്തവയാണ്. നിങ്ങളുടെ റിട്ടേൺ ഷേപ്പിനെക്കുറിച്ച് (return shape) വ്യക്തത വരുത്തുക.

അവസാനമായി, എല്ലാം ലോഗ് (log) ചെയ്യുക. ടൂളിന്റെ പേര്, പാസ് ചെയ്ത ആർഗ്യുമെന്റുകൾ (arguments), ഫലം എന്നിവ രേഖപ്പെടുത്തുക. ഒരു മോഡൽ വലിയൊരു ക്വറിയിൽ (query) വീണ്ടും വീണ്ടും ലൂപ്പ് ചെയ്യുകയോ അല്ലെങ്കിൽ അപ്രതീക്ഷിതമായ ക്രമത്തിൽ ടൂളുകൾ പരിശോധിക്കുകയോ ചെയ്താൽ, അത് കാണാനുള്ള ഏക വഴി നിങ്ങളുടെ ലോഗുകൾ മാത്രമാണ്.

എവിടെ നിന്ന് തുടങ്ങണം

നിങ്ങളുടെ PHP ആപ്ലിക്കേഷനെ ഒരു AI അസിസ്റ്റൻറുമായി ബന്ധിപ്പിക്കുന്നതിന് ഒരു SDK മെയിന്റനറുടെ അനുമതി നിങ്ങൾക്ക് ആവശ്യമില്ല. നിങ്ങൾക്ക് JSON-RPC, ഒരു ലൂപ്പ്, കൂടാതെ stdout-ൽ കൃത്യമായ അച്ചടക്കം എന്നിവ ആവശ്യമാണ്.

ആദ്യ ദിവസം തന്നെ നിങ്ങളുടെ മുഴുവൻ API-യും MCP ടൂളുകളായി പുനർനിർമ്മിക്കാനുള്ള ആഗ്രഹം നിയന്ത്രിക്കുക. നിങ്ങളുടെ സ്ഥാപനത്തിലുള്ള ഒരാൾ ആവർത്തിച്ച് ചോദിക്കുന്ന മൂന്ന് റീഡ്-ഒൺലി (read-only) പ്രവർത്തനങ്ങൾ തിരഞ്ഞെടുക്കുക. ഒരുപക്ഷേ അത് ഓർഡർ സ്റ്റാറ്റസ് പരിശോധിക്കുന്നതോ, കസ്റ്റമർ സമ്മറി എടുക്കുന്നതോ, അല്ലെങ്കിൽ സമീപകാല ഇൻവോയ്‌സുകൾ ലിസ്റ്റ് ചെയ്യുന്നതോ ആകാം. അവയെ ടൂളുകളായി മാറ്റി stdio വഴി നൽകുക, എന്നിട്ട് ഒരു സഹപ്രവർത്തകനെ അവ ഉപയോഗിക്കാൻ അനുവദിക്കുക. മോഡൽ എവിടെ നന്നായി പ്രവർത്തിക്കുന്നുവെന്നും എവിടെ തടസ്സപ്പെടുന്നുവെന്നും നിരീക്ഷിക്കുക. മുപ്പത് ടൂളുകൾ പ്ലാൻ ചെയ്യുന്നതിനേക്കാൾ കൂടുതൽ കാര്യങ്ങൾ നിങ്ങൾക്ക് ഈ മൂന്ന് ടൂളുകളിൽ നിന്ന് പഠിക്കാൻ കഴിയും.

MCP എന്നത് ഒരു പാലമാണ്, നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ പകരക്കാരല്ല. നിങ്ങളുടെ PHP കോഡിന് നിങ്ങളുടെ ബിസിനസ്സിനെക്കുറിച്ച് ഇതിനകം അറിയാം. പ്രോട്ടോക്കോൾ മോഡലിനെ അതിലേക്ക് കടന്നുവരാനും ചോദ്യങ്ങൾ ചോദിക്കാനും സഹായിക്കുന്നു എന്ന് മാത്രം.