MCP-ன் புதிய 2026-07-28 விவரக்குறிப்பு (specification) அனைத்து session-state தேவைகளையும் நீக்குகிறது, இதன் மூலம் ஒவ்வொரு கோரிக்கையும் (request) அதற்குத் தேவையான அனைத்து தரவுகளையும் சுமந்து செல்ல அனுமதிக்கிறது. இந்த stateless protocol-க்கான மாற்றம், டெவலப்பர்கள் ஒவ்வொரு அழைப்பிற்கும் (call) ஒரு தனி இன்ஸ்டன்ஸை உருவாக்கவும், serverless அல்லது edge nodes-களில் இயக்கவும் வழிவகை செய்கிறது. மேலும், இது deployment-ல் பெரும் சிரமமாக இருந்த பழைய sticky-routing மற்றும் shared-store முறைகளைத் தவிர்க்க உதவுகிறது.

Handshakes முதல் சுயாதீனமான அழைப்புகள் (Self-Contained Calls) வரை

இதுவரை, Model Context Protocol (MCP), ஒரு session ID-யை வழங்கும் handshake முறையைத் திணிக்கச் செய்தது. இணைப்பின் காலம் முழுவதும் சர்வர்கள் அந்த ID-யை நினைவில் வைத்திருக்க வேண்டியிருந்தது. நடைமுறையில், இது செயல்முறைகளை (processes) உயிர்ப்புடன் வைத்திருக்கவும், Redis cluster முழுவதும் நிலையை (state) நகலெடுக்கவும் அல்லது "sticky" routing-க்காக load balancers-களை உள்ளமைக்கவும் (configure) வேண்டியிருந்தது. இதன் விளைவாக, சிக்கலான மற்றும் அதிக வளங்களைச் செலவழிக்கும் ஒரு கட்டமைப்பு உருவானது, இது அளவிடுதலை (scaling) பாதிப்பதோடு கிடைமட்ட வளர்ச்சியை (horizontal growth) செலவு மிகுந்ததாக மாற்றியது.

புதிய விவரக்குறிப்பு ஒவ்வொரு கோரிக்கையையும் சுயாதீனமானதாக (self-contained) மாற்றுகிறது. ஒவ்வொரு payload-லும் நெறிமுறை பதிப்பு (protocol version) மற்றும் அழைப்பவரின் அடையாளம் (caller’s identity) ஆகியவை அடங்கும், இதனால் சர்வர் அந்த கோரிக்கையை ஒரு முறை மட்டும் நடக்கும் பரிவர்த்தனையாக (one-off transaction) கருத முடியும். இனி session store, நீண்ட காலம் இயங்கும் process அல்லது சிறப்பு routing விதிகள் தேவையில்லை.

Deployment-க்கு Stateless ஏன் முக்கியம்

  • Serverless மற்றும் edge தயார்நிலை – ஒரு கோரிக்கை அதற்குத் தேவையான அனைத்தையும் சுமந்து செல்வதால், ஒரு function-ஆல் warm-up state இல்லாமலேயே தொடங்கி, பதிலளித்து, முடிவடைய முடியும். அழைப்பிற்கு ஏற்ப கட்டணம் வசூலிக்கும் (per-invocation) வழங்குநர்கள் MCP workloads-களுக்குச் சிறந்த தேர்வாகிவிடுவார்கள்.
  • எளிமையாக்கப்பட்ட load balancing – நிலையான L4/L7 balancers போக்குவரத்தை சீராகப் பிரிக்க முடியும்; ஒரு கிளையண்டை ஒரு குறிப்பிட்ட backend-உடன் இணைத்து வைத்திருக்க வேண்டிய அவசியம் இல்லை.
  • குறைக்கப்பட்ட செயல்பாட்டுச் சுமை (operational overhead) – குழுக்கள் Redis clusters அல்லது தனிப்பயனாக்கப்பட்ட session-replication குறியீடுகளைத் தவிர்க்கலாம், இது செலவு மற்றும் தோல்விக்கான வாய்ப்ப both (இரண்டையும்) குறைக்கிறது.

ஏற்கனவே ஒரு load balancer-க்கு பின்னால் MCP-யை இயக்கும் நிறுவனங்களுக்கு, இந்த மாற்றம் பெரும்பாலும் சீரற்ற போக்குவரத்து விநியோகத்தை ஏற்படுத்தும் "sticky" விதிகளின் தேவையை நீக்குகிறது. ஒரு நாளைக்கு மில்லியன் கணக்கான அழைப்புகளைப் பெறும் அதிகப்படியான சேவை வழங்கும் (high-throughput services) தளங்களுக்கு இந்தச் சேமிப்பு மிகவும் குறிப்பிடத்தக்கது.

செயல்திறன் மற்றும் பாதுகாப்பு மேம்பாடுகள்

இந்த விவரக்குறிப்பு அதன் statelessness நிலையைத் தாண்டி, நெறிமுறையை வலுப்படுத்தும் கூடுதல் மேம்பாடுகளைச் சேர்க்கிறது:

  • TTL-அடிப்படையிலான caching – Tool மற்றும் prompt பட்டியல்கள் இப்போது time-to-live புலத்தை (field) கொண்டுள்ளன, இது கிளையண்ட்கள் முடிவுகளை உள்ளூர் ரீதியாக (locally) cache செய்ய அனுமதிப்பதோடு தேவையற்ற round-trips-ஐத் தவிர்க்கிறது.
  • Header-அடிப்படையிலான routing – புதிய HTTP headers routing தகவல்களை முன்கூட்டியே வெளிப்படுத்துகின்றன, இதனால் gateways முழு JSON body-யையும் பகுப்பாய்வு செய்யாமலேயே போக்குவரத்தை அனுப்ப முடியும், இது தாமதத்தை (latency) மில்லி விநாடிகள் குறைக்கிறது.
  • OAuth/OIDC வலுப்படுத்துதல் – அடையாள டோக்கன்கள் (Identity tokens) கடுமையான OAuth மற்றும் OpenID Connect சோதனைகளுக்கு உட்படுத்தப்படுகின்றன, இது replay மற்றும் token-theft தாக்குதல்களுக்கான பாதிப்பைக் குறைக்கிறது.
  • முறையான extensions framework – Tasks மற்றும் Apps இப்போது ஒரு வரையறுக்கப்பட்ட extension மாடலின் கீழ் வருகின்றன, இது SDK பராமரிப்பாளர்களுக்கு எதிர்கால அம்சங்களை எளிதாக அறிமுகப்படுத்த உதவுகிறது.

டெவலப்பர்களுக்கான தாக்கம்

SDK சுற்றுச்சூழல் அமைப்பு ஏற்கனவே இந்த மாற்றத்தைப் பிரதிபலிக்கிறது: TypeScript, Python, Go மற்றும் C# libraries புதிய கோரிக்கை வடிவமைப்பை வெளியிடுகின்றன. இந்த SDK-களின் மொத்த பதிவிறக்கங்கள் மாதத்திற்கு அரை பில்லியன் நெருங்குகின்றன, இது ஆண்டின் தொடக்கத்தை விட நான்கு மடங்கு அதிகம், இது MCP எவ்வளவு பரவலாக ஏற்றுக்கொள்ளப்படுகிறது என்பதைக் காட்டுகிறது.

ஒரு நிலையான session-ஐ (persistent session) எதிர்பார்த்துக் கொண்டிருந்த எந்தவொரு குறியீட்டையும் டெவலப்பர்கள் மாற்றியமைக்க வேண்டும். பொதுவாக, இது session-குறிப்பிட்ட தரவை request payload-க்குள் அல்லது ஒவ்வொரு அழைப்பிற்கும் ஒரு தனிப்பட்ட வெளிப்புறச் சேமிப்பகத்திற்கு (external store) மாற்றுவதைக் குறிக்கும். இந்த மாற்றத்திற்கான கால அவகாசம் பன்னிரண்டு மாதங்கள் ஆகும், இது குழுக்கள் குறியீட்டை மறுசீரமைக்கவும் (refactor), சோதனை செய்யவும் மற்றும் புதிய முறையைச் செயல்படுத்தவும் போதுமான நேரத்தை வழங்கும்.

மறுப்பு: இடமாற்ற சிக்கல்கள் (Migration Complexity)

Statelessness என்பது எளிதான விஷயம் அல்ல. முந்தைய காலங்களில் உரையாடல் வரலாறு (conversation history) போன்ற விஷயங்களுக்காக சர்வர் பக்க நிலையை (server-side state) நம்பியிருந்த பயன்பாடுகள், இப்போது அந்த நிலையை கிளையண்ட் பக்கத்திலோ அல்லது ஒரு தனிப்பட்ட சேமிப்பு அடுக்கு (persistence layer) மூலமாகவோ நிர்வகிக்க வேண்டியிருக்கும்.

கவனிக்க வேண்டியவை

  • பயன்பாட்டு அளவீடுகள் (Adoption metrics) – SDK பதிப்புப் பயன்பாட்டைக் கண்காணிக்கவும்; மந்தமான வளர்ச்சி இடமாற்றச் சிரமத்தைக் குறிக்கலாம்.
  • Edge பிளாட்ஃபார்ம் ஆதரவு – அதிகப்படியான வழங்குநர்கள் MCP-க்கு இணக்கமான runtimes-களை அறிவிக்கும்போது, serverless-ன் உண்மையான செலவுப் பயன் தெளிவாகத் தெரியும்.
  • பாதுகாப்புச் சம்பவ அறிக்கைகள் – வலுப்படுத்தப்பட்ட OAuth/OIDC ஓட்டம் அடையாளத் தாக்குதல்களைக் குறைக்க வேண்டும், ஆனால் ஏதேனும் ஊடுருவல் ஏற்பட்டால் புதிய பாதுகாப்பு வழிமுறைகள் சோதிக்கப்படும்.

முக்கியக் கருத்து (Takeaway): MCP-யை stateless ஆக்குவதன் மூலம், இந்த விவரக்குறிப்பு நெறிமுறையை நவீன cloud-native முறைகளுடன் ஒருங்கிணைக்கிறது, session management-ன் செயல்பாட்டுச் சுமையைக் குறைப்பதோடு மலிவான மற்றும் நெகிழ்வான (elastic) deployment மாடல்களுக்கான கதவைத் திறக்கிறது. குறியீட்டை மறுசீரமைக்கும் குறுகிய காலமும், பெரிய request footprints-உம் ஒரு சவாலாக இருந்தாலும், நீண்ட காலப் பலன் என்னவென்றால், அது இயங்கும் உள்கட்டமைப்பைப் போலவே எளிதாக அளவிடக்கூடிய (scale) ஒரு நெறிமுறையாக இருக்கும்.