MCP-യുടെ പുതിയ 2026-07-28 സ്പെസിഫിക്കേഷൻ എല്ലാ session-state ആവശ്യകതകളും ഒഴിവാക്കുന്നു, ഇത് ഓരോ റിക്വസ്റ്റും അതിന് ആവശ്യമായ എല്ലാ ഡാറ്റയും ഉൾക്കൊള്ളാൻ അനുവദിക്കുന്നു. ഒരു stateless protocol-ലേക്കുള്ള ഈ മാറ്റം വഴി ഡെവലപ്പർമാർക്ക് ഓരോ കോളിനും വേണ്ടി ഒരു സിംഗിൾ ഇൻസ്റ്റൻസ് പ്രവർത്തിപ്പിക്കാനും, serverless അല്ലെങ്കിൽ edge നോഡുകളിൽ റൺ ചെയ്യാനും, വിന്യാസത്തിൽ (deployment) ബുദ്ധിമുട്ടുണ്ടാക്കിയിരുന്ന പഴയ sticky-routing, shared-store സംവിധാനങ്ങൾ ഒഴിവാക്കാനും സാധിക്കും.

ഹാൻഡ്‌ഷേക്കുകളിൽ നിന്ന് സ്വയം ഉൾക്കൊള്ളുന്ന കോളുകളിലേക്ക് (From Handshakes to Self-Contained Calls)

ഇതുവരെ, Model Context Protocol (MCP) ഒരു session ID നൽകുന്ന ഹാൻഡ്‌ഷേക്കിന് നിർബന്ധിതമായിരുന്നു. കണക്ഷൻ നിലനിൽക്കുന്ന കാലത്തോളം സെർവറുകൾ ആ ID ഓർത്തു വെക്കേണ്ടതുണ്ടായിരുന്നു. പ്രായോഗികമായി ഇതിനർത്ഥം പ്രോസസ്സുകൾ സജീവമായി നിലനിർത്തുകയോ, ഒരു Redis ക്ലസ്റ്ററിലുടനീളം സ്റ്റേറ്റ് റെപ്ലിക്കേറ്റ് ചെയ്യുകയോ, അല്ലെങ്കിൽ "sticky" റൂട്ടിംഗിനായി ലോഡ് ബാലൻസറുകൾ കോൺഫിഗർ ചെയ്യുകയോ ചെയ്യുക എന്നതായിരുന്നു. ഇതിന്റെ ഫലമായി സങ്കീർണ്ണവും കൂടുതൽ റിസോഴ്സുകൾ ആവശ്യമായതുമായ ഒരു സ്റ്റാക്ക് ഉണ്ടാവുകയും, ഇത് സ്കെയിലിംഗിനെ ബാധിക്കുകയും തിരശ്ചീനമായ വളർച്ച (horizontal growth) ചെലവേറിയതാക്കുകയും ചെയ്തു.

പുതിയ സ്പെസിഫിക്കേഷൻ ഓരോ റിക്വസ്റ്റിനെയും സ്വയം ഉൾക്കൊള്ളുന്നതാക്കുന്നു (self-contained). ഓരോ പേലോഡിലും പ്രോട്ടോക്കോൾ വേർഷനും കോൾ ചെയ്യുന്നയാളുടെ ഐഡന്റിറ്റിയും ഉൾപ്പെടുന്നു, അതിനാൽ സെർവറിന് ആ റിക്വസ്റ്റിനെ ഒരു ഒറ്റത്തവണ ഇടപാടായി (one-off transaction) പരിഗണിക്കാം. സെഷൻ സ്റ്റോറോ, ദീർഘകാല പ്രോസസ്സോ, പ്രത്യേക റൂട്ടിംഗ് നിയമങ്ങളോ ഇനി ആവശ്യമില്ല.

വിന്യാസത്തിന് (Deployment) സ്റ്റേറ്റ്‌ലെസ്സ് പ്രോട്ടോക്കോൾ എന്തിനാണ് പ്രസക്തമാകുന്നത്?

  • Serverless and edge ready – ഒരു റിക്വസ്റ്റ് അതിന് ആവശ്യമായതെല്ലാം ഉൾക്കൊള്ളുന്നതിനാൽ, ഒരു ഫംഗ്ഷന് മുൻകൂട്ടി തയ്യാറാക്കിയ സ്റ്റേറ്റ് (warm-up state) ഇല്ലാതെ തന്നെ പ്രവർത്തിച്ച് മറുപടി നൽകാനും നിർത്താനും സാധിക്കും. ഓരോ ഇൻവോക്കേഷനും (invocation) ചാർജ് ചെയ്യുന്ന പ്രൊവൈഡർമാർ MCP വർക്ക്ലോഡുകൾക്ക് അനുയോജ്യമാകും.
  • ലളിതമായ ലോഡ് ബാലൻസിംഗ് (Simplified load balancing) – സ്റ്റാൻഡേർഡ് L4/L7 ബാലൻസറുകൾക്ക് ട്രാഫിക് ഒരുപോലെ വിതരണം ചെയ്യാൻ കഴിയും; ഒരു ക്ലയന്റിനെ പ്രത്യേക ബാക്കെൻഡുമായി ബന്ധിപ്പിച്ചു നിർത്തേണ്ട (pin) ആവശ്യമില്ല.
  • പ്രവർത്തനപരമായ അധികഭാരം കുറയ്ക്കുന്നു (Reduced operational overhead) – ടീമുകൾക്ക് Redis ക്ലസ്റ്ററുകളോ കസ്റ്റം സെഷൻ-റെപ്ലിക്കേഷൻ കോഡുകളോ ഒഴിവാക്കാം, ഇത് ചെലവും പരാജയസാധ്യതയും കുറയ്ക്കുന്നു.

നിലവിൽ ഒരു ലോഡ് ബാലൻസറിന് പിന്നിൽ MCP പ്രവർത്തിപ്പിക്കുന്ന സ്ഥാപനങ്ങൾക്ക്, ട്രാഫിക് അസമമായി വിതരണം ചെയ്യാൻ ഇടയാക്കുന്ന "sticky" നിയമങ്ങളുടെ ആവശ്യം ഈ മാറ്റം ഇല്ലാതാക്കുന്നു. പ്രതിദിനം ദശലക്ഷക്കണക്കിന് കോളുകൾ വരുന്ന ഉയർന്ന പ്രവർത്തനക്ഷമതയുള്ള (high-throughput) സേവനങ്ങൾക്ക് ഇത് വലിയ ലാഭമുണ്ടാക്കും.

പെർഫോമൻസ്, സുരക്ഷാ മെച്ചപ്പെടുത്തലുകൾ (Performance and Security Upgrades)

ഈ സ്പെസിഫിക്കേഷൻ സ്റ്റേറ്റ്‌ലെസ്സ് സ്വഭാവത്തിന് പുറമെ പ്രോട്ടോക്കോളിനെ കൂടുതൽ ശക്തമാക്കുന്ന ചില മെച്ചപ്പെടുത്തലുകളും ഉൾപ്പെടുത്തുന്നു:

  • TTL-അടിസ്ഥാനമാക്കിയുള്ള കാഷിംഗ് (TTL-based caching) – ടൂൾ, പ്രോംപ്റ്റ് ലിസ്റ്റുകളിൽ ഇപ്പോൾ ഒരു time-to-live ഫീൽഡ് ഉൾപ്പെടുന്നു, ഇത് ക്ലയന്റുകൾക്ക് ഫലങ്ങൾ പ്രാദേശികമായി കാഷ് ചെയ്യാൻ സഹായിക്കുകയും അനാവശ്യമായ റൗണ്ട്-ട്രിപ്പുകൾ ഒഴിവാക്കുകയും ചെയ്യുന്നു.
  • ഹെഡർ അധിഷ്ഠിത റൂട്ടിംഗ് (Header-driven routing) – പുതിയ HTTP ഹെഡറുകൾ റൂട്ടിംഗ് വിവരങ്ങൾ നേരത്തെ തന്നെ ലഭ്യമാക്കുന്നു, അതിനാൽ ഗേറ്റ്‌വേകൾക്ക് മുഴുവൻ JSON ബോഡിയും വിശകലനം ചെയ്യാതെ തന്നെ ട്രാഫിക് ഫോർവേഡ് ചെയ്യാൻ കഴിയും, ഇത് ലേറ്റൻസി (latency) കുറയ്ക്കുന്നു.
  • OAuth/OIDC സുരക്ഷാ ശക്തമാക്കൽ (OAuth/OIDC hardening) – ഐഡന്റിറ്റി ടോക്കണുകൾ കൂടുതൽ കർശനമായ OAuth, OpenID Connect പരിശോധനകൾക്ക് വിധേയമാക്കുന്നു, ഇത് റീപ്ലേ (replay), ടോക്കൺ മോഷണം തുടങ്ങിയ ആക്രമണങ്ങൾ കുറയ്ക്കുന്നു.
  • ഔദ്യോഗിക എക്സ്റ്റൻഷൻ ഫ്രെയിംവർക്ക് (Formal extensions framework) – ടാസ്ക്കുകളും ആപ്പുകളും ഇപ്പോൾ കൃത്യമായ ഒരു എക്സ്റ്റൻഷൻ മോഡലിന് കീഴിലാണ്, ഇത് SDK മെയിന്റനർമാർക്ക് ഭാവിയിലെ ഫീച്ചറുകൾ എളുപ്പത്തിൽ അവതരിപ്പിക്കാൻ സഹായിക്കുന്നു.

ഡെവലപ്പർമാരുടെ മേലുള്ള സ്വാധീനം (Impact on Developers)

SDK ഇക്കോസിസ്റ്റം ഈ മാറ്റം ഇപ്പോൾ തന്നെ പ്രതിഫലിപ്പിക്കുന്നുണ്ട്: TypeScript, Python, Go, C# ലൈബ്രറികൾ പുതിയ റിക്വസ്റ്റ് ഫോർമാറ്റ് ഉപയോഗിക്കുന്നു. ഈ SDK-കളുടെ സംയോജിത ഡൗൺലോഡുകൾ പ്രതിമാസം അഞ്ച്പത് കോടിക്ക് (half a billion) അടുത്തെത്തുന്നു, ഇത് ഈ വർഷത്തിന്റെ തുടക്കത്തേക്കാൾ നാല് മടങ്ങ് കൂടുതലാണ്. ഇത് MCP എത്രത്തോളം വ്യാപകമായി ഉപയോഗിക്കപ്പെടുന്നു എന്നതിന്റെ സൂചനയാണ്.

സ്ഥിരമായ ഒരു സെഷൻ (persistent session) ഉണ്ടെന്ന് കരുതി എഴുതിയ കോഡുകളിൽ ഡെവലപ്പർമാർ മാറ്റം വരുത്തേണ്ടതുണ്ട്. സാധാരണയായി ഇതിനർത്ഥം സെഷനുമായി ബന്ധപ്പെട്ട ഡാറ്റ റിക്വസ്റ്റ് പേലോഡിലേക്കോ അല്ലെങ്കിൽ ഓരോ കോളിനും പരിശോധിക്കുന്ന ഒരു എക്സ്റ്റേണൽ സ്റ്റോറിലേക്കോ മാറ്റുക എന്നതാണ്. ഈ മാറ്റത്തിനുള്ള സമയം പന്ത്രണ്ട് മാസമാണ്, ഇത് ടീമുകൾക്ക് കോഡ് പരിഷ്കരിക്കാനും (refactor), പരിശോധിക്കാനും, പുതിയ രീതി നടപ്പിലാക്കാനും സമയം നൽകുന്നു.

മറുവശം: മൈഗ്രേഷൻ സങ്കീർണ്ണത (Counterpoint: Migration Complexity)

സ്റ്റേറ്റ്‌ലെസ്സ് എന്നത് എളുപ്പത്തിൽ ലഭിക്കുന്ന ഒന്നല്ല. സംഭാഷണ ചരിത്രം (conversation history) പോലുള്ള കാര്യങ്ങൾക്കായി സെർവർ സൈഡ് സ്റ്റേറ്റിനെ ആശ്രയിച്ചിരുന്ന ആപ്ലിക്കേഷനുകൾ ഇപ്പോൾ ആ സ്റ്റേറ്റ് ക്ലയന്റ് സൈഡിലോ അല്ലെങ്കിൽ ഒരു പ്രത്യേക പെർസിസ്റ്റൻസ് ലെയർ വഴിയോ കൈകാര്യം ചെയ്യേണ്ടി വരും.

ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ (What to Watch)

  • Adoption metrics – SDK വേർഷനുകളുടെ ഉപയോഗം നിരീക്ഷിക്കുക; ഇതിലെ കുറവ് മൈഗ്രേഷൻ പ്രക്രിയയിലെ ബുദ്ധിമുട്ടുകളെ സൂചിപ്പിക്കാം.
  • എഡ്ജ് പ്ലാറ്റ്‌ഫോം സപ്പോർട്ട് (Edge platform support) – കൂടുതൽ പ്രൊവൈഡർമാർ MCP-യുമായി പൊരുത്തപ്പെടുന്ന റൺടൈമുകൾ പ്രഖ്യാപിക്കുമ്പോൾ, സെർവർലെസ്സിന്റെ യഥാർത്ഥ സാമ്പത്തിക നേട്ടം വ്യക്തമാകും.
  • സുരക്ഷാ സംഭവ റിപ്പോർട്ടുകൾ (Security incident reports) – ശക്തമായ OAuth/OIDC പ്രക്രിയ ഐഡന്റിറ്റി ആക്രമണങ്ങൾ കുറയ്ക്കുമെങ്കിലും, ഏതൊരു സുരക്ഷാ വീഴ്ചയും പുതിയ സുരക്ഷാ സംവിധാനങ്ങളെ പരീക്ഷിക്കും.

ചുരുക്കത്തിൽ (Takeaway): MCP-യെ സ്റ്റേറ്റ്‌ലെസ്സ് ആക്കുന്നതിലൂടെ, ഈ സ്പെസിഫിക്കേഷൻ പ്രോട്ടോളിനെ ആധുനിക ക്ലൗഡ്-നേറ്റീവ് പാറ്റേണുകളുമായി യോജിപ്പിക്കുന്നു. ഇത് സെഷൻ മാനേജ്‌മെന്റിന്റെ പ്രവർത്തനഭാരം കുറയ്ക്കുന്നതോടൊപ്പം കുറഞ്ഞ ചെലവിലുള്ളതും കൂടുതൽ ഇലാസ്തികതയുള്ളതുമായ (elastic) വിന്യാസ മോഡലുകൾക്കും വഴിതുറക്കുന്നു. കോഡ് പരിഷ്കരിക്കേണ്ടി വരുന്നതും റിക്വസ്റ്റ് സൈസ് കൂടുന്നതും ഒരു ചെറിയ വെല്ലുവിളിയാണെങ്കിലും, ദീർഘകാലാടിസ്ഥാനത്തിൽ ഇത് ഇൻഫ്രാസ്ട്രക്ചറിനോടൊപ്പം എളുപ്പത്തിൽ സ്കെയിൽ ചെയ്യാൻ കഴിയുന്ന ഒരു പ്രോട്ടോക്കൺ വാഗ്ദാനം ചെയ്യുന്നു.