MCP vs API: എന്തുകൊണ്ടാണ് പരമ്പരാഗത API-കൾ AI ഏജന്റുകൾക്ക് പരാജയപ്പെടുന്നത്

പരമ്പരാഗത API-കൾ നിങ്ങളുടെ AI ഏജന്റുകളെ സാവധാനത്തിലാക്കുകയും ചെലവേറിയതാക്കുകയും ചെയ്യുന്നു.

REST, GraphQL എന്നിവ ഉപയോഗിച്ച് വെബ് ആപ്പുകൾ നിർമ്മിച്ചുകൊണ്ട് ഞാൻ വർഷങ്ങൾ ചെലവഴിച്ചു. സ്റ്റേറ്റ് (state) എങ്ങനെ കൈകാര്യം ചെയ്യണമെന്നും പേലോഡുകൾ (payloads) എങ്ങനെ ഒപ്റ്റിമൈസ് ചെയ്യണമെന്നും എനിക്കറിയാം. എന്നാൽ AI ഏജന്റുകൾക്കായി നിർമ്മിക്കുന്നത് വ്യത്യസ്തമാണ്.

നമ്മൾ പലപ്പോഴും LLM-കളെ മനുഷ്യരായ ഡെവലപ്പർമാരെപ്പോലെയാണ് കാണുന്നത്. നമ്മൾ അവയ്ക്ക് ഒരു API എൻഡ്‌പോയിന്റ് നൽകുകയും അവ പ്രവർത്തിക്കുമെന്ന് പ്രതീക്ഷിക്കുകയും ചെയ്യുന്നു. ഇത് ഒരു തെറ്റാണ്.

Model Context Protocol (MCP) ഇത് മാറ്റുന്നു. ഇത് AI കണക്റ്റിവിറ്റിക്കായുള്ള ഒരു ഓപ്പൺ സ്റ്റാൻഡേർഡാണ്. LLM-കളെ നിങ്ങളുടെ ടൂളുകളുമായി ബന്ധിപ്പിക്കാൻ നിങ്ങൾ കസ്റ്റം ഗ്ലൂ കോഡ് (glue code) എഴുതുകയാണെങ്കിൽ, നിങ്ങൾ സാങ്കേതികമായ കടബാധ്യത (technical debt) സൃഷ്ടിക്കുകയാണ്.

എന്തുകൊണ്ടാണ് പരമ്പരാഗത API-കൾ AI ഏജന്റുകൾക്ക് പരാജയപ്പെടുന്നത്:

  • N x M പ്രശ്നം: നിങ്ങൾക്ക് 5 AI ഫ്രെയിംവർക്കുകളും 5 എന്റർപ്രൈസ് ടൂളുകളും ഉണ്ടെങ്കിൽ, നിങ്ങൾ 25 കസ്റ്റം കണക്റ്ററുകൾ എഴുതേണ്ടി വരും. MCP ഇതിനെ ഒരു N + M ആർക്കിടെക്ചറിലേക്ക് മാറ്റുന്നു. ഓരോ ടൂളും ഒരു MCP സെർവർ ഉപയോഗിക്കുന്നു. ഓരോ ഏജന്റും ഒരു MCP ക്ലയന്റ് ഉപയോഗിക്കുന്നു.
  • സ്റ്റാറ്റിക് vs ഡൈനാമിക്: REST API-കൾക്ക് ഹാർഡ്‌കോഡ് ചെയ്ത പാത്തുകൾ ആവശ്യമാണ്. AI ഏജന്റുകൾക്ക് റൺടൈമിൽ (runtime) ടൂളുകൾ കണ്ടെത്തേണ്ടതുണ്ട്. ഡൈനാമിക് ഡിസ്കവറിയിലൂടെ ലഭ്യമായ കപ്പാബിലിറ്റികൾ തത്സമയം കാണാൻ MCP ഏജന്റുകളെ അനുവദിക്കുന്നു.
  • ടോക്കൺ പാഴാകുന്നു: പരമ്പരാഗത API-കൾ പലപ്പോഴും വലിയ JSON പേലോഡുകൾ നൽകുന്നു. വലിയ പേലോഡുകൾ പണം പാഴാക്കുകയും ലേറ്റൻസി (latency) വർദ്ധിപ്പിക്കുകയും ചെയ്യുന്നു. അവ മോഡലിന്റെ ശ്രദ്ധ നഷ്ടപ്പെടുന്ന 'കോൺടെക്സ്റ്റ് റോട്ട്' (context rot) എന്ന അവസ്ഥയ്ക്കും കാരണമാകുന്നു. LLM വിൻഡോകൾക്കായി ഒപ്റ്റിമൈസ് ചെയ്ത ഡാറ്റയാണ് MCP നൽകുന്നത്.
  • സ്റ്റേറ്റ്‌ലെസ്നെസ് (Statelessness): REST സ്റ്റേറ്റ്‌ലെസ് ആണ്. AI ഏജന്റുകൾ ചിന്തയുടെയും പ്രവൃത്തിയുടെയും തുടർച്ചയായ ഒരു ലൂപ്പിലാണ് പ്രവർത്തിക്കുന്നത്. വലിയ ഡാറ്റ വീണ്ടും അയക്കാതെ തന്നെ കോൺടെക്സ്റ്റ് നിലനിർത്താൻ MCP സ്റ്റേറ്റ്‌ഫുൾ സെഷനുകൾ (stateful sessions) ഉപയോഗിക്കുന്നു.

MCP മൂന്ന് പ്രധാന ഭാഗങ്ങൾ ഉപയോഗിക്കുന്നു:

  • ടൂളുകൾ (Tools): ഒരു SQL ക്വറി റൺ ചെയ്യുന്നത് പോലുള്ള മോഡൽ നടത്തുന്ന പ്രവർത്തനങ്ങൾ.
  • റിസോഴ്സുകൾ (Resources): ലോഗ് ഫയലുകൾ അല്ലെങ്കിൽ ഡോക്യുമെന്റുകൾ പോലുള്ള റീഡ്-ഒൺലി (read-only) ഡാറ്റ.
  • പ്രോംപ്റ്റുകൾ (Prompts): മോഡലിന്റെ യുക്തിചിന്തയെ സഹായിക്കുന്ന ടെംപ്ലേറ്റുകൾ.

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

നിങ്ങളുടെ LLM കോളുകൾക്കായി JSON സ്ട്രിംഗിഫൈ (stringify) ചെയ്യാൻ കസ്റ്റം ഫംഗ്ഷനുകൾ എഴുതുന്നത് നിർത്തുക. ഏജന്റിക് ഭാവിയിലേക്ക് (agentic future) വളരാൻ കഴിയുന്ന ഒരു ആർക്കിടെക്ചർ നിർമ്മിക്കുക.

നിങ്ങളുടെ അഭിപ്രായങ്ങൾ എന്താണ്? നിങ്ങൾ ഇപ്പോൾ MCP ഉപയോഗിക്കുന്നുണ്ടോ അതോ കസ്റ്റം ഫംഗ്ഷൻ കോളിംഗിൽ തന്നെ തുടരുകയാണോ?

Source: https://dev.to/chaudharidevam/mcp-vs-api-why-traditional-apis-are-failing-ai-agents-28m8

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