سيتم إطلاق الإصدار الثاني من MCP في 28 يوليو 2026. يتخلص هذا الإصدار من كل عمليات المصافحة (handshake)، وترويسة معرف الجلسة (session-ID header)، والأنظمة الفرعية الثلاثة القديمة التي ربطت بروتوكول سياق النموذج (Model Context Protocol - MCP) بخوادم الجلسات الثابتة (sticky-session servers). سيصبح البروتوكول عديم الحالة (stateless) تماماً، بحيث يمكن لأي مثيل (instance) يتم توسيعه تلقائياً أو يعمل بتقنية serverless التعامل مع أي طلب دون الحاجة للحفاظ على حالة العميل.

لماذا يمثل هذا التحول أهمية؟

أجبر الإصدار الأول (v1) من MCP العميل على بدء جلسة عبر عملية مصافحة initialize؛ ومن ثم يقوم الخادم بتعيين Mcp-Session-Id. وكان لزاماً على كل استدعاء لاحق أن يحمل تلك الترويسة، مما يربط المستخدم بعقدة خلفية (backend node) واحدة. وكان على موازنات الحمل (Load balancers) فرض تقارب الجلسة (session affinity)، مما يؤدي إلى زيادة زمن الاستجابة (latency) وصعوبات تشغيلية.

تلغي خاصية "عدم حفظ الحالة" (Statelessness) تلك الصعوبات. فكل السياقات تعيش الآن في حقول وصفية (meta fields) مخصصة تنتقل مع كل استدعاء HTTP. يمكن لأي طلب أن يستقر في أي مثيل، ويتم معالجته، ثم يمكن التخلص من هذا المثيل بمجرد إرسال الاستجابة. يمكن للفرق التي تستخدم منصات serverless، أو مجموعات (clusters) مدارة بالحاويات (container-orchestrated)، أو أي بيئة تقوم بتشغيل وإيقاف الحاويات (pods) حسب الطلب، أن تواءم البروتوكول مع بنيتها التحتية الآن.

ما الذي سيتم إيقافه؟

تم إيقاف ثلاثة أنظمة فرعية كانت تعتمد على الاتصالات المستمرة رسمياً:

  • Sampling – في الإصدار v1، كان بإمكان الخادم أن يطلب من العميل إنشاء نص، وهو نمط يتطلب جلسة مفتوحة. أما في الإصدار v2، فيُتوقع من الخادم استدعاء مزود النموذج اللغوي الكبير (LLM provider) مباشرة أو استخدام نمط InputRequiredResult حيث يقدم العميل المدخلات المفقودة في طلب لاحق.
  • Roots – سابقاً، كان العملاء يرسلون معرفات URIs تحد من رؤية الخادم للموارد الخارجية. أما النهج الجديد فيمرر هذه المعرفات كمعلمات للأدوات (tool parameters) أو يدمجها في حقول الموارد الخاصة بالطلب، مما يلغي خطوة التفاوض المنفصلة الخاصة بـ "roots".
  • Logging – ستختفي ترويسات تسجيل الأحداث (logging headers) على مستوى البروتوكول. استخدم stderr لتصحيح الأخطاء محلياً أو اعتمد OpenTelemetry لمراقبة الإنتاج (production observability).

تستمر فترة الإيقاف لمدة عام واحد. ستظل الميزات التي تم إيقافها تعمل خلال هذه الفترة، مما يمنح الفرق وقتاً لإعادة هيكلة الكود (refactor) قبل أن يرفضها البروتوكول.

ما الجديد بخلاف خاصية عدم حفظ الحالة؟

يضيف MCP v2 ملحقين رسميين:

  • MCP Apps – طريقة خفيفة لوصف واجهات المستخدم التي يتم عرضها من جانب الخادم (server-rendered) والتي يمكن للبروتوكول استدعاؤها.
  • Tasks – نمط للتعامل مع العمليات طويلة الأمد التي قد تمتد عبر دورات متعددة من الطلب والاستجابة.

يفترض كلا الملحقين نموذج الطلب عديم الحالة ويتجنبان حالة الجلسة المخفية.

المخاطر والنقاط المقابلة

هذا التغيير ليس ترقية مباشرة (plug-and-play). لا تزال حزم تطوير البرمجيات (SDKs) للإصدار v2 في المرحلة التجريبية (beta)، وقد تتغير واجهاتها البرمجية العامة (public APIs) قبل إصدار نسخة مستقرة. بالنسبة لأعباء العمل في بيئة الإنتاج التي لا تتحمل التغييرات الجذرية (breaking changes)، استمر في استخدام SDK الإصدار v1 المستقر حتى يتم اعتماد SDK الإصدار v2.

يحتاج المطورون أيضاً إلى مراجعة الكود الحالي بحثاً عن أي من الأنظمة الفرعية الثلاثة التي تم إيقافها.

خارطة طريق عملية للهجرة

  1. أجرِ عملية التدقيق اليوم – افحص خدماتك بحثاً عن استخدام المصافحة (handshake)، و Mcp-Session-Id ، واستدعاءات sampling، ومعرفات roots URIs، وتسجيل الأحداث على مستوى البروتوكول. حدد الكود الذي قد يتعطل في ظل نموذج عديم الحالة.
  2. اختبر على عقدة غير حرجة – عند إصدار SDK مستقر للإصدار v2، قم بتشغيل خادم تجريبي (sandbox server)، ووجهه إلى عميل اختبار، وتحقق من وجود جميع الحقول الوصفية المطلوبة وتفسيرها بشكل صحيح.
  3. إتمام الهجرة الكاملة قبل الموعد النهائي – أكمل عملية الانتقال في جميع عقد الإنتاج قبل انتهاء فترة السماح التي تبلغ عاماً واحداً لتجنب الرفض أثناء التشغيل (runtime rejections).

ما الذي يجب مراقبته لاحقاً

  • إصدار SDK مستقر – سيتم تجميد الـ SDKs التجريبية وسيتم نشر حزمة مستقرة ذات إصدار محدد. سيكون هذا الإصدار هو الهدف الآمن لأي عملية نشر حرجة.

سيتطلب الانتقال تغييرات في الكود وفترة قصيرة من التجريب باستخدام الـ beta-SDK، ولكن العائد سيكون نقطة تكامل أكثر نظافة وقابلية للتوسع لأي تطبيق مدعوم بالنماذج اللغوية الكبيرة (LLM).

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