MCP വേർഷൻ 2, 2026 ജൂലൈ 28-ന് നിലവിൽ വരുന്നു. Model Context Protocol (MCP)-നെ സ്റ്റിക്കി-സെഷൻ (sticky-session) സെർവറുകളുമായി ബന്ധിപ്പിച്ചിരുന്ന എല്ലാ ഹാൻഡ്‌ഷേക്കുകളും (handshake), session-ID ഹെഡറുകളും, മൂന്ന് പഴയ സബ്സിസ്റ്റംകളും (legacy subsystems) ഇതിൽ ഒഴിവാക്കുന്നു. പ്രോട്ടോക്കോൾ പൂർണ്ണമായും സ്റ്റേറ്റ്‌ലെസ്സ് (stateless) ആയി മാറുന്നു, അതിനാൽ ക്ലയന്റ് സ്റ്റേറ്റ് നിലനിർത്താതെ തന്നെ ഏതൊരു ഓട്ടോസ്കെയിൽഡ് (autoscaled) അല്ലെങ്കിൽ സെർവ്ലെസ് (serverless) ഇൻസ്റ്റൻസിനും ഏത് അഭ്യർത്ഥനയും (request) കൈകാര്യം ചെയ്യാൻ കഴിയും.

ഈ മാറ്റം പ്രധാനമാകുന്നത് എന്തുകൊണ്ട്

MCP v1-ൽ ഒരു ക്ലയന്റ് initialize ഹാൻഡ്‌ഷേക്കിലൂടെ ഒരു സെഷൻ ആരംഭിക്കാൻ നിർബന്ധിതമായിരുന്നു; തുടർന്ന് സെർവർ ഒരു Mcp-Session-Id അനുവദിക്കും. അതിനുശേഷമുള്ള ഓരോ കോളും ആ ഹെഡർ ഉൾക്കൊള്ളേണ്ടതുണ്ടായിരുന്നു, ഇത് ഉപയോക്താവിനെ ഒരു സിംഗിൾ ബാക്കെൻഡ് നോഡിൽ തന്നെ ഒതുക്കിനിർത്തുന്നു. ലോഡ് ബാലൻസറുകൾക്ക് (Load balancers) സെഷൻ അഫിനിറ്റി (session affinity) നടപ്പിലാക്കേണ്ടി വരുന്നത് ലേറ്റൻസിനും (latency) പ്രവർത്തനപരമായ തടസ്സങ്ങൾക്കും കാരണമാകുന്നു.

സ്റ്റേറ്റ്‌ലെസ്സ് (Statelessness) ആയ രീതി ഈ തടസ്സങ്ങൾ ഇല്ലാതാക്കുന്നു. എല്ലാ കോൺടെക്സ്റ്റുകളും (context) ഇപ്പോൾ ഓരോ HTTP കോളോടൊപ്പവും വരുന്ന പ്രത്യേക മെറ്റാ ഫീൽഡുകളിൽ (meta fields) ആണ് സൂക്ഷിക്കുന്നത്. ഒരു റിക്വസ്റ്റ് ഏത് ഇൻസ്റ്റൻസിലും എത്തുകയും പ്രോസസ്സ് ചെയ്യപ്പെടുകയും ചെയ്യാം, മറുപടി (response) അയച്ചാലുടൻ ആ ഇൻസ്റ്റൻസ് ഒഴിവാക്കാനും സാധിക്കും. സെർവ്ലെസ് പ്ലാറ്റ്‌ഫോമുകൾ, കണ്ടെയ്നർ-ഓർക്കസ്ട്രേറ്റഡ് ക്ലസ്റ്ററുകൾ (container-orchestrated clusters), അല്ലെങ്കിൽ ആവശ്യാനുസരണം പോഡുകൾ (pods) പ്രവർത്തിപ്പിക്കുന്ന മറ്റേതെങ്കിലും എൻവയോൺമെന്റുകൾ ഉപയോഗിക്കുന്ന ടീമുകൾക്ക് ഇപ്പോൾ ഈ പ്രോട്ടോക്കളിനെ അവരുടെ ഇൻഫ്രാസ്ട്രക്ചറിന് അനുസൃതമായി മാറ്റാൻ കഴിയും.

ഒഴിവാക്കപ്പെടുന്നവ (What’s being retired)

പെർസിസ്റ്റന്റ് കണക്ഷനുകളെ (persistent connections) ആശ്രയിച്ചിരുന്ന മൂന്ന് സബ്സിസ്റ്റംകൾ ഔദ്യോഗികമായി ഒഴിവാക്കി (deprecated):

  • Sampling – v1-ൽ, ഒരു സെർവറിന് ടെക്സ്റ്റ് ജനറേറ്റ് ചെയ്യാൻ ക്ലയന്റിനോട് ആവശ്യപ്പെടാൻ കഴിയുമായിരുന്നു, ഇതിന് ഒരു ഓപ്പൺ സെഷൻ ആവശ്യമായിരുന്നു. എന്നാൽ v2-ൽ, സെർവർ നേരിട്ട് ലാർജ് ലാംഗ്വേജ് മോഡൽ (LLM) പ്രൊവൈഡറെ വിളിക്കണമെന്നോ അല്ലെങ്കിൽ InputRequiredResult പാറ്റേൺ ഉപയോഗിക്കണമെന്നോ പ്രതീക്ഷിക്കുന്നു; ഇതിൽ ക്ലയന്റ് ഒരു ഫോളോ-അപ്പ് റിക്വസ്റ്റിലൂടെ വിട്ടുപോയ ഇൻപുട്ട് നൽകുന്നു.
  • Roots – മുമ്പ്, ക്ലയന്റുകൾ അയക്കുന്ന URIs ബാഹ്യ റിസോഴ്‌സുകളെക്കുറിച്ചുള്ള സെർവറിന്റെ കാഴ്ചപ്പാടിനെ പരിമിതപ്പെടുത്തിയിരുന്നു. പുതിയ രീതിയിൽ ഈ URIs ടൂൾ പാരാമീറ്ററുകളായി (tool parameters) നൽകുകയോ അല്ലെങ്കിൽ റിക്വസ്റ്റിന്റെ റിസോഴ്‌സ് ഫീൽഡുകളിൽ ഉൾപ്പെടുത്തുകയോ ചെയ്യുന്നു, ഇത് പ്രത്യേകമായ "roots" നെഗോഷ്യേഷൻ ഘട്ടം ഒഴിവാക്കുന്നു.
  • Logging – പ്രോട്ടോക്കോൾ തലത്തിലുള്ള ലോഗിംഗ് ഹെഡറുകൾ ഇല്ലാതാകുന്നു. ലോക്കൽ ഡീബഗ്ഗിംഗിനായി (local debugging) stderr-ലേക്ക് എഴുതുകയോ അല്ലെങ്കിൽ പ്രൊഡക്ഷൻ ഒബ്സർവബിലിറ്റിക്കായി (production observability) OpenTelemetry ഉപയോഗിക്കുകയോ ചെയ്യുക.

ഈ ഒഴിവാക്കൽ കാലയളവ് (deprecation window) ഒരു വർഷമാണ്. ഒഴിവാക്കപ്പെട്ട ഫീച്ചറുകൾ ആ കാലയളവിലുടനീളം പ്രവർത്തിക്കും, ഇത് പ്രോട്ടോക്കോൾ അവയെ നിരസിക്കുന്നതിന് മുമ്പ് കോഡ് റീഫാക്ടർ (refactor) ചെയ്യാൻ ടീമുകൾക്ക് സമയം നൽകുന്നു.

സ്റ്റേറ്റ്‌ലെസ്സ് കൂടാതെ പുതിയതായി എന്തൊക്കെയാണ്

MCP v2 രണ്ട് ഔദ്യോഗിക എക്സ്റ്റൻഷനുകൾ (extensions) കൂടി ചേർക്കുന്നു:

  • MCP Apps – പ്രോട്ടോക്കോളിന് ഇൻവോക്ക് ചെയ്യാൻ കഴിയുന്ന സെർവർ-റെൻഡർ ചെയ്ത യൂസർ ഇന്റർഫേസുകളെ വിവരിക്കാനുള്ള ലളിതമായ മാർഗ്ഗം.
  • Tasks – ഒന്നിലധികം റിക്വസ്റ്റ്-റെസ്പോൺസ് സൈക്കിളുകളിലായി നീണ്ടുനിൽക്കുന്ന പ്രവർത്തനങ്ങൾ കൈകാര്യം ചെയ്യാനുള്ള ഒരു പാറ്റേൺ.

രണ്ട് എക്സ്റ്റൻഷനുകളും സ്റ്റേറ്റ്‌ലെസ്സ് റിക്വസ്റ്റ് മോഡൽ അനുസരിച്ചുള്ളവയാണ് കൂടാതെ അവ ഹിഡൻ സെഷൻ സ്റ്റേറ്റ് (hidden session state) ഒഴിവാക്കുന്നു.

റിസ്കുകളും പ്രതിരോധങ്ങളും (Risks and counter-points)

ഈ മാറ്റം ഒരു 'പ്ലഗ് ആൻഡ് പ്ലേ' (plug-and-play) അപ്‌ഗ്രേഡ് അല്ല. v2 SDK-കൾ ഇപ്പോഴും ബീറ്റ (beta) ഘട്ടത്തിലാണ്, അവയുടെ പബ്ലിക് API-കളിൽ സ്റ്റേബിൾ റിലീസ് വരുന്നതിന് മുമ്പ് മാറ്റങ്ങൾ വരാം. ബ്രേക്കിംഗ് ചേഞ്ചുകൾ (breaking changes) സഹിക്കാൻ കഴിയാത്ത പ്രൊഡക്ഷൻ വർക്ക്ലോഡുകൾക്കായി, v2 SDK സ്റ്റേബിൾ ആകുന്നത് വരെ v1 SDK ഉപയോഗിക്കുക.

ഡെവലപ്പർമാർ നിലവിലുള്ള കോഡിൽ ഒഴിവാക്കപ്പെട്ട മൂന്ന് സബ്സിസ്റ്റംകളിൽ ഏതെങ്കിലും ഉണ്ടോ എന്ന് പരിശോധിക്കേണ്ടതുണ്ട് (audit).

പ്രായോഗികമായ ഒരു മൈഗ്രേഷൻ റോഡ്മാപ്പ് (A pragmatic migration roadmap)

  1. ഇന്ന് തന്നെ പരിശോധിക്കുക (Audit today) – ഹാൻഡ്‌ഷേക്ക്, Mcp-Session-Id, സാമ്പിളിംഗ് കോളുകൾ, റൂട്ട്സ് URIs, പ്രോട്ടോക്കോൾ തലത്തിലുള്ള ലോഗിംഗ് എന്നിവ നിങ്ങളുടെ സർവീസുകളിൽ ഉപയോഗിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക. സ്റ്റേറ്റ്‌ലെസ്സ് മോഡലിൽ തകരാറിലാകാൻ സാധ്യതയുള്ള കോഡുകൾ തിരിച്ചറിയുക.
  2. അതിപ്രധാനമല്ലാത്ത ഒരു നോഡിൽ ടെസ്റ്റ് ചെയ്യുക – ഒരു സ്റ്റേബിൾ v2 SDK റിലീസ് ചെയ്യുമ്പോൾ, ഒരു സാൻഡ്‌ബോക്സ് (sandbox) സെർവർ സജ്ജമാക്കി ഒരു ടെസ്റ്റ് ക്ലയന്റിലേക്ക് അത് ബന്ധിപ്പിക്കുക, കൂടാതെ ആവശ്യമായ എല്ലാ മെറ്റാ ഫീൽഡുകളും കൃത്യമായി വ്യാഖ്യാനിക്കപ്പെടുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക.
  3. ഡെഡ്‌ലൈനിന് മുമ്പ് പൂർണ്ണമായ മൈഗ്രേഷൻ പൂർത്തിയാക്കുക – റൺടൈം റിജക്ഷനുകൾ (runtime rejections) ഒഴിവാക്കാൻ, ഒരു വർഷത്തെ ഗ്രേസ് പിരീഡ് അവസാനിക്കുന്നതിന് മുമ്പ് എല്ലാ പ്രൊഡക്ഷൻ നോഡുകളിലും മാറ്റം പൂർത്തിയാക്കുക.

ഇനി ശ്രദ്ധിക്കേണ്ടവ

  • സ്റ്റേബിൾ SDK റിലീസ് – ബീറ്റ SDK-കൾ ഫ്രീസ് ചെയ്യുകയും ഒരു വേർഷൻ ചെയ്ത സ്റ്റേബിൾ പാക്കേജ് പ്രസിദ്ധീകരിക്കുകയും ചെയ്യും. ഏതൊരു ക്രിട്ടിക്കൽ ഡിപ്ലോയ്മെന്റിനും ആ വേർഷൻ സുരക്ഷിതമായ ലക്ഷ്യമായിരിക്കും.

ഈ മാറ്റത്തിന് കോഡ് മാറ്റങ്ങളും ബീറ്റ-SDK പരീക്ഷണങ്ങളും ആവശ്യമായി വരും, എന്നാൽ ഇതിലൂടെ LLM അധിഷ്ഠിത ആപ്ലിക്കേഷനുകൾക്ക് കൂടുതൽ വൃത്തിയുള്ളതും സ്കെയിലബിൾ ആയതുമായ (scalable) ഒരു ഇന്റഗ്രേഷൻ പോയിന്റ് ലഭിക്കും.

ചുരുക്കത്തിൽ (Takeaway): നിങ്ങളുടെ സ്റ്റാക്ക് ഇപ്പോഴും MCP ഹാൻഡ്‌ഷേക്കുകളെയോ ഒഴിവാക്കപ്പെട്ട മൂന്ന് സബ്സിസ്റ്റംകളെയോ ആശ്രയിച്ചാണ് പ്രവർത്തിക്കുന്നതെങ്കിൽ, ഇപ്പോൾ തന്നെ പരിശോധന തുടങ്ങുക; ഒരു വർഷത്തെ ഗ്രേസ് പിരീഡ് ധാരാളമാണ്, എന്നാൽ യഥാർത്ഥ ചെലവ് ഡെഡ്‌ലൈൻ അല്ല, മറിച്ച് കോഡ് റീഫാക്റ്റർ ചെയ്യാനുള്ള പരിശ്രമമാണ്.