MCP सैंपलिंग डेप्रिकेट: सैंपलिंग बनाम एलिसिटेशन और अब क्या उपयोग करें

अगर आपका MCP सर्वर sampling/createMessage को कॉल करता है, तो स्पेसिफ़िकेशन अब आपसे कहता है कि उस पर निर्माण रोक दें। 2026-07-28 को Model Context Protocol ने Sampling को (SEP-2577), Roots और Logging के साथ, डेप्रिकेट कर दिया। Elicitation, जिसे ज़्यादातर लोग इसके साथ जोड़ देते हैं, को नहीं डेप्रिकेट किया गया। उसे इसके बजाय एक नए डिलीवरी मैकेनिज़्म पर दोबारा बनाया गया। यह लेख बताता है कि क्या जा रहा है और क्या बना रहेगा, साथ में तारीख़ें, फ़ील्ड नाम और रिप्लेसमेंट के रास्ते, जो आपको अगली रिलीज़ से पहले चाहिए।

💡 संक्षेप में: Sampling डेप्रिकेट है, और स्पेक कहता है कि सीधे LLM प्रोवाइडर APIs से इंटीग्रेट करें। Elicitation सक्रिय है और अब Multi Round-Trip Requests के ज़रिए पहुँचता है। 2027-07-28 या उसके बाद जारी हुए किसी रिवीज़न से पहले कुछ भी नहीं हटाया जा सकता।

2026-07-28 को क्या बदला

2026-07-28 के रिवीज़न ने यह बदल दिया कि क्लाइंट और सर्वर आपस में कैसे बात करते हैं, और sampling का डेप्रिकेशन एक लंबी चेंजलॉग का सिर्फ़ एक हिस्सा है। यहाँ तीन बदलाव मायने रखते हैं:

• Stateless core. initialize हैंडशेक और Mcp-Session-Id हेडर हटा दिए गए हैं। हर रिक्वेस्ट अपना प्रोटोकॉल वर्ज़न और क्लाइंट क्षमताएँ _meta में लेकर चलती है।
• Multi Round-Trip Requests (MRTR). सर्वर अब खुले कनेक्शन पर sampling/createMessage या elicitation/create नहीं भेज सकता। वह एक इंटरिम रिज़ल्ट लौटाता है, और क्लाइंट जवाब जोड़कर मूल कॉल दोबारा भेजता है।
• डेप्रिकेशन रजिस्ट्री। एक नई लाइफ़साइकल पॉलिसी Active, Deprecated और Removed स्टेट तय करती है, और किसी भी चीज़ को हटाने से पहले कम से कम बारह महीने की खिड़की ज़रूरी है।

पहला बदलाव दूसरे को समझाता है। persistent सेशन के बिना ऐसा कोई चैनल नहीं बचता जिसमें रिक्वेस्ट भेजी जा सके, इसलिए सर्वर से क्लाइंट की ओर जाने वाली रिक्वेस्ट को दोबारा डिज़ाइन करना पड़ा। Sampling को उसी रिलीज़ में दोबारा डिज़ाइन और डेप्रिकेट किया गया। Elicitation को सिर्फ़ दोबारा डिज़ाइन किया गया।

एक नज़र में क्या डेप्रिकेट है

यहाँ "डेप्रिकेट" का मतलब क्या है

"डेप्रिकेट" का मतलब "हटाया गया" नहीं है। खिड़की के दौरान वायर-लेवल व्यवहार नहीं बदलता, क्षमता negotiation अब भी काम करती है और मौजूदा इम्प्लीमेंटेशन चलते रहते हैं। नए इम्प्लीमेंटेशन को इस फ़ीचर को नहीं अपनाना चाहिए, और मौजूदा इम्प्लीमेंटेशन को माइग्रेट करना चाहिए। हटाने का फ़ैसला रिलीज़ तैयारी के दौरान Core Maintainer लेते हैं, इसलिए यह सबसे पहली तारीख़ के बाद भी हो सकता है। SEP इम्प्लीमेंटेशन से यह भी कहता है कि जब कोई डेप्रिकेटेड क्षमता negotiate हो, तो वे चेतावनी दें, इसीलिए SDKs ने डेप्रिकेशन नोटिस प्रिंट करना शुरू किया है। इन चेतावनियों को अपनी टू-डू लिस्ट मानें।

⚠️ सावधान: Python SDK के डेप्रिकेशन पेज के अनुसार ctx.session.create_message() जैसी पुरानी सेशन-शैली कॉल उन सेशन पर अब भी काम करती हैं जो 2025-11-25 या उससे पहले negotiate हुए थे। 2026-07-28 कनेक्शन पर वे चेतावनी देती हैं और फिर एरर फेंकती हैं, क्योंकि भेजने के लिए कोई बैक चैनल बचा ही नहीं।

Sampling क्यों डेप्रिकेट हुआ

SEP-2577 तीन कारण देता है। ये तीनों एक साथ लागू होते हैं।

ज़्यादातर क्लाइंट के लिए बहुत भारी

Sampling सर्वर को क्लाइंट के मॉडल से जनरेशन माँगने देता है। इसे सही ढंग से करने के लिए human-in-the-loop मंज़ूरी, मॉडल चुनने का लॉजिक, सुरक्षा हैंडलिंग और, SEP-1577 के बाद, एक tool loop चाहिए। एक ऐसी सुविधा के लिए यह बहुत कुछ बनाना है जिसे कोई सर्वर शायद कभी कॉल ही न करे। SEP बताता है कि नवंबर 2024 के रिवीज़न से स्पेक में होने के बावजूद बहुत कम क्लाइंट sampling को सपोर्ट करते हैं।

हमले की बड़ी सतह

SEP sampling को तीनों डेप्रिकेटेड फ़ीचरों में सबसे ज़्यादा सुरक्षा-संवेदनशील बताता है। जो सर्वर क्लाइंट के मॉडल से अपने प्रॉम्प्ट चलवा सकता है, वह prompt injection और डेटा exfiltration के लिए जगह बनाता है, इसलिए हर क्लाइंट को रिव्यू स्क्रीन और रेट लिमिट सही ढंग से देनी होंगी।

डायरेक्ट APIs ज़्यादा नियंत्रण देते हैं

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

Elicitation डेप्रिकेट नहीं हुआ

स्पेक में ही सबूत देखें। डेप्रिकेटेड फ़ीचर रजिस्ट्री में Roots, Sampling, Logging, Dynamic Client Registration, includeContext वैल्यू और HTTP+SSE दर्ज हैं। Elicitation उसमें नहीं है। Elicitation पेज पर कोई डेप्रिकेशन चेतावनी नहीं है, और चेंजलॉग elicitation को MRTR के तहत रखता है। कुछ लेखों में सभी सर्वर-से-क्लाइंट फ़ीचर एक साथ समूहित किए जाते हैं, इसलिए वही दावा दोहराने से पहले रजिस्ट्री जाँच लें।

Elicitation ने दो विवरण ज़रूर खोए: out-of-band फ़िनिश नोटिफ़िकेशन और URL मोड में elicitationId फ़ील्ड। जिस सर्वर को किसी रिट्राई को पहले के अनुरोध से मिलाना होता है, वह अब अपना आइडेंटिफ़ायर requestState के अंदर एन्कोड करता है।

Form मोड

Form मोड संरचित डेटा in band इकट्ठा करता है, इसलिए क्लाइंट को जवाब दिखता है। requestedSchema सिर्फ़ primitive प्रॉपर्टी वाला एक flat object है:

• स्ट्रिंग, जिनमें email, uri, date या date-time फ़ॉर्मेट हों
• नंबर और इंटीजर
• बूलियन
• सिंगल-सेलेक्ट और मल्टी-सेलेक्ट enums

नेस्टेड ऑब्जेक्ट और ऑब्जेक्ट के ऐरे जानबूझकर सपोर्ट नहीं किए गए हैं। यूज़र तीन कार्रवाइयों में से एक से जवाब देता है: accept कंटेंट के साथ, decline, या cancel। सर्वर को तीनों को हैंडल करना होगा, जिनमें मना करने पर विकल्प देना भी शामिल है।

⚠️ Form मोड में सर्वर को पासवर्ड, API टोकन, ऐक्सेस टोकन या पेमेंट विवरण नहीं माँगने चाहिए।

URL मोड

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

मेरी राय कि यह क्यों बच गया: Sampling सर्वर को उस काम से बचने देता है जो वह खुद कर सकता था, यानी किसी प्रोवाइडर को कॉल करके। Elicitation इंसान तक पहुँचने का अकेला रास्ता है। डिलीट, पब्लिश या पेमेंट से पहले की पुष्टि के लिए कोई प्रोवाइडर API फ़ॉलबैक नहीं होता, इसलिए इस फ़ीचर को हटाने पर सर्वर अंदाज़े से चलते।

Sampling बनाम Elicitation, आमने-सामने

दोनों को अक्सर विकल्प कहा जाता है, पर ये हैं नहीं। Sampling टेक्स्ट जनरेशन सौंपता है। Elicitation किसी इंसान से जवाब लेता है। "इस पेज का सार बनाओ" वाली sampling कॉल की जगह एक फ़ॉर्म लगाना गलत समाधान होगा, क्योंकि यूज़र ने वह सार लिखवाना चाहा ही नहीं था। उल्टा तरीका भी उतना ही गलत है: जहाँ इंसानी फ़ैसला चाहिए, वहाँ मॉडल का अंदाज़ा इस्तेमाल करना।

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

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

नया राउंड ट्रिप कैसे काम करता है

फ़्लो में चार कदम हैं। क्लाइंट tools/call कॉल करता है। सर्वर resultType: "input_required" के साथ एक InputRequiredResult लौटाता है। क्लाइंट जवाब इकट्ठा करता है और inputResponses जोड़कर मूल कॉल दोबारा भेजता है। फिर सर्वर असली रिज़ल्ट बनाता है। चूँकि रिट्राई में वह सब कुछ होता है जो सर्वर को चाहिए, लोड बैलेंसर के पीछे का कोई भी इंस्टेंस उसे संभाल सकता है।

यहाँ एक इमेज टूल के लिए सर्वर का इंटरिम रिस्पॉन्स है, जिसे आस्पेक्ट रेशियो चाहिए:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "aspect": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Which aspect ratio should the image use?",
          "requestedSchema": {
            "type": "object",
            "properties": {
              "ratio": { "type": "string", "enum": ["16:9", "1:1", "9:16"] }
            },
            "required": ["ratio"]
          }
        }
      }
    },
    "requestState": "<signed blob>"
  }
}

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

और क्लाइंट की रिट्राई, जवाब और लौटाए गए state के साथ:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "generate_image",
    "arguments": { "prompt": "A foggy harbor at dawn" },
    "inputResponses": {
      "aspect": { "action": "accept", "content": { "ratio": "16:9" } }
    },
    "requestState": "<signed blob>"
  }
}

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

संक्षेप के लिए यहाँ ज़रूरी _meta फ़ील्ड (प्रोटोकॉल वर्ज़न, क्लाइंट इंफ़ो, क्लाइंट क्षमताएँ) छोड़ दिए गए हैं। ध्यान दें कि मूल रिक्वेस्ट और रिट्राई के बीच JSON-RPC id बदल जाता है, क्योंकि ये स्वतंत्र रिक्वेस्ट हैं।

क्लाइंट के लिए नियम

• requestState को बिल्कुल वैसे ही वापस भेजें। उसे कभी inspect, parse या modify न करें।
• अगर रिज़ल्ट में requestState नहीं है, तो रिट्राई में कुछ न भेजें।
• रिट्राई के लिए नया JSON-RPC id इस्तेमाल करें।
• अगर inputRequests नहीं हैं, तो क्लाइंट तुरंत रिट्राई कर सकता है।
• ये फ़ील्ड सिर्फ़ उस एक रिक्वेस्ट की रिट्राई पर लागू होते हैं, समानांतर कॉल पर कभी नहीं।

सर्वर के लिए नियम

requestState को हमलावर-नियंत्रित इनपुट मानें, क्योंकि यह क्लाइंट से होकर गुज़रता है। जब यह ऑथराइज़ेशन, रिसोर्स ऐक्सेस या बिज़नेस लॉजिक पर असर डाले, तब HMAC या AEAD से इसकी इंटेग्रिटी सुरक्षित करें और वेरिफ़िकेशन में विफल होने वाली किसी भी चीज़ को अस्वीकार करें। प्रमाणित यूज़र, छोटी एक्सपायरी और मूल अनुरोध का आइडेंटिफ़ायर, सब सुरक्षित पेलोड के अंदर रखें। ये रीप्ले को सीमित करते हैं, लेकिन किसी स्टेट को सिंगल-यूज़ नहीं बनाते, इसलिए वन-टाइम रिडेम्प्शन सर्वर पर लागू करें।

दो और बाधाएँ लागू होती हैं। हर InputRequiredResult को inputRequests या requestState में से कम से कम एक चाहिए, और सर्वर ऐसा request type नहीं भेज सकता जिसके सपोर्ट की घोषणा क्लाइंट ने न की हो। MRTR सिर्फ़ prompts/get, resources/read और tools/call पर काम करता है।

Sampling की जगह अब क्या उपयोग करें

स्पेक का जवाब एक पंक्ति का है: LLM प्रोवाइडर APIs से सीधे इंटीग्रेट करें। व्यवहार में सही रिप्लेसमेंट इस पर निर्भर करता है कि आपने sampling क्यों कॉल किया था।

सीधे प्रोवाइडर API को कॉल करें

जब आपको असली टेक्स्ट जनरेशन चाहिए, तो सर्वर से प्रोवाइडर को कॉल करें। किसी एक को अपने कोड में पक्का करने से पहले उम्मीदवारों की तुलना करें। PicassoIA पर आप Claude Sonnet 5, GPT 5.6 Terra और Gemini 3.5 Flash को साथ-साथ आज़मा सकते हैं और देख सकते हैं कि आपके प्रॉम्प्ट को किसने सबसे अच्छी तरह और ज़रूरी रफ़्तार से संभाला। फिर क्रेडेंशियल को एक सामान्य सर्वर सीक्रेट के रूप में सेव करें, टाइमआउट सेट करें और टोकन उपयोग लॉग करें।

होस्ट मॉडल को तर्क करने दें

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

फ़ैसलों के लिए इंसान से पूछें

जब कमी वाली चीज़ कोई फ़ैसला है, तो elicitation पर जाएँ। Python SDK में एक लेख एक सकारात्मक चुनाव वाला पैटर्न दिखाता है:

CONFIRM = ["cancel", "confirm"]
result = await ctx.elicit("Delete 42 drafts?", response_type=CONFIRM)

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

उसी लेख में चेतावनी दी गई है कि response_type=None पास करने से खाली schema जाता है, इसलिए वायर पर ऑटोमैटिक स्वीकृति इंसानी मंज़ूरी जैसी दिखती है। यूज़र को असली मान चुनने दें। कॉपी करने से पहले अपने SDK का मौजूदा signature जाँच लें।

💡 मोटा नियम: अगर फ़ैसला इंसान को करना है, तो elicit करें। अगर लिखना मॉडल को है, तो प्रोवाइडर को कॉल करें या होस्ट मॉडल को करने दें।

सर्वरों के लिए माइग्रेशन चेकलिस्ट

1. हर कॉल ढूँढें। sampling/createMessage, create_message और किसी भी sampling क्षमता जाँच को खोजें।
2. हर कॉल को उद्देश्य के अनुसार छाँटें। टेक्स्ट जनरेशन प्रोवाइडर API या होस्ट मॉडल के पास जाता है। फ़ैसले elicitation के पास जाते हैं। संदर्भ tool arguments या resource URIs के पास जाता है।
3. includeContext वैल्यू हटाएँ। "thisServer" और "allServers" हटाएँ। फ़ील्ड छोड़ दें या "none" इस्तेमाल करें।
4. Roots और Logging बदलें। पाथ को tool parameters के रूप में पास करें। stdio पर stderr में लॉग करें और बाकी जगह OpenTelemetry इस्तेमाल करें।
5. InputRequiredResult लौटाएँ। सर्वर-इनिशिएटेड रिक्वेस्ट की जगह इंटरिम रिज़ल्ट और एक ऐसा requestState रखें जिस पर आप साइन करते हैं।
6. 2026-07-28 कनेक्शन पर टेस्ट करें। SDK की डेप्रिकेशन चेतावनियों और उन पुरानी सेशन कॉल पर नज़र रखें जो एरर फेंकती हैं।
7. एक लीगेसी पाथ रखें। 2025-11-25 या उससे पहले वाले क्लाइंट खिड़की के दौरान अब भी पुराने व्यवहार पर चलते हैं।

ट्रैक करने लायक टाइमलाइन

बचने वाली तीन गलतियाँ

1. डेप्रिकेट को हटाया हुआ मान लेना। पुराने सेशन अब भी चलते हैं, पर 2026-07-28 कनेक्शन पुरानी सेशन-शैली कॉल अस्वीकार करते हैं। जानें कि आप कौन से वर्ज़न सर्व कर रहे हैं।
2. वह टेक्स्ट फ़ॉर्म से माँगना जो मॉडल को लिखना चाहिए। Elicitation इंसान से इनपुट माँगता है। यह कॉपी का सस्ता ड्राफ़्ट बनाने का तरीका नहीं है।
3. requestState की integrity छोड़ देना। बिना साइन किया state आपके सर्वर लॉजिक से छेड़छाड़ का खुला न्योता है।

वे रिव्यू नियम जो बने रहते हैं

ह्यूमन ओवरसाइट Sampling का वह हिस्सा है जो आगे भी बना रहता है। Elicitation क्लाइंट को यह दिखाना होगा कि कौन-सा सर्वर पूछ रहा है, मना करने और रद्द करने के साफ़ विकल्प देने होंगे, और भेजने से पहले लोगों को फ़ॉर्म के जवाब देखने देने होंगे। URL मोड में उन्हें कुछ भी खोलने से पहले टारगेट डोमेन दिखाना होगा और सहमति लेनी होगी। सर्वर को हर elicitation को यूज़र की पहचान से जोड़ना होगा और यह सत्यापित करना होगा कि URL कौन खोल रहा है। इससे फ़िशिंग का वह तरीका रुकता है जिसमें हमलावर अपना लिंक पीड़ित को भेज देता है।

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

प्रोटोकॉल का काम आसान हो जाता है जब आप देख सकें कि आप क्या बना रहे हैं। अगर आप एक MCP सर्वर लिख रहे हैं जो तस्वीरें बनाता है, तो ऊपर वाला elicitation पैटर्न उस पर अच्छा बैठता है: जनरेशन खर्च करने से पहले आस्पेक्ट रेशियो या स्टाइल पूछें।

PicassoIA पर आप ऐसे टूल के पीछे के मॉडल आज़मा सकते हैं: टेक्स्ट-टू-इमेज के लिए PicassoIA Image, एडिट के लिए PicassoIA Image Editor Pro, और जब आपको एक और नज़रिया चाहिए तो GPT Image 2। PicassoIA https://api.picassoia.com/v1 पर Replicate-शैली का डेवलपर API और MCP कनेक्शन भी देता है, ताकि वही जनरेटर आपके अपने टूल के पीछे लग सकें। योजना बनाने से पहले उसके API पेज पर मौजूदा सीमाएँ जाँच लें।

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