MCP वर्शन 2, 28 जुलाई 2026 को लाइव हो रहा है। यह हर हैंडशेक (handshake), सेशन-ID हेडर और उन तीन लेगेसी सबसिस्टम्स (legacy subsystems) को हटा देता है जो Model Context Protocol (MCP) को स्टिकी-सेशन (sticky-session) सर्वर से जोड़ते थे। यह प्रोटोकॉल पूरी तरह से स्टेटलेस (stateless) हो जाता है, जिससे कोई भी ऑटोस्केल्ड (autoscaled) या सर्वरलेस (serverless) इंस्टेंस क्लाइंट स्टेट को सुरक्षित रखे बिना किसी भी रिक्वेस्ट को हैंडल कर सकता है।

यह बदलाव क्यों महत्वपूर्ण है

MCP v1 में क्लाइंट को initialize हैंडशेक के साथ एक सेशन शुरू करने के लिए मजबूर होना पड़ता था; इसके बाद सर्वर एक Mcp-Session-Id असाइन करता था। बाद की हर कॉल में उस हेडर को ले जाना पड़ता था, जिससे यूजर एक ही बैकएंड नोड तक सीमित हो जाता था। लोड बैलेंसर को सेशन एफिनिटी (session affinity) लागू करनी पड़ती थी, जिससे लेटेंसी (latency) और ऑपरेशनल घर्षण (operational friction) बढ़ जाता था।

स्टेटलेसनेस (Statelessness) उस घर्षण को खत्म कर देती है। अब सारा कॉन्टेक्स्ट समर्पित मेटा फील्ड्स (meta fields) में रहता है जो प्रत्येक HTTP कॉल के साथ चलते हैं। एक रिक्वेस्ट किसी भी इंस्टेंस पर पहुँच सकती है, प्रोसेस हो सकती है, और रिस्पॉन्स भेजते ही उस इंस्टेंस को हटाया जा सकता है। सर्वरलेस प्लेटफॉर्म, कंटेनर-ऑर्केस्ट्रेटेड क्लस्टर्स, या किसी भी ऐसे एनवायरनमेंट का उपयोग करने वाली टीमें जो मांग के अनुसार पॉड्स (pods) को स्पिन अप और डाउन करती हैं, अब इस प्रोटोकॉल को अपने इंफ्रास्ट्रक्चर के अनुरूप बना सकती हैं।

किसे रिटायर किया जा रहा है

तीन सबसिस्टम्स जो पर्सिस्टेंट कनेक्शन (persistent connections) पर निर्भर थे, उन्हें आधिकारिक तौर पर डिप्रिकेट (deprecated) कर दिया गया है:

  • Sampling – v1 में, एक सर्वर क्लाइंट से टेक्स्ट जेनरेट करने के लिए कह सकता था, एक ऐसा पैटर्न जिसके लिए ओपन सेशन की आवश्यकता होती थी। v2 में यह अपेक्षा की जाती है कि सर्वर सीधे लार्ज-लैंग्वेज-मॉडल (LLM) प्रोवाइडर को कॉल करे या InputRequiredResult पैटर्न का उपयोग करे, जहाँ क्लाइंट फॉलो-अप रिक्वेस्ट में छूटा हुआ इनपुट प्रदान करता है।
  • Roots – पहले, क्लाइंट ऐसे URIs भेजते थे जो बाहरी संसाधनों के सर्वर के व्यू (view) को सीमित करते थे। नया तरीका उन URIs को टूल पैरामीटर्स के रूप में पास करता है या उन्हें रिक्वेस्ट के रिसोर्स फील्ड्स में एम्बेड करता है, जिससे अलग से "roots" नेगोशिएशन स्टेप की आवश्यकता समाप्त हो जाती है।
  • Logging – प्रोटोकॉल-लेवल लॉगिंग हेडर गायब हो रहे हैं। लोकल डिबगिंग के लिए stderr पर लिखें या प्रोडक्शन ऑब्जर्वेबिलिटी (observability) के लिए OpenTelemetry अपनाएं।

डिप्रिकेशन विंडो एक साल तक चलेगी। डिप्रिकेट किए गए फीचर्स उस अवधि तक काम करते रहेंगे, जिससे टीमों को प्रोटोकॉल द्वारा उन्हें रिजेक्ट किए जाने से पहले रिफैक्टर (refactor) करने का समय मिल जाएगा।

स्टेटलेसनेस के अलावा नया क्या है

MCP v2 दो आधिकारिक एक्सटेंशन जोड़ता है:

  • MCP Apps – सर्वर-रेंडर किए गए यूजर इंटरफेस को वर्णित करने का एक हल्का तरीका जिसे प्रोटोकॉल इनवोक (invoke) कर सकता है।
  • Tasks – लंबे समय तक चलने वाले ऑपरेशन्स को संभालने का एक पैटर्न जो कई रिक्वेस्ट-रिस्पॉन्स साइकिल तक फैल सकते हैं।

दोनों एक्सटेंशन स्टेटलेस रिक्वेस्ट मॉडल को मानते हैं और छिपे हुए सेशन स्टेट से बचते हैं।

जोखिम और काउंटर-पॉइंट्स

यह बदलाव कोई 'प्लग-एंड-प्ले' अपग्रेड नहीं है। v2 SDKs अभी भी बीटा में हैं, और एक स्टेबल रिलीज़ आने से पहले उनके पब्लिक APIs बदल सकते हैं। उन प्रोडक्शन वर्कलोड्स के लिए जो ब्रेकिंग चेंजेस (breaking changes) सहन नहीं कर सकते, v2 SDK के स्टेबल होने तक स्टेबल v1 SDK पर ही रहें।

डेवलपर्स को तीनों डिप्रिकेट किए गए सबसिस्टम्स में से किसी के लिए भी मौजूदा कोड का ऑडिट करने की आवश्यकता है।

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

  1. आज ही ऑडिट करें – हैंडशेक, Mcp-Session-Id, सैंपलिंग कॉल्स, रूट्स URIs और प्रोटोकॉल-लेवल लॉगिंग के उपयोग के लिए अपनी सेवाओं को स्कैन करें। उस कोड की पहचान करें जो स्टेटलेस मॉडल के तहत टूट जाएगा।
  2. नॉन-क्रिटिकल नोड पर टेस्ट करें – जब एक स्टेबल v2 SDK रिलीज़ हो जाए, तो एक सैंडबॉक्स सर्वर (sandbox server) चलाएं, उसे एक टेस्ट क्लाइंट की ओर पॉइंट करें, और सत्यापित करें कि सभी आवश्यक मेटा फील्ड्स मौजूद हैं और सही ढंग से इंटरप्रेट किए गए हैं।
  3. डेडलाइन से पहले पूर्ण माइग्रेशन – रनटाइम रिजेक्शन से बचने के लिए एक साल की ग्रेस अवधि समाप्त होने से पहले सभी प्रोडक्शन नोड्स पर स्विच पूरा कर लें।

आगे क्या देखें

  • स्टेबल SDK रिलीज़ – बीटा SDKs को फ्रीज कर दिया जाएगा और एक वर्जन वाला स्टेबल पैकेज पब्लिश किया जाएगा। वह वर्जन किसी भी क्रिटिकल डिप्लॉयमेंट के लिए सुरक्षित लक्ष्य होगा।

इस ट्रांज़िशन के लिए कोड बदलावों और बीटा-SDK प्रयोग के एक संक्षिप्त अवधि की आवश्यकता होगी, लेकिन इसका लाभ किसी भी LLM-बैकड एप्लिकेशन के लिए एक स्वच्छ और अधिक स्केलेबल इंटीग्रेशन पॉइंट के रूप में मिलेगा।

निष्कर्ष (Takeaway): यदि आपका स्टैक अभी भी MCP हैंडशेक या तीन डिप्रिकेट किए गए सबसिस्टम्स पर निर्भर है, तो ऑडिट अभी शुरू करें; एक साल की ग्रेस अवधि उदार है, लेकिन वास्तविक लागत रिफैक्टरिंग का प्रयास है, डेडलाइन नहीं।