MCP في 2026: Streamable HTTP وOAuth 2.1 والموت الصامت لواجهة Resources

قدمت Anthropic بروتوكول Model Context Protocol في 25 نوفمبر 2024 كمعيار مفتوح لربط وكلاء الذكاء الاصطناعي بالأدوات ومصادر البيانات الخارجية. عالج ما يسميه المهندسون مشكلة M-ضرب-N: الانفجار التوافقي لربط M نموذج ذكاء اصطناعي مختلف بـN أداة مختلفة، كل منها يتطلب كود تكامل مخصص. اختزل MCP هذا إلى: نفّذ بروتوكول العميل مرة واحدة، نفّذ بروتوكول الخادم مرة واحدة، وكل شيء يتصل.

اكتسب البروتوكول زخماً سريعاً. تبنت OpenAI بروتوكول MCP عبر Agents SDK وResponses API وتطبيق سطح المكتب ChatGPT في مارس 2025. أكدت Google DeepMind دعم Gemini في أبريل 2025. أعلنت Microsoft تكامل MCP مع Windows 11 وAzure وFoundry في مؤتمر Build 2025. بحلول ديسمبر 2025، تبرعت Anthropic بـMCP لمؤسسة Agentic AI Foundation الجديدة تحت مظلة Linux Foundation، المشتركة التأسيس مع OpenAI وBlock، بدعم من AWS وGoogle وMicrosoft وCloudflare وBloomberg. بلغ البروتوكول 97 مليون تنزيل شهري لحزمة SDK وأكثر من 10,000 خادم نشط.

لكن خلف أرقام التبني، خضعت المواصفات نفسها لتطور كبير. صدرت أربع إصدارات في ما يزيد قليلاً عن عام: الإصدار الأولي (2024-11-05)، وإصلاح شامل لطبقة النقل والمصادقة (2025-03-26)، ومرحلة تحسين (2025-06-18)، وإصدار الذكرى السنوية الأولى (2025-11-25). تغيرت طبقة النقل. تمت توحيد المصادقة. انزلقت إحدى البدائيات الأساسية الثلاث نحو عدم الجدوى العملية. وظهر تحدٍ جديد — تضخم نافذة السياق — مع دفع الفرق لـMCP نحو الإنتاج على نطاق واسع.

هذه ليست تحديثات تجميلية. إنها تعكس دروساً صعبة حول كيفية استخدام وكلاء الذكاء الاصطناعي للبروتوكولات فعلياً في الإنتاج، ولها آثار مباشرة على أي شخص يبني أو يستهلك خوادم MCP اليوم.

التصميم الأصلي: ثلاث بدائيات

أُطلق MCP بثلاث بدائيات أساسية، كل منها مصممة لنمط تفاعل مختلف:

Tools هي وظائف يتحكم فيها النموذج يمكن للوكيل استدعاؤها. إنشاء تذكرة، إرسال بريد إلكتروني، استعلام قاعدة بيانات. كل أداة لها اسم ووصف ومخطط معاملات. يقرأ النموذج اللغوي الكبير (LLM) أوصاف الأدوات ويقرر متى يستدعيها. هذه هي البدائية النشطة والوكيلية — التي تتيح لأنظمة الذكاء الاصطناعي اتخاذ إجراءات في العالم.

Resources هي مصادر بيانات يتحكم فيها التطبيق. مستندات، سجلات، ملفات تكوين. على عكس الأدوات، التطبيق هو الذي يقرر متى يسترجع الموارد ويمررها كسياق للنموذج. صُمم Resources كآلية قابلة للتصفح، للقراءة فقط، لكشف المعلومات دون الحاجة إلى استدعاءات وظائف.

Prompts هي قوالب تعليمات معرّفة مسبقاً تكشفها خوادم MCP لهيكلة سلوك الوكيل لمهام محددة. تعمل على توحيد كيفية تعامل النماذج مع العمليات الشائعة وضمان الاتساق بين الفرق التي تستخدم نفس الخادم.

استخدم النقل الأولي HTTP مع Server-Sent Events (SSE) للبث من الخادم إلى العميل. تُركت المصادقة للتطبيقات الفردية — عادةً رموز API مخزنة في متغيرات البيئة.

التحول 1: بدائية Resources التي تجاوزها المطورون

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

في الممارسة العملية، ثبت أن التمييز أقل فائدة مما كان متوقعاً. استعلام بيانات — “الحصول على سجل العميل للمعرّف 12345” — يعمل بشكل مطابق كاستدعاء أداة مع معاملات. بدائية Tools مرنة بما يكفي للتعامل مع كل من الإجراءات (إنشاء، تحديث، حذف) والاستعلامات (قراءة، بحث، سرد). توجيه كل شيء عبر الأدوات يمنح LLM واجهة واحدة ومتسقة للتفاعل مع الأنظمة الخارجية.

هذا مرئي في منظومة خوادم MCP. افحص التطبيقات المجتمعية والخدمات السحابية والمشاريع مفتوحة المصدر: التصميمات المرتكزة على الأدوات هي المهيمنة. Resources موجود في المواصفات ومدعوم من حزم SDK المتوافقة، لكن المجتمع تقارب بشكل كبير نحو الأدوات كبدائية شاملة.

النمط مألوف من تاريخ البروتوكولات. المواصفات الأولية ترمي شبكة واسعة — بدائيات متعددة تغطي أنماط تفاعل نظرية مختلفة. الممارسة تُبسّط. يكتشف المجتمع أي التجريدات تستحق وزنها في الإنتاج وأيها يضيف مساحة سطحية دون قيمة متناسبة.

Resources لم يُوقف رسمياً. يبقى في كل إصدار من المواصفات حتى 2025-11-25 وموثق مع دعم SDK كامل. لكن عدم جدواه العملية إشارة مهمة للمطورين: عند تصميم خوادم MCP، استثمروا في الأدوات.

التحول 2: Streamable HTTP يحل محل SSE

استخدم النقل الأصلي Server-Sent Events — بروتوكول بث أحادي الاتجاه يتطلب من الخادم الحفاظ على اتصال مستمر لدفع التحديثات إلى العميل. عمل هذا مع الوكلاء المحليين لكنه خلق مشاكل خطيرة على نطاق واسع.

لماذا فشل SSE في الإنتاج

يتطلب SSE اتصالات مستمرة. في البيئات بدون خادم (serverless) — AWS Lambda وCloudflare Workers وVercel Functions — الحفاظ على اتصالات مستمرة إما مستحيل أو باهظ التكلفة. المؤسسات التي أرادت نشر خوادم MCP كوظائف serverless اضطرت إلى حلول بديلة أو لم تتمكن من استخدام MCP على الإطلاق.

حتى في بيئات الخوادم التقليدية، تخلق الاتصالات المستمرة عبئاً تشغيلياً: تجميع الاتصالات وإدارة المهلات ومنطق إعادة الاتصال وتوزيع الأحمال تصبح كلها أصعب عندما يجب أن تبقى الاتصالات حية إلى ما لا نهاية. تعترف خارطة طريق MCP 2026 بهذا صراحةً، مشيرةً إلى أن تشغيل streamable HTTP على نطاق واسع كشف ثغرات حيث تتصادم الجلسات ذات الحالة مع موازنات الأحمال وتتطلب التوسعة الأفقية حلولاً بديلة.

ما الذي تغير

أوقف إصدار المواصفات 2025-03-26، الصادر في مارس 2025، HTTP+SSE وقدم نقل streamable HTTP. أضاف TypeScript SDK الدعم في الإصدار 1.10.0 في 17 أبريل 2025.

يدعم النقل الجديد العمليات ذات الحالة وعديمة الحالة. خادم MCP بسيط يمكنه معالجة كل طلب بشكل مستقل — لا حاجة لاتصال مستمر، متوافق تماماً مع النشر serverless. الخوادم الأكثر تعقيداً التي تحتاج البث أو الرسائل المبادر بها من الخادم يمكنها اختيارياً ترقية الاتصال لاستخدام SSE ضمن إطار النقل الجديد.

يوفر الخادم نقطة نهاية HTTP واحدة (نقطة نهاية MCP) تدعم طرق POST وGET. إدارة الجلسات اختيارية — يمكن للخوادم تعيين معرّف جلسة عبر ترويسة Mcp-Session-Id، لكن الخوادم عديمة الحالة يمكنها تخطي الجلسات بالكامل. هذا يعني أن خوادم MCP يمكن الآن نشرها كـ:

• وظائف serverless — Lambda وCloud Functions وVercel
• خدمات ويب تقليدية — Express وFastAPI وSpring Boot
• خدمات مصغرة حاوية — Kubernetes وCloud Run وECS
• وظائف حافة — Cloudflare Workers وVercel Edge

اختفى قيد الاتصالات المستمرة. يمكن نشر خوادم MCP أينما يعمل HTTP — وهو في كل مكان.

التوافق مع الإصدارات السابقة

الخوادم التي ترغب في دعم العملاء القدامى يمكنها استضافة نقاط نهاية SSE المتوقفة ونقطة نهاية streamable HTTP الجديدة في وقت واحد. هذا يسمح بالترحيل التدريجي دون كسر التكاملات القائمة.

الأثر العملي

للمطورين، هذا التغيير قابل للتنفيذ فوراً. خوادم MCP الجديدة يجب أن تستهدف streamable HTTP من اليوم الأول. حتى للنشر المحلي الأولي، تصميم HTTP عديم الحالة يمكّن الترحيل المستقبلي إلى بيئات serverless أو حافة دون إعادة هيكلة.

للمستهلكين الذين يقيّمون خوادم MCP، دعم النقل أصبح الآن مسألة توافق. الخوادم التي لا تزال تستخدم نقل SSE فقط ستخلق قيود نشر في البيئات السحابية الأصلية.

التحول 3: OAuth 2.1 يسد فجوة المصادقة

لم يكن لمواصفات MCP الأولية (2024-11-05) آلية مصادقة موحدة. نفّذ المطورون مخططاتهم الخاصة، عادةً بتمرير رموز API في متغيرات البيئة. كان هذا مقبولاً للخوادم المحلية حيث يتحكم المطور في البيئة، لكنه غير مقبول للنشر السحابي متعدد المستأجرين.

مشكلة بيانات الاعتماد المشتركة

لنأخذ شركة تنشر خادم MCP للوصول إلى GitHub. مع النموذج القديم، يحتاج الخادم رمز GitHub — إما رمز وصول شخصي محدد لمستخدم واحد أو رمز حساب خدمة بصلاحيات أوسع. لا أي من الخيارين آمن لخدمة متعددة المستخدمين.

الرمز الشخصي يعني أن جميع الطلبات تمر عبر صلاحيات مستخدم واحد، بدون مسار تدقيق يميز من فعل ماذا. رمز حساب الخدمة عادةً لديه وصول أكبر مما ينبغي لأي مستخدم فردي، منتهكاً مبدأ الحد الأدنى من الصلاحيات.

كيف يحل OAuth 2.1 المشكلة

قدم إصدار المواصفات 2025-03-26 إطار تفويض شامل مبني على OAuth 2.1. تتطابق البنية بشكل نظيف مع أدوار OAuth المعتمدة: خوادم MCP تعمل كخوادم موارد OAuth 2.1، وعملاء MCP يعملون كعملاء OAuth 2.1، وخادم تفويض منفصل يتولى إصدار الرموز.

يعمل التدفق كالتالي:

1. وكيل المستخدم يتصل بخادم MCP مستضاف سحابياً
2. الخادم يرد بـHTTP 401 Unauthorized، مما يطلق تدفق OAuth
3. العميل يعيد توجيه المستخدم إلى شاشة الموافقة لخادم التفويض
4. المستخدم يفوّض الوصول بنطاقات محددة
5. خادم MCP يتلقى رمز وصول محدد لذلك المستخدم بعينه
6. استدعاءات الأدوات اللاحقة تستخدم رمز المستخدم، وليس بيانات اعتماد مشتركة

تفرض المواصفات عدة تدابير أمنية. يجب على العملاء تطبيق Resource Indicators (RFC 8707) لمنع الخوادم الخبيثة من الحصول على رموز وصول مخصصة لخدمات أخرى. يجب على الخوادم تطبيق OAuth 2.0 Protected Resource Metadata (RFC 9728) للإشارة إلى مواقع خوادم التفويض الخاصة بها. يجب التحقق من صحة الرموز للجمهور المقصود.

كل مستخدم يتحكم في وصوله الخاص. يمكن تحديد نطاق الرموز للحد الأدنى من الصلاحيات اللازمة. هناك مسار تدقيق واضح لكل مستخدم. لا توجد بيانات اعتماد مشتركة في متغيرات البيئة.

لماذا يطلق هذا العنان للتبني المؤسسي

الاعتراض الأكثر شيوعاً من المؤسسات على MCP كان الأمان. يزيل OAuth 2.1 هذا الاعتراض. كل مستخدم يصادق بشكل مستقل عبر تدفقات تثق بها المؤسسة بالفعل. يمكن لفرق تكنولوجيا المعلومات فرض سياسات وصول لكل مستخدم. يمكن لفرق الامتثال تدقيق إجراءات كل مستخدم.

حسّن إصدار نوفمبر 2025 (2025-11-25) نموذج التفويض أكثر، وتُدرج خارطة طريق 2026 أماناً أعمق ومصادقة متكاملة مع SSO ضمن أولويات جاهزية المؤسسات. هذا هو التحول الذي ينقل MCP من أداة مطور إلى بنية تحتية مؤسسية.

التحدي الناشئ: تضخم نافذة السياق

مع انتقال MCP إلى الإنتاج على نطاق واسع، ظهرت مشكلة جديدة لم يتوقعها المصممون الأصليون: تعريفات الأدوات تستهلك رموز نافذة السياق.

كل وصف أداة ومخطط معاملات وتنسيق استجابة يقتطع من الذاكرة العاملة للنموذج. بالنسبة للوكلاء المتصلين بعدة خوادم MCP، يتراكم العبء بسرعة. تشير تقارير الصناعة إلى أن الاتصال بستة خوادم MCP مع 84 أداة إجمالية يستهلك حوالي 15,500 رمز عند بدء الجلسة — قبل أن يقوم الوكيل بأي عمل فعلي. بعض الفرق تفيد بأن MCP يستهلك 40 إلى 50 بالمائة من نوافذ السياق المتاحة.

المشكلة كبيرة بما يكفي لأن المدير التقني لشركة Perplexity أعلن في مارس 2026 أن الشركة تبتعد عن MCP لصالح واجهات API وCLI التقليدية، مستشهداً بتضخم الرموز واحتكاك المصادقة كمشاكل جوهرية.

يستجيب المجتمع بعدة نهج. أظهر نمط تنفيذ الكود تخفيضات في الرموز تصل إلى 98 بالمائة من خلال السماح للوكلاء بكتابة وتنفيذ كود بدلاً من إجراء استدعاءات أدوات فردية. الكشف التدريجي يرسل بياناً أدنى عند الاتصال — فقط أسماء الأدوات وأوصاف من سطر واحد — مع تحميل المخططات الكاملة فقط عند الحاجة. مشروع mcp2cli يحول خوادم MCP إلى واجهات CLI يستدعيها الوكلاء عند الطلب، متجنباً حقن المخططات المسبق بالكامل.

نشرت Anthropic نفسها إرشادات هندسية حول نمط تنفيذ الكود، معترفةً بالمشكلة وموفرةً تطبيقاً مرجعياً. تُدرج خارطة طريق 2026 تحسينات في قابلية توسعة النقل وإدارة الجلسات التي يجب أن تساعد في معالجة عبء السياق على مستوى البروتوكول.

هذا يستحق المتابعة. قد تصبح كفاءة السياق بنفس أهمية النقل والمصادقة في تحديد جدوى MCP في الإنتاج.

نمط النضج

يتبع تطور MCP نمطاً مألوفاً من تاريخ البروتوكولات. بدأ HTTP بسيطاً، ثم نما للتعامل مع الاتصالات المستمرة والبث وتعدد الإرسال. كانت واجهات REST APIs حرة الشكل في البداية، ثم توحدت حول مواصفات OpenAPI. أُطلق GraphQL مع جميع الميزات مكشوفة، ثم تقارب المجتمع نحو مجموعة فرعية عملية.

يمر MCP بنفس النضج. المواصفات الأولية رمت شبكة واسعة — أدوات وresources وprompts ونقل SSE وبدون مصادقة معيارية. بعد أربعة إصدارات من المواصفات، ضيّق المجتمع المساحة الفعالة: الأدوات عبر streamable HTTP مع OAuth 2.1، تحت حوكمة Linux Foundation من خلال Agentic AI Foundation.

الإصدار القادم من المواصفات مقرر مبدئياً لشهر يونيو 2026، مع التركيز على قابلية توسعة النقل للنشر الموزّع، ودلالات التواصل بين الوكلاء، وميزات المؤسسات مثل مسارات التدقيق وقابلية نقل التكوين.

ما يجب فعله الآن

إذا كنت تبني خوادم MCP

• ابنِ أدوات، وليس موارد. وجّه كل الوظائف — الإجراءات واستعلامات البيانات — عبر بدائية Tools. هذا حيث تقارب المجتمع.
• صمم لـstreamable HTTP. ابنِ بدون حالة حيثما أمكن، حتى للنشر المحلي الأولي. هذا يبقي خيارات النشر المستقبلية مفتوحة.
• طبّق OAuth 2.1 لأي خادم يصل إلى بيانات خاصة بالمستخدم في سيناريوهات متعددة المستأجرين. تفرض المواصفات RFC 8707 Resource Indicators وRFC 9728 Protected Resource Metadata.
• قلّل أوصاف الأدوات. عبء نافذة السياق مصدر قلق حقيقي في الإنتاج. اجعل الأوصاف مختصرة ومخططات المعاملات محكمة.

إذا كنت تستهلك خوادم MCP

• قيّم كتالوجات الأدوات. الأدوات التي يكشفها الخادم هي قدراته الحقيقية. دعم Resources غير ذي صلة لمعظم حالات الاستخدام.
• تحقق من توافق النقل. الخوادم التي تستخدم نقل SSE فقط ستقيّد خيارات نشرك. فضّل streamable HTTP.
• اطلب OAuth لأي خادم يتعامل مع بيانات حساسة. مفاتيح API المشتركة في متغيرات البيئة تمثل مسؤولية أمنية.
• راقب عبء الرموز. اتصالات MCP المتعددة تُراكم استهلاك السياق. خصص ميزانية لعبء المخططات في تخطيط نافذة السياق.

إذا كنت تقيّم MCP لمؤسستك

• البروتوكول جاهز للإنتاج ومدعوم من جميع مزودي الذكاء الاصطناعي الرئيسيين تحت حوكمة Linux Foundation.
• ابدأ بالاستهلاك، وليس البناء. استخدم خوادم MCP الموجودة للتكاملات الشائعة (أكثر من 10,000 متاح) قبل الاستثمار في تطوير خوادم مخصصة.
• خطط للتعدد. حتى لو كان نشرك الأول لمستخدم واحد، بنية جاهزة لـOAuth تتجنب التحديث المؤلم لاحقاً.

الخلاصة

MCP في بداية 2026 بروتوكول أكثر تركيزاً وقابلية للنشر وأماناً مما أُطلق في نوفمبر 2024. أربعة إصدارات من المواصفات صقلت البروتوكول بناءً على خبرة الإنتاج. تقارب المجتمع نحو الأدوات كبدائية أساسية، وstreamable HTTP كنقل، وOAuth 2.1 كمعيار مصادقة. تبقى بدائية Resources في المواصفات لكنها خاملة فعلياً. وتحدٍ جديد — تضخم نافذة السياق — يقود الموجة التالية من ابتكار البروتوكول.

للمطورين، المسار واضح: ابنوا أدوات، انشروا في أي مكان، صادقوا بشكل صحيح، واحتفظوا بمخططات أدواتكم خفيفة. وجد البروتوكول شكله الجاهز للإنتاج، والمنظومة تنضج بسرعة.

المصادر والقراءات الإضافية

• Model Context Protocol — Official Specification
• MCP Streamable HTTP Transport Specification (2025-03-26)
• MCP Authorization Specification — OAuth 2.1
• Why MCP Deprecated SSE and Went with Streamable HTTP — fka.dev
• The 2026 MCP Roadmap — Model Context Protocol Blog
• Anthropic Donates MCP to the Agentic AI Foundation
• MCP Authentication and Authorization — Stack Overflow Blog
• Code Execution with MCP: Building More Efficient AI Agents — Anthropic Engineering