تطوّر MCP نحو البروتوكول عديم الحالة
شهد بروتوكول Model Context Protocol أهم تغيير في البنية التحتية منذ إطلاقه. مواصفة 2026-07-28 تنقل MCP من بروتوكول ذي حالة إلى بروتوكول عديم الحالة.
إذا سبق لك أن عانيت من sticky sessions أو تخزين الجلسات في Redis أو أخطاء "session not found" بعد إعادة تشغيل Pod — فهذا التحديث موجّه إليك.
مشكلة MCP ذي الحالة
كانت إصدارات MCP السابقة تتطلّب مصافحة initialize. يتتبّع العميل معرّف Mcp-Session-Id. وهذا المعرّف كان يثبت العميل على نسخة خادم محدّدة.
في العروض المحلية لم يلاحظ أحد. في الإنتاج كان الأمر مؤلماً:
- موازنات الأحمال تحتاج sticky sessions
- النشر على عدة Pods يحتاج حالة جلسة مشتركة (غالباً Redis)
- إذا فشلت نسخة، تفشل الجلسة معها
- المنصات التي تتقلّص إلى الصفر لا تستطيع الإقلاع البارد وسط جلسة نشطة
لم تكن تبني خادم MCP. كنت تبني نظام ارتباط جلسات يعرض أدوات بالمصادفة.
ما الذي تغيّر في المواصفة الجديدة
عديم الحالة افتراضياً
اختفت مصافحة initialize. واختفى ترويسة Mcp-Session-Id. كل طلب أصبح مكتفياً بذاته.
هذا يعني:
- موازنة round-robin القياسية تعمل
- أي Pod يمكنه معالجة أي طلب
- الخوادم يمكنها التقلّص إلى الصفر على Cloudflare Workers وCloud Run وما شابه
- فشل النسخة لم يعد يترك جلسة العميل معلّقة
توجيه أصلي عبر HTTP
ترويسات طلب جديدة — Mcp-Method وMcp-Name — تتيح للبوابات توجيه الحركة دون تحليل أجسام JSON. زمن استجابة أقل. بروكسيات حافة أنظف. وسطاء مخصّصة أقل.
تلميحات التخزين المؤقت
يمكن لاستدعاءات قوائم الأدوات والـ prompts والموارد أن تعيد تلميحات ttlMs وcacheScope. نفس فكرة تخزين HTTP المؤقت: أخبر العميل كم من الوقت تبقى القائمة آمنة لإعادة الاستخدام، وهل التخزين خاص أم قابل للمشاركة.
الحالة في واجهتك البرمجية لا في البروتوكول
تحتاج استمرارية بين الاستدعاءات؟ مرّر المعرّفات كوسائط للأدوات. خزّن حالة سير العمل في قاعدة بياناتك. استخدم نفس أنماط واجهات REST العادية.
جلسات مستوى البروتوكول كانت اختصاراً. وأصبحت أيضاً ضريبة على التوسّع. النموذج الجديد يدفع الحالة إلى مكانها الطبيعي — طبقة النطاق لديك.
سير العمل دون اتصالات دائمة
كان MCP ذو الحالة يغطي التفاعلات متعددة الخطوات بجلسات طويلة العمر. المواصفة الجديدة تستبدل ذلك بأنماط طلب/استجابة صريحة.
input_required للمتابعات
عندما يحتاج الخادم تأكيداً ("هل أنت متأكد أنك تريد الحذف؟") يعيد نتيجة input_required. يعيد العميل تقديم الاستدعاء مع المدخل المطلوب. لا حاجة لاتصال مفتوح. ولا لارتباط جلسة.
المهام للعمل طويل الأمد
تخرج العمليات طويلة الأمد من التجربة إلى امتداد رسمي. يتتبّع العملاء التقدّم عبر task/get أو الاشتراكات بدلاً من إبقاء الاتصال مفتوحاً لدقائق.
هذا الشكل الصحيح لأعباء الوكلاء: ابدأ العمل، راقب أو اشترك، ثم تابع.
ماذا يعني هذا إن كنت تبني خوادم MCP اليوم
| قبل | بعد |
|---|---|
| Sticky sessions / Redis | عمّال عديمو الحالة |
initialize + معرّف جلسة |
طلبات مكتفية بذاتها |
| حالة جلسة يملكها البروتوكول | معرّفات وحالة في وسائط الأدوات / قاعدة بياناتك |
| اتصال دائم للمتابعات | جولات input_required |
| واجهات مهام تجريبية | امتداد مهام رسمي |
إذا كنت تصمّم خادماً جديداً، ابدأ من نموذج 2026-07-28. لا تخترع مخزن جلسات لن تحتاجه.
إذا كنت ترقّي خادماً قائماً:
- أزل الاعتماد على
Mcp-Session-Id - اجعل كل استدعاء أداة قابلاً للمصادقة والتوجيه بشكل مستقل
- انقل أي سياق عبر الاستدعاءات إلى الوسائط أو طبقة التخزين لديك
- اعتمد
input_requiredلتدفقات التأكيد - استخدم امتداد المهام للعمل الذي يتجاوز طلب HTTP واحداً
نافذة الترقية
هذا تغيير كاسر — والمشروع عامله كذلك. هناك نافذة إهمال لمدة 12 شهراً لسلوك الجلسات القديم، وإصدارات SDK الرئيسية (v2.0) تستهدف المواصفة الجديدة بالفعل.
لا تنتظر حتى تُغلق النافذة. MCP عديم الحالة أبسط تشغيلاً، وأرخص توسّعاً، وأقرب إلى طريقة عمل واجهات HTTP الإنتاجية أصلاً.
الخلاصة
توقّف MCP عن التظاهر بأنه بروتوكول جلسات طويلة العمر وأصبح ما تحتاجه أنظمة الإنتاج: واجهة عديمة الحالة ومتوافقة مع HTTP للأدوات.
أجزاء متحركة أقل. توسّع أفضل. ملكية أوضح للحالة.
إذا كنت تخطّط لهجرة أو إطلاق إنتاجي، أرسل بريدك لتحصل على دليل MCP الإنتاجي مجاناً — تكامل قابل للتوسّع، قائمة تحقق 2026-07-28، وموجز جاهز للمورّدين.