MCP ടൂൾ അതിന്റെ സ്കീമ മാറ്റി. നിങ്ങളുടെ ഏജന്റ് അത് ശ്രദ്ധിച്ചില്ല.

നിങ്ങളുടെ ടൂൾ കോൾ (tool call) പരാജയപ്പെട്ടില്ല. അത് 200 സ്റ്റാറ്റസ് കോഡും സാധുവായ JSON-ഉം നൽകി.

എന്നാൽ അത് തെറ്റായ കോൺട്രാക്റ്റിന് (contract) विरुद्धയാണ് പ്രവർത്തിച്ചത്. മൂന്ന് ദിവസം മുമ്പ് അപ്‌സ്ട്രീം സെർവർ ഒരു ഫീൽഡിന്റെ പേര് മാറ്റി. നിങ്ങളുടെ ഏജന്റ് പഴയ പേര് തന്നെ അയച്ചുകൊണ്ടിരുന്നു. സെർവർ അത് നിശബ്ദമായി ഒഴിവാക്കി. ഫലം ശൂന്യമായി വന്നു. ഒരു എററും (error) കാണിച്ചില്ല. ഒരാളും ഒരാഴ്ചത്തേക്ക് അത് ശ്രദ്ധിച്ചതുമില്ല.

ഇതാണ് സൈലന്റ് ഫെയിലിയർ (silent failure). ലോഗുകൾ ചുവപ്പായി മാറുന്ന തരത്തിലുള്ള വലിയ പരാജയങ്ങളല്ല ഇത്. സെർവർ ശരിയാണെന്ന് തോന്നിപ്പിക്കുമെങ്കിലും ഡാറ്റ തെറ്റായി വരുന്ന അവസ്ഥയാണിത്.

കോൾ ചെയ്യുന്ന ഇടയിലുള്ള സമയങ്ങളിൽ MCP സെർവറുകൾക്ക് ഒരു ടൂൾ കോൺട്രാക്റ്റ് മാറ്റാൻ കഴിയും. അവയ്ക്ക് ഒരു പാരാമീറ്റർ (parameter) പുനർനാമകരണം ചെയ്യാനോ ഒരു ഫീൽഡ് വിവരണത്തിൽ മാറ്റം വരുത്താനോ സാധിക്കും. ഈ മാറ്റങ്ങൾ പലപ്പോഴും ഘടനാപരമായി (structurally) ശരിയായിരിക്കും. JSON വാലിഡേഷൻ (validation) വിജയിക്കും. സെർവർ 200 മറുപടി നൽകും. ഒരു എററും ഇല്ലാതെ നിങ്ങളുടെ ഏജന്റ് തെറ്റായ ഡാറ്റ ഉപയോഗിച്ച് പ്രവർത്തിക്കും.

പരിഹാരം ലളിതമാണ്: • ഓരോ ടൂൾ കോൺട്രാക്റ്റിന്റെയും ഒരു SHA-256 ഹാഷ് (hash) നിശ്ചയിക്കുക. • ആ ഹാഷിൽ സ്കീമയും വിവരണവും (description) ഉൾപ്പെടുത്തുക. • ഓരോ കോളിന് മുമ്പും ഹാഷ് പരിശോധിക്കുക. • കോൺട്രാക്റ്റിൽ മാറ്റം വന്നാൽ കോൾ നിർത്തുക.

ഒരു ടൂൾ മറുപടി നൽകുന്നുണ്ടോ എന്നതിലാണ് നമ്മൾ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നത്. നമ്മൾ സ്റ്റാറ്റസ് കോഡുകൾ പരിശോധിക്കുന്നു. ടൈമൗട്ടുകൾ (timeouts) സെറ്റ് ചെയ്യുന്നു. 5xx എററുകൾ വരുമ്പോൾ വീണ്ടും ശ്രമിക്കുന്നു (retry). ഏജന്റ് സ്കീമ മനസ്സിലാക്കിയ സമയത്തിനും കോൾ ചെയ്യുന്ന സമയത്തിനും ഇടയിൽ കോൺട്രാക്റ്റിൽ മാറ്റം വന്നിട്ടുണ്ടോ എന്ന് ആരും പരിശോധിക്കാറില്ല.

ഒരു MCP സെർവർ tools/list വഴി ടൂളുകൾ ലഭ്യമാക്കുന്നു. ഓരോ ടൂളിനും ഒരു inputSchema-യും വിവരണവും ഉണ്ടായിരിക്കും. ഒരു സെഷന്റെ തുടക്കത്തിൽ നിങ്ങളുടെ ഏജന്റ് ഇത് ഒരിക്കൽ വായിക്കുന്നു.

സെർവർ അപ്‌ഡേറ്റ് ചെയ്യുമ്പോൾ ഇവ സംഭവിക്കാം:

  • അധിക പ്രോപ്പർട്ടികൾ (properties) നിലനിർത്തിക്കൊണ്ട് തന്നെ ഒരു പാരാമീറ്ററിന്റെ പേര് മാറ്റുക (ഉദാഹരണത്തിന് query എന്നത് q എന്നാക്കി മാറ്റുക). പഴയ പാരാമീറ്റർ നിശബ്ദമായി ഒഴിവാക്കപ്പെടും.
  • ഒരു ഫീൽഡിന്റെ അർത്ഥം മാറ്റുക. ഒരു ലിമിറ്റ് "max results" എന്നതിൽ നിന്ന് "page index" എന്നതിലേക്ക് മാറാം. അതിന്റെ ടൈപ്പ് ഒരു integer ആയി തുടരുന്നതിനാൽ വാലിഡേഷൻ വിജയിക്കും.
  • ഒരു enum പരിമിതപ്പെടുത്തുക. സാധുവായ ഒരു വാല്യൂ പുതിയൊരു ഡിഫോൾട്ട് (default) വാല്യൂവിലേക്ക് മാറാം.

ഒരു ലിസ്റ്റിൽ മാറ്റം വന്നാൽ സെർവർ ക്ലയന്റിനെ അറിയിക്കണം (SHOULD) എന്നാണ് MCP സ്പെക് (spec) പറയുന്നത്. എന്നാൽ അത് നിർബന്ധമായും (MUST) ചെയ്യണമെന്നില്ല. പല സെർവറുകളും ഈ അറിയിപ്പ് നൽകില്ല. അവർ നൽകിയാൽ പോലും, ഒരു പ്രത്യേക ടൂൾ സ്കീമ മാറിയെന്ന് അവർ അറിയിച്ചേക്കില്ല.

ഘടനാപരമായ വാലിഡേഷനെ (structural validation) മാത്രം ആശ്രയിക്കുന്നത് നിർത്തുക. അർത്ഥത്തിലുണ്ടാകുന്ന മാറ്റങ്ങൾ തിരിച്ചറിയാൻ അതിന് കഴിയില്ല.

നിങ്ങളുടെ MCP ടൂളുകളെ സോഫ്റ്റ്‌വെയർ ഡിപെൻഡൻസികൾ (software dependencies) പോലെ കാണുക. ഒരു lockfile രീതി ഉപയോഗിക്കുക. ആദ്യമായി ബന്ധപ്പെടുമ്പോൾ, ടൂളിന്റെ സ്കീമയുടെയും വിവരണത്തിന്റെയും ഒരു SHA-256 ഹാഷ് എടുക്കുക. ഓരോ കോളിന് മുമ്പും ഹാഷ് വീണ്ടും കണക്കാക്കുക. അവ ഒന്നുതന്നെയാണെങ്കിൽ മുന്നോട്ട് പോവുക. അവ ഒത്തുപോകുന്നില്ലെങ്കിൽ മാറ്റം (drift) ശ്രദ്ധയിൽപ്പെടുത്തി പ്രവർത്തനം നിർത്തുക.

വിവരണത്തിന്റെ (description) ഹാഷ് എടുക്കുന്നതാണ് ഇതിലെ രഹസ്യം. ഒരു പാരാമീറ്റർ "max results" എന്നതിൽ നിന്ന് "page index" എന്നതിലേക്ക് മാറിയാൽ, സ്കീമ ഒന്നുതന്നെയായി തോന്നും. എന്നാൽ വാക്കുകൾ മാറിയതുകൊണ്ട് ഹാഷ് മാറും. വാലിഡേഷന് കണ്ടെത്താൻ കഴിയാത്ത സെമാന്റിക് ഡ്രിഫ്റ്റ് (semantic drift) ഇത് പിടികൂടും.

കോൺട്രാക്റ്റിൽ മാറ്റം വരുമ്പോൾ ഊഹിച്ചു പ്രവർത്തിക്കരുത്. അന്ധമായി വീണ്ടും ശ്രമിക്കരുത് (retry). പ്രവർത്തനം നിർത്തി, വ്യത്യാസം ലോഗ് ചെയ്യുക, കോൺട്രാക്റ്റ് ശരിയാക്കുക.

Source: https://dev.to/0012303/the-mcp-tool-your-agent-calls-changed-its-schema-it-didnt-notice-5g6m

Optional learning community: https://t.me/GyaanSetuAi