مواصفات MCP عديمة الحالة: شرح الخوادم عديمة الحالة وذات الحالة

من المرجّح أن كل خادم MCP بنيته قبل هذا الصيف يبدأ بالطريقة نفسها: يتصل العميل، ويرسل initialize، وينتظر الرد، ثم يرسل initialized، ولا يبدأ العمل الفعلي إلا بعد ذلك. تُلغي المراجعة 2026-07-28 من بروتوكول سياق النموذج (Model Context Protocol) هذا الإجراء. لا توجد مصافحة، ولا ترويسة Mcp-Session-Id، ولا جلسة على مستوى البروتوكول مرتبطة بعملية واحدة. إذا كنت تشغّل خادم MCP خلف موازن أحمال، أو أجّلت هذا النشر لأن الجلسات اللاصقة بدت فخًّا، فهذا هو التغيير الذي كنت تنتظره.

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

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

لخّصت Agentic AI Foundation، وهي مؤسسة مشروع Linux Foundation التي تشرف الآن على MCP، هذا الإصدار في منشور الترحيل الخاص بها. الخلاصة أن البروتوكول توقّف عن افتراض محادثة طويلة بين عميل واحد وخادم واحد، وبدأ يعامل كل استدعاء كطلب HTTP عادي.

المصافحة لم تعد موجودة

في البروتوكول الذي يعود إلى عام 2025، كان أول ما يفعله العميل هو التفاوض. يحمل طلب initialize إصدار البروتوكول وقائمة بالقدرات، ويردّ الخادم بقائمته، ويؤكد العميل ذلك بطلب initialized. وكل ما يأتي بعد ذلك يعتمد على ما اتُّفق عليه في ذلك الاتصال تحديدًا.

تُزيل المراجعة الجديدة هذا التبادل بالكامل. لم يعد الخادم يبني ذاكرة خاصة بكل عميل، لذلك يمكن أن يُجاب طلبان من العميل نفسه بواسطة جهازين مختلفين دون أن يلاحظ أيٌّ منهما ذلك.

كل طلب يحمل سياقه الخاص

بما أن شيئًا لا يُتفاوض عليه مسبقًا، فإن كل طلب يعرّف بنفسه. يحمل كائن _meta داخل غلاف JSON-RPC إصدار البروتوكول، وهوية العميل، وأعلام القدرات. تبدو معلومات العميل هكذا:

{
  "_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 إلى مجموعة، وكل ما عداها إلى مجموعة أخرى، باستخدام الترويسات وحدها. ويصبح تحديد المعدل والتسجيل أبسط للسبب نفسه.

ما الذي يبقى كما هو

لا شيء في نظرة النموذج إلى خادمك يتغيّر. الأدوات والموارد والأوامر لا تزال العناصر الأساسية الثلاثة، والطلبات لا تزال JSON-RPC، والأداة لا تزال تتلقى المعاملات وتعيد نتيجة. الفرق يكمن خلف الستار: لم تعد نقاط القوائم تختلف حسب الاتصال، فيعيد tools/list الإجابة نفسها لكل مستدعٍ بدلًا من تنوع لكل جلسة. هذه القاعدة الواحدة هي ما يجعل تخزين قائمة الأدوات مؤقتًا على الحافة آمنًا.

ذات الحالة مقابل عديمة الحالة بلغة بسيطة

تُستخدم هذه المصطلحات بشكل فضفاض، لذلك إليك التعريف العملي. يحتفظ الخادم ذو الحالة بشيء ما بين الطلبات، ولا يكون الطلب التالي منطقيًا إلا إذا وصل إلى المكان نفسه. أما الخادم عديم الحالة فلا يحتفظ بشيء بين الطلبات، وكل طلب يحتوي على كل ما يلزم للرد عليه.

المقهى الذي يتذكرك

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

مكتب البريد الذي لا يفعل ذلك

الرسالة تعمل بالعكس. العنوان، وعنوان المرسل، والطابع كلها على الخارج، لذلك يستطيع أي موظف في أي فرع أن يفرزها دون الاتصال بأحد. هذا خادم عديم الحالة، وهذا بالضبط سلوك طلب MCP بتاريخ 2026-07-28: إصدار البروتوكول وهوية العميل والقدرات كلها تُرسل مع الاستدعاء.

الكلفة خلف موازن الأحمال

سمح نقل Streamable HTTP الذي قُدّم في المراجعة 2025-03-26 للخادم بإصدار Mcp-Session-Id أثناء التهيئة. كان العميل يعيده مع كل طلب لاحق، وكان الخادم يستخدمه للعثور على الصفحة الصحيحة في سجله: القدرات المتفق عليها، وسياق كل مستخدم، وأحيانًا الاشتراكات المفتوحة. أما الخوادم التي تعمل على نقل stdio فكانت ذات حالة بطريقة أبسط، لأن العملية نفسها كانت الجلسة.

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

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

أين تذهب حالتك الآن

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

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

المعرّفات الصريحة

النمط الموصى به هو النمط الذي تستخدمه واجهات REST APIs منذ عقود. ينشئ استدعاء أداة واحد معرّفًا ويعيده، ويمرّره النموذج مرة أخرى كوسيط في الاستدعاءات اللاحقة. تؤدي البطاقة الورقية على تلك السلة الدور نفسه الذي يؤديه basket_id.

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

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

يبحث الخادم عن السلة في قاعدة بيانات عند كل استدعاء. يمكن لأي نسخة أن تخدم أي خطوة، ولا يُفقد شيء عند إعادة التشغيل، ويستطيع النموذج استئناف العمل في محادثة جديدة تمامًا ما دام يحتفظ بالمعرّف.

طلبات الجولات المتعددة

أحيانًا تحتاج أداة إلى تأكيد في منتصف العملية، مثل "هل تريد حذف هذه الملفات، وعددها 40؟". في عالم الجلسات كان الخادم سيتوقف وينتظر على اتصال مفتوح. أما بموجب SEP-2322 فتحمل الاستجابة بدلًا من ذلك resultType: "input_required" وrequestState غير شفاف. يعيد العميل المحاولة للاستدعاء نفسه مع الإجابات في inputResponses.

ولأن التقدم يسافر داخل ذلك الرمز، يمكن لأي نسخة تستقبل المحاولة أن تتابع من حيث توقفت النسخة السابقة تمامًا.

المهام للعمل البطيء

تتبع المهام الطويلة نموذج تذكرة الاستلام. مع امتداد Tasks (SEP-2663)، يتلقى العميل taskId فورًا ويستعلم عن tasks/get حتى ينتهي العمل. يُفصل الاستدعاء عن تنفيذه، فلا يُبقي تصيير فيديو يستغرق عشر دقائق اتصالًا مفتوحًا، ويمكن لكل استعلام أن يصل إلى أي نسخة.

ترحيل الخادم دون متاعب

راجع ما تخزّنه

ابدأ بالبحث عن كل مكان يتذكر فيه خادمك شيئًا عن العميل بين الطلبات. المشتبه بهم المعتادون:

• سياق المصادقة المحفوظ وقت initialize
• ذاكرات مؤقتة لكل جلسة أو عدادات معدل محفوظة في الذاكرة
• فحوصات القدرات التي تقرأ الأعلام المتفاوض عليها بدلًا من _meta
• قوائم أدوات تتغير حسب من اتصل
• اشتراكات مرتبطة باتصال مفتوح

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

استخدم أداة التحويل الآلي لحزمة SDK

يُقسَّم TypeScript SDK الإصدار 2 إلى حزم خاصة بكل جانب، ويأتي مع أداة تحويل آلي (codemod) للتغييرات الميكانيكية:

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

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

تواصل حزم SDK الإصدار 2 التحدث بالبروتوكول الذي يعود إلى عام 2025 افتراضيًا، وتقديم 2026-07-28 يتطلب تفعيلًا صريحًا. وهذا يتيح لك شحن تغيير الشيفرة أولًا، ثم تبديل مفتاح البروتوكول حين يصبح عملاؤك جاهزين. ويواصل الفرع v1.x تلقي إصلاحات الأخطاء والثغرات الأمنية لمدة ستة أشهر على الأقل بعد الإصدار 2.

انتبه إلى جدول مواعيد الإيقاف

يعد القائمون على المشروع بفاصل لا يقل عن اثني عشر شهرًا بين الإيقاف والإزالة، وأقرب تاريخ لإزالة الميزات المهملة هو 28 يوليو 2027. وتذكر أدلة الترحيل Roots وSampling وLogging ضمن الميزات المهملة (SEP-2577)، مع انتقال التدفقات التي يبدأها الخادم إلى طلبات الجولات المتعددة. خطّط للعمل، لكن هذا ليس حالة طارئة.

الأمن يصبح أكثر صرامة

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

اجعل المعرّفات غير قابلة للتخمين. المعرّف مجرد رقم، والمعرّفات هدف تقليدي للهجمات. عبارة b_47f2 تعمل في المخطط، أما في بيئة الإنتاج فولّد قيمًا عشوائية طويلة، واحفظ مالك المعرّف إلى جانب السجل، وتحقق في كل استدعاء من أن المستدعي يملك المعرّف. وأبطِل صلاحية المعرّفات التي لم تعد تحتاجها.

ترويسات التوجيه الجديدة تساعد هنا أيضًا. لأن Mcp-Method وMcp-Name مرئيان دون فتح نص الطلب، يمكن للبوابة أن تطبّق سياسة لكل أداة، مثل حدود معدل أشد على أداة دفع، أو قائمة سماح لأداة مدمّرة، قبل أن يصل الطلب إلى شيفرتك. يصبح الدفاع متعدد الطبقات أسهل حين تستطيع الطبقة الخارجية قراءة الملصق على المظروف.

💡 قاعدة عامة: عامل كل معرّف كمعامل عنوان URL عام. افترض أن أحدهم سيجرّب المعرّف التالي.

هل يجب أن تتحول إلى عديم الحالة؟

بالنسبة لمعظم الخوادم، نعم. عمليات البحث للقراءة فقط، وعمليات CRUD على قاعدة البيانات، والبحث، وأي شيء يغلّف REST API لا يوجد ما تحتاج إلى تذكره، لذا فالتحول يعني في معظمه حذف الشيفرة. تكسب عمليات نشر أبسط، وملاءمة طبيعية لمنصات الحوسبة بلا خوادم، وأعطالًا تصيب طلبًا واحدًا بدلًا من محادثة كاملة.

بعض الأدوات تحتفظ بشيء حي: صفحة متصفح، أو صدفة (shell)، أو تصيير قيد التنفيذ. احتفظ بتلك الحالة، لكن ضعها خلف معرّف له مدة صلاحية، في مخزن يمكن لكل نسخة الوصول إليه. البروتوكول عديم الحالة. أما الواجهة الخلفية فليس عليها أن تكون كذلك.

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

توليد الصور عبر 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 لإيقافها.

معرّفات التنبؤ معرّفات أيضًا

التوليد غير متزامن. يعيد بدء المهمة معرّف تنبؤ فورًا، ويستدعي المساعد أداة الحالة بهذا المعرّف بعد فترة الانتظار المقترحة، مرارًا وتكرارًا، حتى تظهر الحالة succeeded أو failed. لا يبقى اتصال مفتوح خاملًا أثناء عمل وحدة GPU، ويحمل المعرّف كل الاستمرارية. إنه نمط basket_id مطبّق على الصور.

بعض الحدود تستحق المعرفة عند تخطيط سير العمل: 5 تنبؤات متزامنة لكل حساب، مشتركة بين الرموز واتصالات MCP، وأوامر نصية تصل إلى 4,000 حرف، ومهلة 3 ساعات لكل مهمة.

النماذج التي يمكنك استدعاؤها

هذه النماذج الأربعة متاحة عبر كلٍّ من واجهة API واتصال MCP:

• PicassoIA Image لتحويل النص إلى صورة
• PicassoIA Image Editor Pro لتعديل صورة موجودة
• PicassoIA Video لإنشاء فيديو من نص أو صورة
• Seedance 2.5 Lite لإنشاء فيديو مع صوت

الصور في هذا المقال جاءت من P Image، وهو واحد من نماذج تحويل النص إلى صورة الكثيرة على المنصة. عند كتابة أوصاف الأدوات ومخططات JSON التي سيعرضها خادم MCP الخاص بك، يوفر نموذج لغوي كبير الوقت. Claude Sonnet 5، وGPT 5.6 Sol، وGemini 3.5 Flash كلها متاحة لصياغة هذا النوع من النص المنظم ومراجعته.

دورك الآن: أنشئ صورًا مع Picasso IA

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

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