ترقية خادم MCP إلى مواصفة 2026-07-28 عديمة الجلسة

إذا كان خادم MCP لديك ما زال ينشئ جلسة، ويعيد ترويسة Mcp-Session-Id، وينتظر notifications/initialized، فهو يعمل وفق البنية القديمة. الترقية إلى مواصفة 2026-07-28 لا تعني نقل الجلسة نفسها إلى Redis، بل تعني أن تكون كل مطالبة مفهومة بذاتها.

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

يسجل سجل التغييرات الرسمي تعديلين حاسمين. أولًا، أزيلت الجلسات على مستوى البروتوكول وترويسة Mcp-Session-Id من Streamable HTTP، ولم تعد قوائم tools/list وresources/list وprompts/list تتغير باختلاف الاتصال. ثانيًا، أزيل تسلسل initialize ثم notifications/initialized في الإصدار الحديث. أصبحت معلومات الإصدار والقدرات والهوية مرتبطة بكل طلب. هذا هو النص المعياري. أما قرارنا الهندسي فهو الاحتفاظ بحالة العمل فقط عند الحاجة، مع مالك وصلاحية ومدة انتهاء واضحة.

لنرقِّ خادمًا ينشئ تقارير. في النسخة القديمة، يقرأ المعالج Mcp-Session-Id، ويبحث عن كائن جلسة، ثم يخزن مسودة التقرير داخله. نحذف قارئ الترويسة وطبقة الجلسات وجدولها وعلامة initialized. ثم نضيف مدققًا مشتركًا يقرأ protocolVersion وclientCapabilities من _meta. وفي HTTP نقارن الإصدار مع MCP-Protocol-Version. إذا لم يكن مدعومًا، نعيد UnsupportedProtocolVersionError مع الإصدارات المدعومة بدل التخمين الصامت.

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

نضيف كذلك server/discover للإعلان عن الإصدارات والقدرات والهوية. وفي ترقية تدريجية، يستطيع خادم يدعم الجيلين تمييز الطلب الحديث من بيانات _meta، مع عزل مسار initialize القديم للعملاء القدامى. ولا يجوز أن تتسرب حالة المسار القديم إلى قوائم المسار الحديث.

الاختبار يتكون من خمس نقاط: تعمل tools/list من دون initialize ومن دون ترويسة جلسة؛ ويعيد اتصال HTTP جديد القائمة نفسها؛ وتعيد create_report معرّفًا، بينما تفشل update_report من دونه وتنجح به عبر اتصال آخر؛ ويعيد الإصدار غير المدعوم الخطأ المحدد؛ ولا يحتاج المسار الحديث إلى notifications/initialized. ثم نشغّل مستخدمين بالتوازي ونتأكد من أن معرّف أحدهما لا يفتح تقرير الآخر.

النجاح يعني خمسًا من خمس: لا Mcp-Session-Id، ولا اعتماد حديث على initialize، وبيانات إصدار وقدرات لكل طلب، ومعرّفات صريحة ومصرح بها، واختبارات عبر اتصالات مختلفة. عبارة stateless لا تعني عدم وجود أي حالة عمل؛ بل تعني ألا يخفي البروتوكول الحالة داخل الاتصال. ضع روابط المواصفة وسجل التغييرات والنقل وملفات SEP بجانب طلب الدمج، وثبّت الاختبارات على عقد 2026-07-28. ويمكن لـ Optijara مساعدتك في تصميم حدود التوافق وخطة اختبار قابلة للتدقيق.