إيقاف دعم أخذ العينات في MCP: Sampling مقابل Elicitation وما الذي تستخدمه الآن

إذا كان خادم MCP الخاص بك يستدعي sampling/createMessage، فإن المواصفات تطلب منك الآن التوقف عن البناء عليه. في 2026-07-28 أوقف Model Context Protocol دعم Sampling (SEP-2577)، إلى جانب Roots وLogging. أما Elicitation، وهي الميزة التي يخلط بها معظم الناس مع الميزة السابقة، فلم يتم إيقافها أبدًا. بل أُعيد بناؤها على آلية تسليم جديدة. يفصل هذا المقال بين ما سيزول وما سيبقى، مع التواريخ وأسماء الحقول ومسارات البدائل التي تحتاجها قبل إصدارك التالي.

💡 الخلاصة السريعة: تم إيقاف Sampling، وتنص المواصفات على الدمج المباشر مع APIs مزودي النماذج اللغوية الكبيرة (LLM). أما Elicitation فما زالت فعّالة، وتمرّ الآن عبر Multi Round-Trip Requests. لا يمكن إزالة أي شيء قبل إصدار مراجعة يُطرح في 2027-07-28 أو بعده.

ما الذي تغيّر في 2026-07-28

تعيد المراجعة 2026-07-28 كتابة طريقة تواصل العملاء والخوادم، وإيقاف Sampling بند واحد في سجل تغييرات طويل. ثلاثة تغييرات تهمنا هنا:

• النواة عديمة الحالة (Stateless). اختفت مصافحة initialize وترويسة Mcp-Session-Id. يحمل كل طلب الآن إصدار البروتوكول وقدرات العميل داخل _meta.
• Multi Round-Trip Requests (MRTR). لم يعد بإمكان الخادم دفع sampling/createMessage أو elicitation/create عبر اتصال مفتوح. بل يعيد نتيجة مؤقتة، ويعيد العميل تنفيذ الاستدعاء الأصلي مع إرفاق الإجابة.
• سجل الإيقاف. تحدد سياسة دورة حياة جديدة الحالات Active وDeprecated وRemoved، مع فترة دنيا مدتها اثنا عشر شهرًا قبل أن يصبح حذف أي شيء ممكنًا.

يفسر التغيير الأول الثاني. فبدون جلسة دائمة لا توجد قناة يُدفع من خلالها الطلب، لذلك كان لا بد من إعادة تصميم الطلبات المرسلة من الخادم إلى العميل. أُعيد تصميم Sampling وأُوقف في الإصدار نفسه. أما Elicitation فأُعيد تصميمه فقط.

نظرة سريعة على ما تم إيقافه

ماذا تعني كلمة Deprecated هنا

"Deprecated" لا تعني "removed". خلال فترة الإيقاف لا يتغير سلوك مستوى السلك، وتظل تفاوض القدرات تعمل، وتستمر التطبيقات القائمة في العمل. لا ينبغي للتطبيقات الجديدة أن تتبنى الميزة، وينبغي للتطبيقات القائمة أن ترحّل. والإزالة قرار يتخذه Core Maintainers أثناء تحضير الإصدار، لذلك قد تتأخر عن أقرب موعد. كما تطلب SEP من التطبيقات إصدار تحذير كلما جرى التفاوض على قدرة مُوقَفة، ولهذا بدأت حزم SDK بطباعة إشعارات الإيقاف. اعتبر هذه التحذيرات قائمة مهامك.

⚠️ تنبيه: تقول صفحة إيقاف Python SDK إن استدعاءات الجلسات القديمة مثل ctx.session.create_message() ما زالت تعمل على الجلسات المتفاوض عليها في 2025-11-25 أو قبله. أما على اتصال 2026-07-28 فإنها تصدر تحذيرًا ثم تُطلق استثناءً، لأنه لم تعد هناك قناة عودة للإرسال عبرها.

لماذا تم إيقاف Sampling

تذكر SEP-2577 ثلاثة أسباب. وهي تتراكم معًا.

ثقيل أكثر من اللازم على معظم العملاء

يتيح Sampling للخادم أن يطلب من نموذج العميل توليد نص. ولتنفيذ ذلك بشكل صحيح تحتاج إلى موافقة بشرية، ومنطق لاختيار النموذج، ومعالجة للأمان، وبعد SEP-1577 حلقة أدوات. وهذا كثير من البناء لميزة قد لا يستدعيها الخادم أبدًا. وتشير SEP إلى أن عددًا قليلًا من العملاء يدعمون Sampling رغم وجوده في المواصفات منذ مراجعة نوفمبر 2024.

سطح هجوم واسع

تصف SEP الميزة بأنها الأكثر حساسية من ناحية الأمان بين الميزات الثلاث الموقفة. فالخادم الذي يستطيع جعل نموذج العميل يشغّل أوامره النصية يفتح الباب لحقن الأوامر النصية وتسريب البيانات، لذلك يجب على كل عميل أن يتقن شاشات المراجعة وحدود معدل الطلبات.

استدعاء APIs مباشرة يمنحك تحكمًا أكبر

يستطيع الخادم الذي يحتاج نموذجًا أن يستدعي مزودًا بنفسه. يختار النموذج ويضبط المعاملات ويبث المخرجات. كانت الحجة القديمة لصالح Sampling أن الخوادم لا تحتاج بيانات اعتماد خاصة بها. أما المفاضلة الآن فواضحة: أنت تحتفظ ببيانات الاعتماد، وتدفع الفاتورة، وتقرر ما يحدث للبيانات. خصص ميزانية لإعادة المحاولات وحدود المعدل ونموذج احتياطي، لأن هذه صارت عملياتك أنت وليست عمليات العميل.

لم يتم إيقاف Elicitation

تحقق من الدليل في المواصفات نفسها. يسرد سجل الميزات المُوقفة Roots وSampling وLogging وDynamic Client Registration وقيم includeContext وHTTP+SSE. Elicitation غير مدرج فيه. لا تحمل صفحة Elicitation أي تحذير إيقاف، وسجل التغييرات يضع Elicitation ضمن MRTR. يجمع بعض المقالات كل ميزات الخادم نحو العميل في سلة واحدة، لذلك تحقق من السجل قبل أن تكرر هذا الادعاء.

فقد Elicitation تفصيلين: إشعار الإنهاء خارج النطاق (out-of-band)، وحقل elicitationId في وضع URL. ولذلك يحتاج الخادم الذي يجب أن يطابق إعادة محاولة مع طلب سابق إلى أن يرمّز معرّفه الخاص داخل requestState.

وضع النموذج (Form Mode)

يجمع وضع النموذج البيانات المنظمة داخل القناة (in band)، فيرى العميل الإجابة. وrequestedSchema كائن مسطح لا يحتوي إلا على خصائص أولية:

• نصوص، مع صيغ email أو uri أو date أو date-time
• أرقام وأعداد صحيحة
• قيم منطقية
• قوائم منسدلة باختيار واحد واختيار متعدد

الكائنات المتداخلة ومصفوفات الكائنات غير مدعومة عمدًا. يجيب المستخدم بأحد ثلاثة إجراءات: accept مع المحتوى، أو decline، أو cancel. وعلى الخادم أن يتعامل مع الإجراءات الثلاثة، بما في ذلك تقديم بدائل عند الرفض.

⚠️ يجب ألا يطلب الخوادم كلمات المرور أو رموز API أو رموز الوصول أو تفاصيل الدفع في وضع النموذج.

وضع URL (URL Mode)

يرسل وضع URL المستخدم إلى صفحة خارج النطاق (out of band)، ولا تمر البيانات عبر العميل إطلاقًا. وهو الطريق المناسب لعمليات التسليم الحساسة ولمصادقة OAuth مع الأطراف الثالثة. يجب على العميل أن يعرض عنوان URL كاملًا، وأن يبرز النطاق، وأن يطلب موافقة المستخدم، وألا يجلب الصفحة مسبقًا أبدًا. استجابة accept تعني فقط أن المستخدم وافق على فتح الصفحة. ولا تعني أن التفاعل قد انتهى.

قراءتي لسبب بقائها: يتيح Sampling للخادم أن يتخطى عملًا كان يستطيع إنجازه بنفسه عبر استدعاء مزود. أما Elicitation فهي الطريق الوحيد إلى الشخص. وبوابات التأكيد قبل الحذف أو النشر أو الدفع لا يوجد لها API مزوّد تلجأ إليه، لذلك كانت إزالة الميزة ستترك الخوادم في حيرة.

Sampling مقابل Elicitation جنبًا إلى جنب

يُقال كثيرًا إن الميزتين بديلتان عن بعضهما، وهذا غير صحيح. يفوّض Sampling توليد النص، أما Elicitation فيحصل على إجابة من شخص. واستبدال استدعاء Sampling من نوع "لخّص هذه الصفحة" بنموذج يعرض على المستخدم سيكون حلًا خاطئًا، لأن المستخدم لم يرد أصلًا كتابة هذا الملخص. والاتجاه المعاكس خاطئ بالقدر نفسه: أن تستخدم تخمين نموذج في موضع يحتاج إلى قرار بشري.

خذ خادم صور مثالًا عمليًا. قبل أن ينفق توليدًا، يحتاج إلى نمط وإلى إذن بالمتابعة. وكلاهما اختيار بشري، لذلك يستخدم Elicitation. ويريد أيضًا أمرًا نصيًا أغنى مما كتبه المستخدم. وإعادة الصياغة توليد نص، وكانت تُنفَّذ سابقًا عبر استدعاء Sampling. أما الآن فالخادم يستدعي مزودًا بنفسه، أو يطلب وصف الأداة من النموذج المضيف أن يرسل أمرًا نصيًا أوفى منذ البداية.

في هذه المراجعة تبقى الميزتان على الآلية نفسها، لأن كلًا منهما يظهر كعنصر داخل inputRequests. والفرق في من يقرأ العنصر، وما تقوله المواصفات عن مدة صلاحيته.

كيف تعمل الرحلة الذهابية والعودة الجديدة

تتكون الرحلة من أربع خطوات. يستدعي العميل tools/call. ويعيد الخادم InputRequiredResult مع resultType: "input_required". يجمع العميل الإجابة ويعيد تنفيذ الاستدعاء الأصلي مع إرفاق 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>"
  }
}

نسخ الأمر النصي

وهذه إعادة محاولة العميل، مع الإجابة والحالة المعادة:

{
  "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 المطلوبة (إصدار البروتوكول ومعلومات العميل وقدرات العميل) هنا للاختصار. لاحظ أن id في JSON-RPC يتغير بين الطلب الأصلي وإعادة المحاولة، لأنهما طلبان مستقلان.

قواعد للعملاء

• أعد إرسال requestState كما هو تمامًا. لا تفحصه ولا تحلله ولا تعدّله أبدًا.
• إذا لم تحتوِ النتيجة على requestState، فلا ترسل واحدًا في إعادة المحاولة.
• استخدم id جديدًا في JSON-RPC لإعادة المحاولة.
• إذا لم تكن هناك inputRequests، فيجوز للعميل أن يعيد المحاولة فورًا.
• تؤثر الحقول في إعادة محاولة ذلك الطلب وحده، لا في الاستدعاءات المتوازية أبدًا.

قواعد للخوادم

اعتبر requestState مدخلًا قد يتلاعب به المهاجم، لأنه يمر عبر العميل. وإذا أثّر في التفويض أو الوصول إلى الموارد أو منطق العمل، فاحمِ سلامته باستخدام HMAC أو AEAD، وارفض كل ما يفشل في التحقق. ضع المستخدم الموثّق وصلاحية قصيرة ومعرّفًا للطلب الأصلي داخل الحمولة المحمية. هذه الإجراءات تحدّ من إعادة التشغيل (replay) لكنها لا تجعل الحالة تُستخدم مرة واحدة، لذلك طبّق قيد الاستخدام لمرة واحدة على الخادم.

وهناك قيدان آخران. يحتاج كل InputRequiredResult إلى واحد على الأقل من inputRequests أو requestState، ويجب ألا يرسل الخادم نوع طلب لم يعلن العميل دعمه له. ويعمل MRTR فقط على prompts/get وresources/read وtools/call.

ما الذي تستخدمه بدلًا من Sampling

تقول المواصفات في سطر واحد: ادمج مباشرة مع APIs مزودي LLM. وعمليًا، يعتمد البديل الصحيح على سبب استدعاء 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 يرسل مخططًا فارغًا، لذلك يبدو القبول التلقائي مطابقًا لموافقة بشرية على السلك. أعطِ المستخدم قيمة حقيقية يختارها. وتحقق من التوقيع الحالي في SDK لديك قبل النسخ.

💡 قاعدة عامة: إذا كان على شخص أن يقرر، فاستخدم Elicitation. وإذا كان على نموذج أن يكتب، فاستدعِ مزودًا أو دع النموذج المضيف يتولى ذلك.

قائمة تحقق للترحيل بالنسبة للخوادم

1. ابحث عن كل استدعاء. ابحث عن sampling/createMessage و create_message، وأي فحوص لقدرة Sampling.
2. صنّف كل استدعاء حسب غرضه. يذهب توليد النص إلى API مزود أو إلى نموذج المضيف. وتذهب القرارات إلى Elicitation. ويذهب السياق إلى معاملات الأدوات أو URIs للموارد.
3. أسقط قيم includeContext. أزل "thisServer" و "allServers". احذف الحقل أو استخدم "none".
4. استبدل Roots وLogging. مرّر المسارات كمعاملات للأدوات. سجّل عبر stderr في stdio، واستخدم OpenTelemetry في غير ذلك.
5. أعد InputRequiredResult. استبدل الطلبات التي يبدأها الخادم بنتائج مؤقتة مع requestState توقّعه أنت.
6. اختبر على اتصال بتاريخ 2026-07-28. راقب تحذيرات الإيقاف في SDK، واستدعاءات الجلسات القديمة التي تُنتج أخطاء.
7. أبقِ مسارًا قديمًا. العملاء الذين يعملون على 2025-11-25 أو قبله ما زالوا يستخدمون السلوك القديم خلال فترة الانتقال.

الجدول الزمني الذي يجب متابعته

ثلاثة أخطاء يجب تجنبها

1. اعتبار الموقوف مُزالًا. الجلسات القديمة ما زالت تعمل، لكن اتصالات 2026-07-28 ترفض استدعاءات الجلسات القديمة. اعرف الإصدارات التي تخدمها.
2. استخدام نموذج لنص يجب أن يكتبه نموذج. Elicitation يطلب من شخص مدخلًا، وليس طريقة أرخص لصياغة النصوص.
3. تجاهل سلامة requestState. الحالة غير الموقّعة دعوة مفتوحة للعبث بمنطق خادمك.

قواعد المراجعة التي تبقى

الرقابة البشرية هي الجزء الذي ينتقل من Sampling إلى Elicitation. يجب على عملاء Elicitation أن يعرضوا اسم الخادم الذي يطلب المعلومات، وأن يوفروا خياري رفض وإلغاء واضحين، وأن يتيحوا للأشخاص مراجعة إجابات النموذج قبل إرسالها. وفي وضع URL يجب عليهم عرض النطاق المستهدف والحصول على موافقة المستخدم قبل فتح أي شيء. ويجب على الخوادم ربط كل طلب Elicitation بهوية المستخدم والتحقق ممن يفتح عنوان URL، وهذا يمنع نمط التصيّد الذي يرسل فيه المهاجم رابطه الخاص إلى الضحية.

أنشئ صورك الخاصة مع Picasso IA

يصبح العمل على البروتوكول أسهل عندما ترى ما تبنيه. إذا كنت تكتب خادم MCP يولّد صورًا، فإن نمط Elicitation الوارد أعلاه يناسبه جيدًا: اطلب نسبة عرض إلى ارتفاع أو نمطًا قبل إنفاق توليد.

على PicassoIA يمكنك تجربة النماذج التي تقف خلف هذا النوع من الأدوات: PicassoIA Image لتحويل النص إلى صورة، وPicassoIA Image Editor Pro للتعديلات، وGPT Image 2 عندما تريد رؤية مختلفة. ويقدّم PicassoIA أيضًا API للمطورين على نمط Replicate عند https://api.picassoia.com/v1، وتوصيلات MCP، بحيث يمكن أن تقف المولّدات نفسها خلف أدواتك الخاصة. تحقّق من الحدود الحالية في صفحة API الخاصة به قبل أن تخطط بناءً عليها.

افتح Picasso IA، واكتب أمرًا نصيًا واحدًا، ووَلِّد أول صورة لك. ثم أعد التجربة بنسبة عرض إلى ارتفاع مختلفة، وقارن بين الصورتين. تلك الحلقة الصغيرة هي نمط الطلب والإجابة وإعادة المحاولة الذي وصفه هذا المقال، مع بكسلات في النهاية.