بروتوكول MCP ينشر خريطة طريق جديدة تركّز على HTTP وهوية الوكلاء

نشر القائمون الأساسيون (Core Maintainers) على بروتوكول Model Context Protocol (MCP)، المعيار المفتوح الذي تستضيفه مؤسسة Agentic AI Foundation (AAIF) التابعة لمؤسسة Linux Foundation، خريطة طريق محدّثة تحدد اتجاه البروتوكول للإصدار المقبل من المواصفات وما بعده. وبحسب ما ذكره الموقع التقني الياباني Publickey، تتمحور خريطة الطريق حول خمسة مجالات ذات أولوية: المراسلة الموجهة للوكلاء، توحيد النقل حول HTTP، هوية الوكلاء والأمن الجاهز للمؤسسات، تحسين الأدوات الأساسية، وتجربة أفضل لمطوري حزم SDK. وتؤكد المدونة الرسمية لـMCP أن خريطة الطريق أعدّها القائمون الأساسيون بالتعاون مع مجتمع مجموعات العمل (Working Groups)، وأنها "تحدد اتجاه العمل على البروتوكول خلال الأشهر المقبلة".

وُلد MCP في نوفمبر 2024 كبروتوكول اقترحته شركة Anthropic لربط نماذجها من عائلة Claude بمصادر بيانات وأدوات خارجية. وفي 9 ديسمبر 2025، أعلنت مؤسسة Linux Foundation أنها تلقّت تبرعًا بالبروتوكول وأسّست مؤسسة Agentic AI Foundation لإدارة تطوره، بعضوية بلاتينية تضم Amazon Web Services وAnthropic وBlock وBloomberg وCloudflare وGoogle وMicrosoft وOpenAI. ووفق إعلان Linux Foundation، أصبح MCP أحد أسرع مشاريع المصادر المفتوحة نموًا خلال العام الماضي، بأكثر من 97 مليون عملية تنزيل شهرية لحزم SDK وأكثر من 10 آلاف خادم نشط، وهو مدمج بشكل أساسي في ChatGPT وClaude وCursor وGemini وMicrosoft Copilot وVisual Studio Code. وفي يوليو الماضي، وصل امتداد "Enterprise-Managed Authorization" (EMA)، الذي يتيح إدارة صلاحيات الوصول بشكل موحّد، إلى النسخة المستقرة، كما تحوّل البروتوكول إلى اتصالات عديمة الحالة (stateless) في تحديث كبير يسهّل عمليات التوسع واسعة النطاق.

خمسة مجالات ذات أولوية

وبحسب المقال الرسمي "The New MCP Roadmap"، يبني هذا التحديث على خريطة الطريق السابقة المنشورة في مارس، والتي تضمنت أربع أولويات: تطور النقل وقابلية التوسع، التواصل بين الوكلاء، نضج الحوكمة، والجاهزية للمؤسسات. ووصل معظم التقدم المُحرز خلال الأشهر الخمسة الماضية إلى إصدار المواصفات الصادر في 28 يوليو 2026 (2026-07-28). فقد أُلغيت الجلسات على مستوى البروتوكول ومصافحة التهيئة الأولية، ما يتيح للخوادم التوسع أفقيًا دون الحاجة إلى الاحتفاظ بحالة (SEP-2575 وSEP-2567)؛ وحصلت العملاء (clients) على استدعاء جديد باسم `server/discover` للتعرف على قدرات الخادم قبل الاتصال به؛ كما أصبحت نتائج القوائم قابلة للتخزين المؤقت (caching) بموجب SEP-2549.

• المراسلة الموجهة للوكلاء: بناء أحداث يبادر بها الخادم (webhooks وقنوات) حتى لا تضطر العملاء إلى الاستعلام المتكرر عن النتائج، وتطوير امتداد Tasks (SEP-2663) تمهيدًا لإدماجه في المواصفات الأساسية
• توحيد النقل حول HTTP: توسيع Streamable HTTP ليشمل الخوادم المحلية أيضًا، عبر تشغيل HTTP/2 فوق stdio للحفاظ على مزايا تعدد الإرسال دون فقدان ضمانات الأمان ودورة الحياة الخاصة بالعملية الفرعية
• هوية الوكلاء والأمن الجاهز للمؤسسات: إنهاء مواصفة Demonstrating Proof of Possession (DPoP) ودفع اعتمادها، وتحديد هوية الوكلاء وتفويضهم عبر Workload Identity Federation (SEP-1933) وتبادل رموز ID-JAG، بدلًا من مفاتيح API الملصقة أو الرموز طويلة الصلاحية
• تحسين الأدوات الأساسية: توحيد شكل استجابات `tools/call` وإدخال آلية الاكتشاف التدريجي (progressive discovery)، بحيث لا يضطر النموذج لتحميل كامل كتالوج أدوات الخادم قبل أن يطرح المستخدم سؤاله الأول
• تحسين تجربة مطوري SDK: صقل سهولة استخدام واجهات البرمجة ودقة التوثيق، لأن عددًا متزايدًا من المطورين — بل ووكلاء الذكاء الاصطناعي أنفسهم — بات يكتب أكواد عملاء أو خوادم MCP اعتمادًا مباشرة على حزم SDK

ما الذي يحله هذا التحديث للشركات

يفترض نموذج التفويض الحالي في MCP أن يوافق إنسان على الوصول عبر المتصفح. لكن المدونة الرسمية تشير إلى أن حصة متزايدة من المتصلين بالبروتوكول باتت وكلاء يعملون كأحمال عمل سحابية (cloud workloads) ذات هوية خاصة بها، تتصرف نيابة عن مستخدم غير حاضر، أو تفوّض صلاحيات أضيق لوكلاء فرعيين. ويهدف العمل على الهوية ضمن خريطة الطريق إلى منح خوادم MCP طريقة موحدة للتعرف على هويات هؤلاء الوكلاء والثقة بها، استنادًا إلى معايير قائمة بدلًا من مفاتيح API الملصقة، بالتنسيق مع مجموعتي عمل IETF OAuth وWIMSE بشأن آلية تبادل الرموز الأساسية. ويحمل توحيد النقل حول HTTP أهمية تشغيلية مماثلة: فخادم MCP بعيد مبني على Streamable HTTP لم يعد يختلف عن أي حمل عمل HTTP آخر، ما يتيح للشركات استضافته وتوسيعه على البنية التحتية ذاتها — موازنات الحمل والبوابات وأدوات المراقبة — التي تستخدمها أصلًا لواجهات برمجتها، بدلًا من بناء بنية مخصصة لبروتوكول منفصل.

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

لماذا يهم هذا الفرق التي تبني وكلاء ذكاء اصطناعي

يُعد MCP بالفعل الوصلة التي تستخدمها معظم منتجات الذكاء الاصطناعي الكبرى — ChatGPT وClaude وCursor وGemini وMicrosoft Copilot وVisual Studio Code — للوصول إلى أدوات خارجية، ما يجعل خريطة الطريق هذه أكثر بكثير من وثيقة هندسية داخلية: إنها تشير إلى الوجهة المقبلة للمعيار الفعلي لربط الوكلاء بالأدوات. وبالنسبة للشركات التي تربط وكلاء الذكاء الاصطناعي بأنظمتها الداخلية، من المتوقع أن يخفّض العمل على توحيد HTTP التكلفة التشغيلية لتشغيل خوادم MCP على نطاق واسع، إذ لن تعود هناك حاجة لبنية تحتية منفصلة للنشر عبر stdio أو WebSocket. أما العمل على الهوية فيعالج خطرًا ملموسًا تعيشه الفرق فعليًا: مفاتيح API مشتركة بين خدمات متعددة أو تبقى صالحة بعد تغيّر موقع موظف ما. وتوفر طريقة موحدة لتحديد نطاق بيانات اعتماد خاصة بكل وكيل وإلغاؤها عند الحاجة، مدعومة بسجلات تدقيق، بديلًا عن مشاركة المفاتيح بشكل غير رسمي بنظام يمكن لفريق الأمن التحكم فيه فعليًا. وينبغي للمؤسسات التي تعتمد اليوم على رموز طويلة الصلاحية لمصادقة اتصالات MCP أن تعتبر هذا التحديث إشارة مبكرة للبدء في التخطيط لمسار انتقال بمجرد اكتمال العمل على الهوية والتفويض.