MCP-യുടെ 2026 ജൂലൈ സ്പെസിഫിക്കേഷൻ പ്രോട്ടോക്കോൾ ലെയറിൽ നിന്ന് എല്ലാത്തരം സെഷൻ സ്റ്റേറ്റുകളും (session state) നീക്കം ചെയ്യുന്നു, ഇതിലൂടെ എല്ലാ സ്റ്റേറ്റുകളും മോഡലിന്റെ കോൺടെക്സ്റ്റ് വിൻഡോയിൽ (context window) തന്നെ നിലനിൽക്കാൻ നിർബന്ധിതമാക്കുന്നു. ഈ മാറ്റം ഏതൊരു MCP സെർവറിനും ഏത് അഭ്യർത്ഥനയ്ക്കും മറുപടി നൽകാൻ അനുവദിക്കുന്നു, ഇത് ലോഡ് ബാലൻസറുകൾക്ക് (load balancers), സെർവ്ലെസ് ഫംഗ്ഷനുകൾക്ക് (serverless functions), ഓട്ടോസ്കെയിലിംഗ് കുബർനെറ്റസ് പോഡുകൾക്ക് (autoscaling Kubernetes pods) പിന്നിൽ പൂർണ്ണമായും സ്റ്റേറ്റ്‌ലെസ്സ് (stateless) ആയ വിന്യാസങ്ങൾ സാധ്യമാക്കുന്നു.

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

അതിന്റെ ആദ്യ റിലീസ് മുതൽ, MCP (Model Communication Protocol) ഒന്നിലധികം HTTP കോളുകളിലൂടെ സംഭാഷണത്തിന്റെ അവസ്ഥ (conversational state) ട്രാക്ക് ചെയ്യുന്നതിനായി ഒരു ലഘുവായ സെഷൻ ഹാൻഡ്‌ഷേക്കും (session handshake) Mcp-Session-Id എന്ന ഹെഡറും ഉപയോഗിച്ചിരുന്നു. ഈ ഡിസൈൻ വഴി, ഏതൊക്കെ ടൂൾ ഹാൻഡിലുകൾ (tool handles), സാമ്പിളിംഗ് നിരക്കുകൾ (sampling rates) അല്ലെങ്കിൽ ലോഗിംഗ് മുൻഗണനകൾ (logging preferences) എന്നിവ ഒരു പ്രത്യേക ക്ലയന്റിന്റേതാണെന്ന് സെർവറിന് ഓർമ്മിച്ചുവെക്കാൻ കഴിഞ്ഞിരുന്നു. കൂടാതെ, ഇത് റീസ്യൂമബിൾ (resumable) ആയ Server-Sent Events (SSE) സ്ട്രീമുകളും വാഗ്ദാനം ചെയ്തിരുന്നു, അതിനാൽ ഒരു കണക്ഷൻ തകർന്നാലും എവിടെയാണോ നിർത്തിയത് അവിടെ നിന്ന് വീണ്ടും തുടങ്ങാൻ സാധിക്കുമായിരുന്നു.

2026 ജൂലൈ 28-ലെ സ്പെസിഫിക്കേഷൻ സെഷൻ ഹാൻഡ്‌ഷേക്കിനെ പൂർണ്ണമായും ഒഴിവാക്കുന്നു. ഓരോ അഭ്യർത്ഥനയും ഇപ്പോൾ ഒരു _meta ഫീൽഡിൽ പ്രോട്ടോക്കോൾ വേർഷനും ക്ലയന്റ് കപ്പാബിലിറ്റികളും ഉൾക്കൊള്ളുന്നു, കൂടാതെ Mcp-Session-Id ഹെഡറും ഇല്ലാതാകുന്നു. Roots, sampling, logging ഫീൽഡുകൾ നിർത്തലാക്കി (deprecated) എന്ന് അടയാളപ്പെടുത്തിയിരിക്കുന്നു. ചുരുക്കത്തിൽ, വയർ പ്രോട്ടോക്കോൾ (wire protocol) ഇപ്പോൾ ശുദ്ധമായ റിക്വസ്റ്റ്-റെസ്‌പോൺസ് (request-response) രീതിയിലാണ്; നിലനിർത്താൻ ഒരു "സെഷനും" ഇനിയില്ല.

ഡെവലപ്പർമാർ ഇനി എന്ത് മാറ്റമാണ് വരുത്തേണ്ടത്

സ്റ്റേറ്റ് എന്നത് ഇനി സെർവറിന്റെ ഉത്തരവാദിത്തമല്ല; അത് മോഡലിന്റെ കോൺടെക്സ്റ്റ് വിൻഡോയിലാണ് നിലനിൽക്കുന്നത്. ഒരു മോഡലിന് ഒരു ബാഹ്യ റിസോഴ്‌സിനെ (external resource) പരാമർശിക്കേണ്ടി വരുമ്പോൾ, ഒരു ടൂൾ റിസൾട്ടിന്റെ ഭാഗമായി സെർവറിൽ നിന്ന് വ്യക്തമായ ഒരു ഹാൻഡിൽ (handle) അത് സ്വീകരിക്കണം. അടുത്ത അഭ്യർത്ഥനയിൽ ആ ഹാൻഡിൽ ഒരു ആർഗ്യുമെന്റായി (argument) ഉൾപ്പെടുത്തുന്നു, മോഡൽ അതിനെ മറ്റ് ടോക്കണുകൾ പോലെ തന്നെ കൈകാര്യം ചെയ്യുന്നു.

കോൺടെക്സ്റ്റ് വിൻഡോ എന്നത് നിശ്ചിത വലുപ്പമുള്ള ഒരു ടോക്കൺ ബഫർ ആയതിനാൽ, ഓരോ ഹാൻഡിലും ഉപയോക്താവിന്റെ പ്രോംപ്റ്റുകളുമായോ (user prompts) മോഡൽ ഔട്ട്‌പുട്ടുമായോ മത്സരിക്കുന്ന തരത്തിൽ സ്ഥലം ഉപയോഗിക്കുന്നു.

വിശ്വാസ്യതയിലും (reliability) മാറ്റം വരുന്നു. SSE റീസ്യൂമബിലിറ്റിയോ (resumability) മെസ്സേജ് റീഡെലിവറിയോ ഇല്ലാത്തതിനാൽ, ഒരു സ്ട്രീം തകർന്നാൽ ആ അഭ്യർത്ഥന പൂർണ്ണമായും നഷ്ടപ്പെടും. ക്ലയന്റുകൾ ആ കോൾ ആദ്യം മുതൽ തന്നെ വീണ്ടും തുടങ്ങേണ്ടി വരും. വേഗത്തിലുള്ള, സ്റ്റേറ്റ്‌ലെസ്സ് ക്വറികൾക്ക് (stateless queries) ഇത് കുഴപ്പമില്ലാത്തതാണ്; എന്നാൽ ദീർഘനേരം നീണ്ടുനിൽക്കുന്ന റിട്രീവൽ (retrieval) അല്ലെങ്കിൽ മൾട്ടി-സ്റ്റെപ്പ് ഏജന്റ് ടാസ്ക്കുകൾക്ക് (multi-step agent tasks), ഡെവലപ്പർമാർ സ്വന്തമായി റീട്രൈ ലോജിക് (retry logic) നിർമ്മിക്കുകയോ ജോലിയെ ചെറിയ ഭാഗങ്ങളായി തിരിക്കുകയോ ചെയ്യേണ്ടി വരും.

പൈലറ്റ് പ്രോട്ടോക്കോൾ (Pilot Protocol) ഈ വിടവ് നികത്തുന്നു

MCP-യുടെ സ്റ്റേറ്റ്‌ലെസ്സ് സ്വഭാവം ബോധപൂർവ്വമാണ്, എന്നാൽ ഇത് നെറ്റ്‌വർക്ക് ലെയറിനെ കണക്ഷൻ-ലെവൽ ഐഡന്റിറ്റിയോ (connection-level identity) വിശ്വാസ്യതയുടെ ഉറപ്പുകളോ ഇല്ലാതെയാക്കുന്നു. MCP-ക്ക് താഴെ പ്രവർത്തിക്കുന്ന പൈലറ്റ് പ്രോട്ടോക്കോൾ ഈ വിടവ് നികത്തുന്നു. പൈലറ്റ് ഐഡന്റിറ്റി ഒരിക്കൽ സ്ഥാപിക്കുകയും പാക്കറ്റുകളെ അയക്കുന്നയാളുമായി ബന്ധിപ്പിക്കാൻ എൻക്രിപ്ഷൻ ഉപയോഗിക്കുകയും ചെയ്യുന്നു. MCP-യുടെ കാഴ്ചപ്പാടിൽ, ക്ലയന്റ് ഓരോ തവണയും പുതിയൊരു HTTP അഭ്യർത്ഥന അയക്കുന്നു; പൈലറ്റ് അടിസ്ഥാനപരമായ ട്രാൻസ്‌പോർട്ടിനെ (transport) സുസ്ഥിരമായി നിലനിർത്തുന്നു.

ഈ രണ്ട് പ്രോട്ടോക്കോളുകളും പരസ്പരം പൂരകങ്ങളാണ്: MCP ലളിതവും, ഓരോ അഭ്യർത്ഥനയ്ക്കും ചിലവ് കുറഞ്ഞതും, ഏത് HTTP എൻഡ്‌പോയിന്റിനും പിന്നിൽ എളുപ്പത്തിൽ സ്കെയിൽ ചെയ്യാൻ കഴിയുന്നതുമായി നിലനിൽക്കുന്നു; അതേസമയം, പരമ്പരാഗത സെഷൻ അധിഷ്ഠിത പ്രോട്ടോക്കോളുകൾ ചെയ്തിരുന്ന കഠിനമായ ജോലികൾ പൈലറ്റ് ഏറ്റെടുക്കുന്നു.

സ്കെയിലിംഗിലെ ഗുണങ്ങൾ

  • ലോഡ്-ബാലൻസർ സൗഹൃദം (Load-balancer friendly) – സെഷൻ അഫിനിറ്റി (session affinity) ആവശ്യമില്ല; ഏത് ബാക്കെൻഡും ഏത് അഭ്യർത്ഥനയും കൈകാര്യം ചെയ്യാം.
  • സെർവ്ലെസ് റെഡി (Serverless ready) – ഫംഗ്ഷനുകൾ ആവശ്യാനുസരണം പ്രവർത്തിപ്പിക്കാനും, ഒരു അഭ്യർത്ഥന കൈകാര്യം ചെയ്യാനും, സ്റ്റേറ്റ് ബാക്കി വെക്കാതെ തന്നെ നിർത്താനും സാധിക്കും.
  • കുബർനെറ്റസ് ഓട്ടോസ്കെയിലിംഗ് (Kubernetes autoscaling) – പോഡുകൾ സ്വതന്ത്രമായി കൂട്ടിച്ചേർക്കാനോ നീക്കം ചെയ്യാനോ കഴിയും; കൺട്രോൾ പ്ലേൻ ഇനി സെഷൻ മാപ്പുകൾ ട്രാക്ക് ചെയ്യേണ്ടതില്ല.

വെല്ലുവിളികൾ (The trade-offs)

  • ടോക്കൺ ഓവർഹെഡ് (Token overhead) – ഹാൻഡിലുകളും മറ്റ് സ്റ്റേറ്റുകളും ഇപ്പോൾ മോഡലിന്റെ കോൺടെക്സ്റ്റ് വിൻഡോ ഉപയോഗിക്കുന്നു, ഇത് പ്രോംപ്റ്റും റെസ്‌പോൺസും തമ്മിൽ നേരിട്ട് മത്സരിക്കുന്നു.
  • മോഡൽ അധിഷ്ഠിത കൃത്യത (Model-driven correctness) – മോഡൽ ഹാൻഡിലുകൾ കൃത്യമായി തിരികെ നൽകണം; ഒരു ഹാലുസിനേഷനോ (hallucination) ടൈപ്പോ (typo) വർക്ക്ഫ്ലോ തകരാൻ കാരണമാകും.
  • ഇൻബിൽറ്റ് റീസ്യൂമബിലിറ്റി ഇല്ല (No built-in resumability) – ദീർഘനേരം നീണ്ടുനിൽക്കുന്ന ടാസ്ക്കുകൾ സ്വന്തമായി ചെക്ക്‌പോയിന്റിംഗ് (checkpointing) നടപ്പിലാക്കണം അല്ലെങ്കിൽ പൂർണ്ണമായ റീസ്റ്റാർട്ടിന്റെ റിസ്ക് ഏറ്റെടുക്കണം.
  • ഡയഗ്നോസ്റ്റിക്സ് നിർത്തലാക്കൽ (Deprecation of diagnostics) – Roots, sampling, logging ഫീൽഡുകൾ ഇല്ലാതായതിനാൽ, ആപ്ലിക്കേഷൻ ലെയറിൽ ഇവ ചേർത്തില്ലെങ്കിൽ സൂക്ഷ്മമായ മോണിറ്ററിംഗിനുള്ള സൗകര്യം ഡെവലപ്പർമാർക്ക് നഷ്ടപ്പെടും.

ചുരുക്കത്തിൽ

വയറിൽ നിന്ന് സെഷൻ സ്റ്റേറ്റ് നീക്കം ചെയ്യുന്നതിലൂടെ, MCP 2026-07 പ്രോട്ടോക്കോളിനെ ഏത് ലോഡ് ബാലൻസർ, ഫംഗ്ഷൻ പ്ലാറ്റ്‌ഫോം അല്ലെങ്കിൽ എഡ്ജ് നോഡിന് പിന്നിലും ഇരിക്കാൻ കഴിയുന്ന ഒരു ശുദ്ധമായ HTTP എൻഡ്‌പോയിന്റാക്കി മാറ്റുന്നു. ഇതിന്റെ ഗുണം വ്യക്തമായ സ്കെയിലബിലിറ്റി (scalability) ആണ്; ദോഷം എന്നത് സ്റ്റേറ്റ് ഇപ്പോൾ മോഡലിന്റെ പരിമിതമായ ടോക്കൺ വിൻഡോയിൽ നിലനിൽക്കുന്നു എന്നതും, വിശ്വാസ്യത ക്ലയന്റിലും അടിസ്ഥാനപരമായ പൈലറ്റ് ലെയറിലും ആശ്രയിച്ചിരിക്കുന്നു എന്നതുമാണ്. AI ഏജന്റുകൾ സെക്കൻഡുകളിൽ നിന്ന് മണിക്കൂറുകളിലേക്ക് നീണ്ടുനിൽക്കുമ്പോൾ, ഓരോ അഭ്യർത്ഥനയ്ക്കും കുറഞ്ഞ നിരക്കും ടോക്കൺ ബജറ്റ് സമ്മർദ്ദവും തമ്മിലുള്ള സന്തുലിതാവസ്ഥയാണ് സ്റ്റേറ്റ്‌ലെസ്സ് മോഡൽ ഒരു ശാശ്വത വിജയമാകുമോ എന്ന് തീരുമാനിക്കുന്നത്.