تجرد مواصفات MCP لشهر يوليو 2026 كل أشكال حالة الجلسة (session state) من طبقة البروتوكول، مما يجبر جميع الحالات على العيش داخل نافذة سياق النموذج (model's context window). يتيح هذا التغيير لأي خادم MCP الإجابة على أي طلب، مما يفتح الباب أمام عمليات النشر عديمة الحالة تمامًا (pure-stateless deployments) خلف موازنات الحمل (load balancers)، والوظائف عديمة الخادم (serverless functions)، وحاويات Kubernetes القابلة للتوسع تلقائيًا (autoscaling Kubernetes pods).

لماذا يهم هذا التغيير

منذ إصداره الأول، حافظ بروتوكول MCP (Model Communication Protocol) على مصافحة جلسة (session handshake) خفيفة الوزن وترويسة Mcp-Session-Id لتتبع حالة المحادثة عبر استدعاءات HTTP المتعددة. سمح هذا التصميم للخادم بتذكر مقابض الأدوات (tool handles)، أو معدلات أخذ العينات (sampling rates)، أو تفضيلات التسجيل (logging preferences) الخاصة بعميل معين. كما وفر تدفقات أحداث خادم المرسل (Server-Sent Events - SSE) القابلة للاستئناف، بحيث يمكن للاتصال المنقطع أن يكمل من حيث توقف.

تلغي مواصفات 28 يوليو 2026 مصافحة الجلسة تمامًا. يحمل كل طلب الآن إصدار البروتوكول وقدرات العميل في حقل _meta ، وتختفي ترويسة Mcp-Session-Id. كما تم وضع علامة "مهجور" (deprecated) على حقول Roots وsampling وlogging. باختصار، أصبح بروتوكول الأسلاك (wire protocol) الآن عبارة عن طلب-استجابة (request-response) بحت؛ لا توجد "جلسة" للحفاظ عليها.

ما الذي سيتعين على المطورين فعله بشكل مختلف

لم تعد الحالة من شأن الخادم؛ بل أصبحت تعيش داخل نافذة سياق النموذج. عندما يحتاج النموذج إلى الإشارة إلى مورد خارجي، يجب أن يتلقى مقبضًا (handle) صريحًا من الخادم كجزء من نتيجة الأداة. يتضمن الطلب التالي هذا المقبض كمعامل (argument)، ويعامله النموذج مثل أي رمز (token) آخر.

نظرًا لأن نافذة السياق هي مخزن مؤقت للرموز (token buffer) ثابت الحجم، فإن كل مقبض يستهلك مساحة تتنافس مع مطالبات المستخدم (user prompts) أو مخرجات النموذج.

تتغير الموثوقية أيضًا. فبدون إمكانية استئناف SSE أو إعادة تسليم الرسائل، يؤدي انقطاع التدفق إلى فقدان الطلب تمامًا. يجب على العملاء إعادة تشغيل الاستدعاء من البداية. هذا أمر مقبول للاستعلامات السريعة عديمة الحالة؛ أما بالنسبة لعمليات الاسترداد طويلة الأمد أو مهام الوكيل (agent tasks) متعددة الخطوات، فإنه يجبر المطورين على بناء منطق إعادة المحاولة الخاص بهم أو تقسيم المهمة إلى أجزاء أصغر.

بروتوكول Pilot يسد الفجوة

إن انعدام الحالة في MCP أمر متعمد، لكنه يترك طبقة الشبكة بدون هوية على مستوى الاتصال أو ضمانات للموثوقية. وهنا يأتي دور Pilot Protocol، الذي يعمل تحت MCP، ليسد هذه الفجوة. يقوم Pilot بإنشاء الهوية مرة واحدة ويستخدم التشفير لربط الحزم بالمرسل. من وجهة نظر MCP، يرسل العميل ببساطة طلب HTTP جديد في كل مرة؛ بينما يحافظ Pilot على استقرار النقل الأساسي.

يكمل البروتوكولان بعضهما البعض: يظل MCP رشيقًا، ومنخفض التكلفة لكل طلب، وسهل التوسع خلف أي نقطة نهاية HTTP، بينما يتولى Pilot المهام الثقيلة التي كانت توفرها البروتوكولات التقليدية القائمة على الجلسة.

الفوائد عند التوسع

  • صديق لموازنات الحمل – لا حاجة لتقارب الجلسة (session affinity)؛ يمكن لأي واجهة خلفية (backend) خدمة أي طلب.
  • جاهز للأنظمة عديمة الخادم – يمكن للوظائف أن تعمل عند الطلب، وتعالج طلبًا، ثم تتوقف عن العمل دون ترك حالة عالقة.
  • توسع تلقائي في Kubernetes – يمكن إضافة الحاويات (Pods) أو إزالتها بحرية؛ لم تعد لوحة التحكم (control plane) تتبع خرائط الجلسات.

المقايضات

  • عبء الرموز (Token overhead) – تشغل المقابض وأي حالة أخرى الآن نافذة سياق النموذج، مما يتنافس مباشرة مع المطالبة والاستجابة.
  • الدقة المعتمدة على النموذج – يجب على النموذج إعادة صدى المقابض بشكل صحيح؛ حيث يمكن أن تؤدي الهلوسة أو الخطأ المطبعي إلى كسر سير العمل.
  • عدم وجود إمكانية استئناف مدمجة – يجب على المهام طويلة الأمد تنفيذ نقاط التحقق (checkpointing) الخاصة بها أو قبول مخاطر إعادة التشغيل الكاملة.
  • إلغاء التشخيصات – اختفت حقول Roots وsampling وlogging، لذا يفقد المطورون وسيلة سهلة للمراقبة الدقيقة ما لم يضيفوها في طبقة التطبيق.

الخلاصة

من خلال محو حالة الجلسة من الأسلاك، يحول MCP 2026-07 البروتوكول إلى نقطة نهاية HTTP بحتة يمكن أن توضع خلف أي موازن حمل، أو منصة وظائف، أو عقدة طرفية (edge node). الميزة واضحة وهي القابلية للتوسع؛ أما العيب فهو أن الحالة تعيش الآن في نافذة الرموز المحدودة للنموذج، وتعتمد الموثوقية على العميل وطبقة Pilot الأساسية. ومع امتداد مهام وكلاء الذكاء الاصطناعي من ثوانٍ إلى ساعات، فإن التوازن بين تسعير الطلب الرخيص وضغط ميزانية الرموز هو ما سيحدد ما إذا كان النموذج عديم الحالة سيثبت نجاحه الدائم.