MCP स्टेटलेस स्पेक: स्टेटलेस बनाम स्टेटफ़ुल सर्वर की व्याख्या

इस गर्मी से पहले आपने जो भी MCP सर्वर बनाया था, वह शायद एक ही तरीके से शुरू होता है: क्लाइंट कनेक्ट होता है, initialize भेजता है, जवाब का इंतज़ार करता है, फिर initialized भेजता है, और उसके बाद ही असली काम शुरू होता है। Model Context Protocol का 2026-07-28 रिवीज़न यह रस्म हटा देता है। इसमें कोई हैंडशेक नहीं है, कोई Mcp-Session-Id हेडर नहीं है, और कोई प्रोटोकॉल-लेवल सेशन नहीं है जो एक ही प्रोसेस से बँधा हो। अगर आप MCP सर्वर को लोड बैलेंसर के पीछे चलाते हैं, या स्टिकी सेशन को जाल मानकर यह डिप्लॉयमेंट टालते रहे थे, तो यही वह बदलाव है जिसका आप इंतज़ार कर रहे थे।

यह लेख MCP स्टेटलेस स्पेक, व्यवहार में स्टेटलेस बनाम स्टेटफ़ुल सर्वर का अर्थ, और सबसे अहम बात, उस स्टेट का क्या होता है जिसकी आपके टूल्स को अब भी ज़रूरत है, इन सबको समझाता है। आप वे सटीक फ़ील्ड और हेडर देखेंगे जो बदले हैं, एक माइग्रेशन चेकलिस्ट, और यह भी कि इमेज जनरेशन कनेक्शन उसी पैटर्न में कैसे फ़िट होता है।

2026-07-28 स्पेक में क्या बदला

Agentic AI Foundation, यानी वह Linux Foundation प्रोजेक्ट जो अब MCP की देखरेख करता है, ने अपनी माइग्रेशन पोस्ट में इस रिलीज़ का सार दिया। संक्षेप में: प्रोटोकॉल ने यह मानना बंद कर दिया कि एक क्लाइंट और एक सर्वर के बीच लंबी बातचीत होगी, और हर कॉल को एक सामान्य HTTP रिक्वेस्ट की तरह देखना शुरू कर दिया।

हैंडशेक अब नहीं है

2025 के दौर के प्रोटोकॉल में क्लाइंट सबसे पहले बातचीत करके शर्तें तय करता था। initialize रिक्वेस्ट में प्रोटोकॉल वर्ज़न और क्षमताओं की सूची जाती थी, सर्वर अपनी सूची के साथ जवाब देता था, और क्लाइंट initialized से पुष्टि करता था। उसके बाद का सब कुछ उसी कनेक्शन पर तय हुई बातों पर निर्भर था।

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

हर रिक्वेस्ट अपना संदर्भ साथ लाती है

चूँकि शुरू में कुछ भी तय नहीं होता, इसलिए हर रिक्वेस्ट खुद अपनी जानकारी देती है। JSON-RPC एनवेलप में _meta ऑब्जेक्ट प्रोटोकॉल वर्ज़न, क्लाइंट की पहचान और क्षमता फ़्लैग लेकर चलता है। क्लाइंट की जानकारी कुछ ऐसी दिखती है:

{
  "_meta": {
    "io.modelcontextprotocol/clientInfo": {
      "name": "my-app",
      "version": "1.0"
    }
  }
}

प्रॉम्प्ट कॉपी करें

इसका व्यावहारिक असर यह है कि सर्वर सामने वाली रिक्वेस्ट से ही वह सब पढ़ लेता है जो उसे चाहिए। यहाँ देखें कि क्या बदला है:

💡 टिप: क्लाइंट चाहे तो अब भी सर्वर की क्षमताएँ पहले से मँगा सकता है। अब यह एक वैकल्पिक कॉल है, अनिवार्य पहला कदम नहीं।

गेटवे के लिए रूटिंग हेडर

Streamable HTTP पर स्पेक ऐसे हेडर भी परिभाषित करता है जिनसे इंफ़्रास्ट्रक्चर JSON बॉडी पढ़े बिना ट्रैफ़िक रूट कर सके:

• MCP-Protocol-Version: 2026-07-28
• Mcp-Method: tools/call
• Mcp-Name: search

गेटवे tools/call के लिए search वाली रिक्वेस्ट को एक पूल पर और बाकी सब को दूसरे पूल पर भेज सकता है, सिर्फ़ हेडर देखकर। इसी वजह से रेट लिमिटिंग और लॉगिंग भी सरल हो जाती हैं।

क्या नहीं बदला

मॉडल की नज़र में आपके सर्वर का स्वरूप नहीं बदलता। Tools, resources और prompts अब भी तीन प्रिमिटिव हैं, रिक्वेस्ट अब भी JSON-RPC हैं, और टूल अब भी आर्गुमेंट लेता है और नतीजा लौटाता है। फ़र्क पर्दे के पीछे है: लिस्ट एंडपॉइंट अब कनेक्शन के हिसाब से नहीं बदलते, इसलिए tools/list हर कॉलर को एक ही जवाब देता है, न कि हर सेशन के लिए अलग। यही नियम टूल लिस्ट को एज पर कैश करना सुरक्षित बनाता है।

स्टेटफ़ुल बनाम स्टेटलेस, सीधी भाषा में

ये शब्द ढीले-ढाले तरीके से इस्तेमाल होते हैं, इसलिए यहाँ काम चलाऊ परिभाषा दी गई है। स्टेटफ़ुल सर्वर रिक्वेस्ट के बीच कुछ न कुछ रखता है, और अगली रिक्वेस्ट तभी समझ में आती है जब वह उसी जगह पहुँचे। स्टेटलेस सर्वर रिक्वेस्ट के बीच कुछ नहीं रखता, और हर रिक्वेस्ट में उसे जवाब देने के लिए ज़रूरी सब कुछ होता है।

वह कैफ़े जो आपको याद रखता है

एक कैफ़े की कल्पना करें जहाँ बरिस्ता आपका ऑर्डर जानती है, आपका नाम जानती है, और यह भी कि आपको चीनी नहीं चाहिए। ऑर्डर देने में तीन शब्द लगते हैं, क्योंकि संदर्भ उसके दिमाग में है। यह एक स्टेटफ़ुल सर्वर है। यह तेज़ और दोस्ताना है, जब तक वह ब्रेक पर न जाए और उसकी जगह आया व्यक्ति आपको पहचानता ही न हो।

वह पोस्ट ऑफ़िस जो ऐसा नहीं करता

चिट्ठी उल्टे तरीके से काम करती है। पता, भेजने वाले का पता और टिकट, सब बाहर की तरफ़ लिखे होते हैं, इसलिए किसी भी शाखा का कोई भी कर्मचारी बिना किसी को फ़ोन किए उसे छाँट सकता है। यह एक स्टेटलेस सर्वर है, और 2026-07-28 की MCP रिक्वेस्ट ठीक ऐसे ही व्यवहार करती है: प्रोटोकॉल वर्ज़न, क्लाइंट की पहचान और क्षमताएँ, तीनों कॉल के साथ चलती हैं।

लोड बैलेंसर के पीछे की कीमत

2025-03-26 रिवीज़न में आए Streamable HTTP ट्रांसपोर्ट ने इनिशियलाइज़ेशन के दौरान सर्वर को एक Mcp-Session-Id जारी करने दिया। क्लाइंट हर बाद की रिक्वेस्ट में उसे वापस भेजता था, और सर्वर उसी से अपनी लेजर का सही पन्ना ढूँढता था: तय की गई क्षमताएँ, हर यूज़र का संदर्भ, और कभी-कभी खुले सब्सक्रिप्शन। stdio ट्रांसपोर्ट पर सर्वर इससे भी सरल तरीके से स्टेटफ़ुल थे, क्योंकि प्रोसेस खुद ही सेशन था।

जब वह लेजर किसी एक प्रोसेस की मेमोरी में रहती है, तो आपके लोड बैलेंसर को उसी क्लाइंट को उसी प्रोसेस पर भेजते रहना पड़ता है। टीमों ने इसे दो तरह से हल किया। स्टिकी सेशन ट्रैफ़िक को असमान कर देते हैं और नोड के रीस्टार्ट होते ही टूट जाते हैं। शेयर्ड स्टोर, जैसे Redis, लेटेंसी बढ़ाता है और एक नया single point of failure जोड़ता है। दोनों मुफ़्त नहीं हैं।

सेशन हटने के बाद कोई भी रिक्वेस्ट सादे राउंड-रॉबिन बैलेंसर के पीछे किसी भी इंस्टेंस पर पहुँच सकती है, जैसे एक जैसी टोल लेनों को गाड़ियाँ बारी-बारी से भरती हैं। यहाँ दोनों की तुलना एक साथ है:

अब आपकी स्टेट कहाँ जाती है

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

💡 मोटा नियम: अगर मॉडल को कुछ बाद में जारी रखना है, तो उसे एक हैंडल दें। अगर यूज़र को कॉल के बीच किसी बात का जवाब देना है, तो मल्टी-राउंड-ट्रिप रिक्वेस्ट इस्तेमाल करें। अगर काम धीमा है, तो टास्क इस्तेमाल करें।

स्पष्ट हैंडल

सुझाया गया पैटर्न वही है जो REST APIs दशकों से इस्तेमाल करते आए हैं। एक टूल कॉल एक पहचानकर्ता बनाकर लौटाती है, और मॉडल उसे बाद की कॉल में आर्गुमेंट के रूप में वापस भेजता है। उस टोकरी पर लगा कागज़ का टैग वही भूमिका निभाता है जो basket_id निभाता है।

create_basket()                           -> {"basket_id": "b_47f2"}
add_item(basket_id="b_47f2", sku="widget-123")
checkout(basket_id="b_47f2")

प्रॉम्प्ट कॉपी करें

सर्वर हर कॉल पर डेटाबेस में वह टोकरी ढूँढता है। कोई भी इंस्टेंस कोई भी स्टेप पूरा कर सकता है, रीस्टार्ट से कुछ नहीं जाता, और जब तक मॉडल के पास ID है, वह बिल्कुल नई बातचीत में भी काम आगे बढ़ा सकता है।

मल्टी-राउंड-ट्रिप रिक्वेस्ट

कभी-कभी किसी टूल को बीच में पुष्टि चाहिए होती है, जैसे "क्या ये 40 फ़ाइलें मिटाएँ?" सेशन वाली दुनिया में सर्वर खुले कनेक्शन पर रुककर इंतज़ार करता। SEP-2322 के तहत जवाब अब resultType: "input_required" और एक अपारदर्शी requestState टोकन लेकर आता है। क्लाइंट वही कॉल दोबारा भेजता है और जवाब inputResponses में डालता है।

चूँकि प्रगति उसी टोकन के भीतर रहती है, इसलिए retry पाने वाला कोई भी इंस्टेंस ठीक वहीं से काम उठा सकता है जहाँ पिछला इंस्टेंस रुका था।

धीमे काम के लिए टास्क

लंबे काम क्लेम टिकट मॉडल का पालन करते हैं। Tasks एक्सटेंशन (SEP-2663) के साथ क्लाइंट तुरंत taskId पाता है और काम पूरा होने तक tasks/get पर पोल करता रहता है। कॉल अपने निष्पादन से अलग होती है, इसलिए दस मिनट का रेंडर भी कनेक्शन खुला नहीं रखता, और हर पोल कोई भी इंस्टेंस तक पहुँच सकता है।

बिना परेशानी के सर्वर माइग्रेट करना

जो स्टोर करते हैं, उसका ऑडिट करें

सबसे पहले हर उस जगह को खोजें जहाँ आपका सर्वर रिक्वेस्ट के बीच क्लाइंट के बारे में कुछ याद रखता है। आम दोषी ये हैं:

• initialize के समय सहेजा गया Auth संदर्भ
• मेमोरी में रखे गए प्रति-सेशन कैश या रेट काउंटर
• ऐसे क्षमता चेक जो _meta के बजाय तय किए गए फ़्लैग पढ़ते हैं
• ऐसी टूल लिस्ट जो इस बात पर बदलती हैं कि कौन जुड़ा है
• खुले कनेक्शन से जुड़े सब्सक्रिप्शन

इनमें से हर एक को एक नया ठिकाना चाहिए: रिक्वेस्ट खुद, आपका डेटाबेस, या एक स्पष्ट हैंडल।

SDK codemod इस्तेमाल करें

TypeScript SDK v2 साइड-विशिष्ट पैकेज में बँटता है और यांत्रिक बदलावों के लिए एक codemod देता है:

npm install @modelcontextprotocol/server
npx @modelcontextprotocol/codemod@latest v1-to-v2 .

प्रॉम्प्ट कॉपी करें

v2 SDK डिफ़ॉल्ट रूप से अब भी 2025 के दौर के प्रोटोकॉल पर बात करते हैं, और 2026-07-28 की सेवा देना एक स्पष्ट opt-in है। इससे आप पहले कोड बदलाव भेज सकते हैं और प्रोटोकॉल स्विच तब पलटते हैं जब आपके क्लाइंट तैयार हों। v1.x लाइन को v2 के बाद कम से कम छह महीने तक बग और सुरक्षा सुधार मिलते रहेंगे।

डेप्रिकेशन की घड़ी पर नज़र रखें

मेंटेनर डेप्रिकेशन और हटाने के बीच कम से कम बारह महीने का वादा करते हैं, और डेप्रिकेटेड फ़ीचर के लिए सबसे जल्दी हटाने की तारीख 28 जुलाई 2027 है। माइग्रेशन लेख Roots, Sampling और Logging को डेप्रिकेटेड फ़ीचर में गिनते हैं (SEP-2577), और सर्वर-शुरू किए गए फ़्लो मल्टी-राउंड-ट्रिप रिक्वेस्ट की ओर जा रहे हैं। योजना बनाएँ, पर यह कोई आपात स्थिति नहीं है।

सुरक्षा और सख़्त होती है

सेशन सर्वर को कहने देता था कि "यह क्लाइंट पहले लॉगिन कर चुका है।" वह शॉर्टकट अब खत्म हो जाता है। हर रिक्वेस्ट में क्रेडेंशियल होने चाहिए, और हर रिक्वेस्ट की जाँच होनी चाहिए। अगर वैलिडेशन की लागत आपको परेशान करती है, तो नतीजे को कुछ सेकंड के लिए मेमोरी में रखा जा सकता है, पर सिर्फ़ इसलिए किसी रिक्वेस्ट पर भरोसा न करें कि पिछली ठीक लग रही थी।

हैंडल ऐसे बनाएँ जिन्हें अंदाज़े से ढूँढा न जा सके। हैंडल सिर्फ़ एक ID है, और ID हमलावरों के पसंदीदा निशाने होते हैं। b_47f2 डायग्राम में काम करता है। प्रोडक्शन में लंबे, रैंडम मान बनाएँ, रिकॉर्ड के साथ मालिक को सहेजें, और हर कॉल पर जाँचें कि कॉलर उस हैंडल का मालिक है। जिनकी ज़रूरत नहीं रही, उनकी मियाद खत्म करें।

नए रूटिंग हेडर यहाँ भी मदद करते हैं। क्योंकि Mcp-Method और Mcp-Name बॉडी खोले बिना दिखते हैं, इसलिए गेटवे हर टूल के लिए नीति लागू कर सकता है, जैसे पेमेंट टूल पर सख़्त रेट लिमिट या किसी विनाशकारी टूल के लिए allow list, और यह रिक्वेस्ट आपके कोड तक पहुँचने से पहले होगा। जब बाहरी परत लिफ़ाफ़े पर लिखा लेबल पढ़ सके, तो डिफ़ेंस इन डेप्थ आसान हो जाती है।

💡 मोटा नियम: हर हैंडल को सार्वजनिक URL पैरामीटर की तरह मानें। मान लें कि कोई अगला हैंडल आज़माने की कोशिश करेगा।

क्या आपको स्टेटलेस होना चाहिए?

ज़्यादातर सर्वरों के लिए, हाँ। रीड-ओनली लुकअप, डेटाबेस पर CRUD, सर्च, और REST API को रैप करने वाली हर चीज़ के पास याद रखने को कुछ नहीं होता, इसलिए इस बदलाव का ज़्यादातर हिस्सा कोड हटाना भर है। इससे आपको सरल डिप्लॉयमेंट मिलते हैं, सर्वरलेस प्लेटफ़ॉर्म में स्वाभाविक फ़िट मिलता है, और ऐसी विफलताएँ मिलती हैं जो पूरी बातचीत की जगह एक ही रिक्वेस्ट को प्रभावित करती हैं।

कुछ टूल कुछ जीवंत चीज़ रखते हैं: एक ब्राउज़र पेज, एक शेल, या चल रहा रेंडर। वह स्टेट रखें, लेकिन उसे एक मियाद वाले हैंडल के पीछे रखें, ऐसे स्टोर में जहाँ हर इंस्टेंस पहुँच सके। प्रोटोकॉल स्टेटलेस है। आपके बैकएंड को ऐसा होना ज़रूरी नहीं है।

एक त्वरित जाँच बताती है कि सर्वर कितना तैयार है। कोई भी रिक्वेस्ट चुनें जो अभी चल रही हो, उसे संभाल रहा इंस्टेंस बंद करें, और उसी कॉल को किसी दूसरे इंस्टेंस पर दोबारा भेजें। अगर जवाब एक जैसा है, तो आप वहाँ स्टेटलेस हैं जहाँ यह मायने रखता है। अगर retry विफल होता है, क्लाइंट से दोबारा शुरू करने को कहता है, या कुछ सूक्ष्म रूप से अलग लौटाता है, तो मेमोरी में अब भी एक लेजर छिपी है, और सबसे पहले उसी कोड को डेटाबेस या हैंडल के पीछे ले जाना चाहिए।

MCP पर इमेज जनरेट करना

MCP ही वह रास्ता है जिससे असिस्टेंट क्रिएटिव टूल्स तक पहुँचते हैं, और इमेज जनरेशन हैंडल पैटर्न का एक साफ़ उदाहरण है। PicassoIA अपने मॉडल एक डेवलपर API और एक MCP कनेक्शन के ज़रिए देता है। API https://api.picassoia.com/v1 पर है, इसमें एक Bearer टोकन इस्तेमाल होता है जो pia_sk_ से शुरू होता है, और Replicate जैसे लेआउट का पालन करता है: जॉब शुरू करने के लिए POST /v1/models/{owner}/{name}/predictions, उसकी स्थिति जाँचने के लिए GET /v1/predictions/{id}, और उसे रोकने के लिए POST /v1/predictions/{id}/cancel।

प्रेडिक्शन ID भी हैंडल हैं

जनरेशन एसिंक्रोनस है। जॉब शुरू करने पर तुरंत एक प्रेडिक्शन ID मिलता है, और असिस्टेंट सुझाए गए इंतज़ार के बाद उस ID के साथ स्टेटस टूल बार-बार तब तक कॉल करता है जब तक स्थिति succeeded या failed न दिखाए। GPU काम करते समय कोई खुला कनेक्शन खाली नहीं बैठता, और निरंतरता पूरी तरह ID में रहती है। यह पिक्सल पर लागू basket_id पैटर्न है।

वर्कफ़्लो की योजना बनाते समय कुछ सीमाएँ जानना उपयोगी है: हर अकाउंट के लिए 5 एकसाथ प्रेडिक्शन, जो सभी टोकन और MCP कनेक्शन के बीच साझा हैं, प्रॉम्प्ट 4,000 अक्षरों तक, और हर जॉब के लिए 3 घंटे का टाइमआउट।

वे मॉडल जिन्हें आप कॉल कर सकते हैं

ये चार मॉडल API और MCP कनेक्शन, दोनों के ज़रिए उपलब्ध हैं:

• टेक्स्ट-टू-इमेज के लिए PicassoIA Image
• मौजूदा तस्वीर को संपादित करने के लिए PicassoIA Image Editor Pro
• टेक्स्ट या इमेज से वीडियो के लिए PicassoIA Video
• ऑडियो वाले वीडियो के लिए Seedance 2.5 Lite

इस लेख की तस्वीरें P Image से आई हैं, जो प्लेटफ़ॉर्म पर उपलब्ध कई टेक्स्ट-से-इमेज मॉडल में से एक है। जब आप अपने MCP सर्वर के लिए टूल विवरण और JSON स्कीमा लिख रहे हों, तो लार्ज लैंग्वेज मॉडल (LLM) समय बचाता है। Claude Sonnet 5, GPT 5.6 Sol और Gemini 3.5 Flash ऐसे संरचित टेक्स्ट का ड्राफ़्ट बनाने और उसकी समीक्षा के लिए उपलब्ध हैं।

आपकी बारी: Picasso IA के साथ इमेज बनाएँ

अब आपने पूरी तस्वीर देख ली: सेशन बाहर, हैंडल अंदर, कोई भी इंस्टेंस कोई भी रिक्वेस्ट जवाब दे सकता है। इस पैटर्न को महसूस करने का सबसे तेज़ तरीका है इसे इस्तेमाल करना। Picasso IA खोलें, एक टेक्स्ट-से-इमेज मॉडल चुनें, और उस दृश्य के लिए प्रॉम्प्ट लिखें जैसा आप अपने आर्किटेक्चर डायग्राम को दिखाना चाहते हैं। कोई आरामदेह कैफ़े आज़माएँ, कोई व्यस्त टोल प्लाज़ा, या सर्वरों की एक शांत कतार, फिर एक बार में एक डिटेल बदलें और देखें कि नतीजा कैसे बदलता है।

जब आप और चाहें, तो सभी मॉडल पेज पर हर मॉडल देखें, किसी पसंदीदा इमेज को वीडियो मॉडल से छोटी क्लिप में बदलें, और प्रयोग करते रहें। आपका लिखा हर प्रॉम्प्ट एक छोटी रिक्वेस्ट है जो अपना सब कुछ साथ लेकर चलती है, और यही इस स्पेक का मूल विचार है।