MCP version 2, २८ जुलै २०२६ रोजी कार्यान्वित होत आहे. यामध्ये प्रत्येक handshake, session-ID header आणि ते तीन legacy subsystems काढून टाकण्यात आले आहेत, जे Model Context Protocol (MCP) ला sticky-session सर्व्हर्सशी जोडून ठेवत होते. हा प्रोटोकॉल आता पूर्णपणे stateless झाला आहे, त्यामुळे क्लायंट स्टेट (client state) जतन न करता कोणताही autoscaled किंवा serverless instance कोणत्याही विनंतीची (request) हाताळणी करू शकतो.

हा बदल का महत्त्वाचा आहे

MCP v1 मध्ये क्लायंटला initialize handshake सह सेशन सुरू करणे बंधनकारक होते; त्यानंतर सर्व्हर Mcp-Session-Id नियुक्त करत असे. त्यानंतरच्या प्रत्येक कॉलमध्ये तो header असणे आवश्यक होते, ज्यामुळे वापरकर्ता एकाच बॅकएंड नोडवर मर्यादित राहत असे. Load balancers ला session affinity लागू करावी लागत असे, ज्यामुळे latency आणि कार्यात्मक अडथळे (operational friction) निर्माण होत असत.

Statelessness मुळे हे अडथळे दूर होतात. आता सर्व context हे समर्पित meta fields मध्ये असते जे प्रत्येक HTTP call सोबत प्रवास करते. एखादी request कोणत्याही instance वर येऊ शकते, त्यावर प्रक्रिया केली जाऊ शकते आणि response पाठवताच तो instance काढून टाकता येतो. Serverless platforms, container-orchestrated clusters किंवा गरजेनुसार pods सुरू आणि बंद करणारे कोणतेही environment वापरणाऱ्या टीम्स आता या प्रोटोकॉलला त्यांच्या इन्फ्रास्ट्रक्चरशी सुसंगत बनवू शकतात.

काय निवृत्त (retire) केले जात आहे

कायमस्वरूपी कनेक्शन्सवर (persistent connections) अवलंबून असलेले तीन subsystems अधिकृतपणे deprecated करण्यात आले आहेत:

  • Sampling – v1 मध्ये, सर्व्हर क्लायंटला मजकूर (text) तयार करण्यास सांगू शकत असे, ज्या पद्धतीसाठी ओपन सेशनची आवश्यकता होती. v2 मध्ये सर्व्हरने थेट large-language-model provider ला कॉल करणे किंवा InputRequiredResult पॅटर्न वापरणे अपेक्षित आहे, जिथे क्लायंट फॉलो-अप विनंतीमध्ये (follow-up request) अपूर्ण माहिती पुरवतो.
  • Roots – यापूर्वी, क्लायंट्स असे URIs पाठवत असत जे बाह्य संसाधनांच्या (external resources) सर्व्हरच्या दृष्टिकोनाला मर्यादित करत असत. नवीन पद्धतीत हे URIs tool parameters म्हणून पाठवले जातात किंवा विनंतीच्या resource fields मध्ये समाविष्ट केले जातात, ज्यामुळे स्वतंत्र “roots” negotiation स्टेपची गरज उरत नाही.
  • Logging – प्रोटोकॉल-स्तरीय logging headers काढून टाकण्यात आले आहेत. स्थानिक डीबगिंगसाठी (local debugging) stderr मध्ये लिहा किंवा production observability साठी OpenTelemetry चा वापर करा.

Deprecation विंडो एक वर्षाची असेल. Deprecated फीचर्स त्या कालावधीसाठी काम करत राहतील, ज्यामुळे टीम्सना प्रोटोकॉलद्वारे ते नाकारले जाण्यापूर्वी refactor करण्यासाठी वेळ मिळेल.

Statelessness व्यतिरिक्त नवीन काय आहे

MCP v2 मध्ये दोन अधिकृत extensions जोडले गेले आहेत:

  • MCP Apps – सर्व्हर-रेंडर केलेल्या युजर इंटरफेसचे वर्णन करण्याची एक हलकी (lightweight) पद्धत, ज्याला प्रोटोकॉल कॉल करू शकतो.
  • Tasks – दीर्घकाळ चालणाऱ्या ऑपरेशन्स हाताळण्यासाठी एक पॅटर्न, जे अनेक request-response cycles मध्ये पसरलेले असू शकतात.

दोन्ही extensions stateless request मॉडेलवर आधारित आहेत आणि लपविलेले session state टाळतात.

जोखीम आणि प्रतिवाद

हा बदल 'plug-and-play' अपग्रेड नाही. v2 SDKs अजूनही beta मध्ये आहेत आणि स्थिर (stable) रिलीज येण्यापूर्वी त्यांच्या public APIs मध्ये बदल होऊ शकतात. ज्या production workloads मध्ये breaking changes सहन करता येत नाहीत, त्यांच्यासाठी v2 SDK स्थिर होईपर्यंत stable v1 SDK वरच राहा.

डेव्हलपर्सनी तीन deprecated subsystems पैकी कोणत्याही गोष्टीसाठी सध्याच्या कोडचे ऑडिट करणे देखील आवश्यक आहे.

एक व्यावहारिक मायग्रेशन रोडमॅप

  1. आजच ऑडिट करा – तुमच्या सर्व्हिसेसमध्ये handshake, Mcp-Session-Id, sampling calls, roots URIs आणि प्रोटोकॉल-स्तरीय logging चा वापर होत आहे का ते तपासा. stateless मॉडेलमध्ये कोणता कोड बिघडू शकतो ते ओळखा.
  2. Non-critical नोडवर चाचणी करा – जेव्हा stable v2 SDK रिलीज होईल, तेव्हा एक sandbox सर्व्हर सुरू करा, तो एका test client कडे वळवा आणि सर्व आवश्यक meta fields उपलब्ध आहेत आणि त्यांचे योग्य प्रकारे अर्थ लावले जात आहेत याची खात्री करा.
  3. मुदतीपूर्वी पूर्ण मायग्रेशन करा – runtime rejections टाळण्यासाठी एक वर्षाचा grace period संपण्यापूर्वी सर्व production nodes वर स्विचिंग पूर्ण करा.

पुढे काय पाहावे

  • Stable SDK रिलीज – Beta SDKs गोठवले (frozen) जातील आणि एक versioned stable package प्रकाशित केले जाईल. कोणत्याही महत्त्वाच्या deployment साठी ते version सुरक्षित लक्ष्य असेल.

या बदलासाठी कोडमध्ये बदल आणि beta-SDK च्या प्रयोगाचा थोडा काळ आवश्यक असेल, परंतु याचे फळ म्हणजे कोणत्याही LLM-backed application साठी एक स्वच्छ आणि अधिक स्केलेबल (scalable) इंटिग्रेशन पॉइंट मिळेल.

थोडक्यात सांगायचे तर (Takeaway): जर तुमचा stack अजूनही MCP handshakes किंवा तीन deprecated subsystems वर अवलंबून असेल, तर आताच ऑडिट सुरू करा; एक वर्षाचा grace period पुरेसा वाटू शकतो, परंतु खरा खर्च मुदतीचा नसून refactor करण्याच्या प्रयत्नांचा आहे.