MCP 2026-07-28 تحليل: البروتوكول يتحول إلى عديم الحالة لسهولة التوسع

مقدمة

يشهد بروتوكول سياق النموذج (Model Context Protocol) أكبر مراجعة معمارية منذ إطلاقه.

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

تركز مراجعة 2026-07-28 على المشكلات التي ظهرت عندما غادر MCP أجهزة الكمبيوتر المحمولة للمطورين ودخل بيئات الإنتاج الكبيرة.

يمكن تلخيص التغيير الرئيسي على النحو التالي:

يتحول MCP إلى عديم الحالة على مستوى البروتوكول.

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

لكن النقل عديم الحالة ليس سوى جزء من هذا التحديث.

كما يرسي هذا التعديل رسمياً إطار عمل للإضافات، ويعيد تشكيل المهام الطويلة الأمد، ويقدم طلبات متعددة الجولات ذهاباً وإياباً، ويضيف رؤوس HTTP قابلة للتوجيه وإشارات التخزين المؤقت، ويعزز آليات التفويض، ويوسع دعم مخطط JSON، ويضع سياسة رسمية لإهمال الميزات.

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

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

نمو MCP بالتني السريع

يبرز التقرير المصدر سرعة نمو استخدام MCP.

وفقاً لإعلان مطوري Claude المشار إليه في المقالة المصدرية:

• تجاوزت التنزيلات الشهرية لـ MCP SDK 400 مليون مرة.
• نما الاستخدام الشهري لـ SDK حوالي أربعة أضعاف خلال العام.
• تجاوزت التنزيلات التراكمية لكل من SDK الخاصة بـ TypeScript و Python معالم كبيرة جداً.
• تتوفر مئات من تكاملات MCP عبر نظام الموصلات البيئي الخاص بـ Claude.

هذه الأرقام المحددة لنهاية يوليو هي مؤشرات من إعلان الإصدار، وليست أرقاماً منشورة في المواصفات الأساسية.

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

هذا يعني أن النظام البيئي كان كبيراً بالفعل قبل إعادة تصميم البروتوكول في يوليو.

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

تشمل هذه المشكلات:

• الجلسات اللاصقة.
• تخزين الجلسات المشترك.
• التوسع الأفقي.
• النشر بدون خوادم.
• توجيه البوابات.
• تعقيد المصادقة.
• عمليات الذكاء الاصطناعي الطويلة الأمد.
• الواجهات التفاعلية.
• التوافق مع الإصدارات السابقة.
• تطور البروتوكول.

لماذا أصبح التصميم السابق القائم على الحالة مشكلة في التوسع

كانت عمليات نشر MCP البعيدة المبكرة تحافظ على حالة الجلسة على مستوى البروتوكول.

عادةً ما يقوم العميل بتهيئة

إنشاء اتصال والحصول على معرف جلسة. ثم تتطلب الطلبات اللاحقة الحفاظ على الارتباط بتلك الجلسة.

يظهر تدفق مبسط لـ 2025-11-25 على النحو التالي:

POST /mcp HTTP/1.1
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {},
    "clientInfo": {
      "name": "my-app",
      "version": "1.0"
    }
  }
}

بعد التهيئة، يمكن أن تحمل الاستدعاءات اللاحقة:

Mcp-Session-Id: 1868a90c-3a3f-4f5b

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

قد تتطلب عمليات نشر الإنتاج:

• توجيه موازن التحميل اللاصق.
• تخزين الجلسات المشترك.
• تكرار الجلسات.
• منطق انتهاء صلاحية الجلسات.
• معالجة تجاوز الفشل.
• مراقبة تدرك الاتصال.
• معالجة خاصة لإعادة تشغيل الخوادم.

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

يزيل التعديل الجديد هذا الافتراض.

MCP الآن عديم الحالة على مستوى البروتوكول

في تصميم بروتوكول 2026-07-28، يحمل كل طلب المعلومات التي يحتاجها الخادم لتحليل الطلب.

المثال الرسمي هو:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "q": "otters"
    },
    "_meta": {
      "io.modelcontextprotocol/clientInfo": {
        "name": "my-app",
        "version": "1.0"
      }
    }
  }
}

لا مزيد من Mcp-Session-Id على مستوى البروتوكول.

لا مزيد من جلسة الاتصال الإلزامية التي تربط الطلبات بمثيل خادم واحد.

يمكن لأي مثيل خادم متوافق معالجة الطلب.

هذا تحسين كبير للنشر السحابي.

يمكن لخوادم MCP البعيدة الآن التكيف مع البنى التقليدية:

عميل
  ↓
بوابة API / موازن تحميل
  ↓
مثيل خادم MCP أ
مثيل خادم MCP ب
مثيل خادم MCP ج

لم يعد يتعين على الطلبات العودة إلى مثيل معين لمجرد أن طلباً سابقاً وقع على ذلك المثيل.

إزالة مصافحة initialize من التنسيق الجديد عبر الشبكة

يزيل إعادة التصميم عديم الحالة أيضاً دورة حياة initialize / initialized القديمة من تنسيق 2026-07-28 عبر الشبكة.

المعلومات التي كانت تُنقل مرة واحدة فقط أثناء التهيئة، تنتقل الآن مع كل طلب عبر البيانات الوصفية.

عندما يرغب العميل في اكتشاف قدرات الخادم مسبقاً، يمكنه استخدام الطريقة الجديدة server/discover.

هذا لا يعني أن العملاء القدامى سيتوقفون عن العمل فوراً.

تتضمن وثائق SDK الحالية شرحاً لسلوك التوافق مع إصدارات البروتوكول السابقة. على سبيل المثال، يمكن لـ C# SDK دعم المسار الجديد عديم الحالة

مع الاستمرار في التفاوض على السلوك القديم القائم على الجلسات مع العملاء الذين يستخدمون بروتوكول 2025-11-25.

الفرق الرئيسي في الترحيل هو:

2026-07-28:
نموذج الطلبات عديمة الحالة، بدون جلسة بروتوكول.

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

يجب على المطوّرين اختبار طرفي التكامل، بدلاً من ترقية الخادم فقط وافتراض أن جميع العملاء يفهمون الإصدار الجديد.

## البروتوكول عديم الحالة لا يعني تطبيقاً بلا حالة

من أسهل الأخطاء التي يمكن ارتكابها فهم هذا التغيير على النحو التالي:

> لم يعد تطبيق MCP مسموحاً له بالاحتفاظ بالحالة.

هذا ليس ما يعنيه المواصف.

**طبقة البروتوكول** هي عديمة الحالة.

يمكن للتطبيق الاستمرار في الحفاظ على الحالة حيثما تكون مفيدة.

لنفترض أن أداة تسوق أنشأت سلة تسوق.

يمكن للخادم إرجاع:

```JSON
{
  "basket_id": "basket_8472"
}

يمكن للنموذج تمرير هذه القيمة في الاستدعاءات اللاحقة:

{
  "basket_id": "basket_8472",
  "item_id": "item_123"
}

هذا يجعل حالة التطبيق مرئية كبيانات أدوات عادية، بدلاً من إخفائها في بيانات تعريف النقل.

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

لماذا قد تكون المؤشرات الصريحة أفضل

للمؤشرات المرئية عدة مزايا.

يمكن للنموذج:

• تمريرها بين الأدوات ذات الصلة.
• الاستدلال على أي مؤشر يخص أي مهمة.
• تضمينها في السجلات.
• استعادتها بعد إعادة المحاولة.
• تسليمها إلى خطوة أخرى في سير العمل.

يمكن للخادم:

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

وبالتالي، ينقل MCP عديم الحالة إدارة الحالة من طبقة النقل إلى تصميم تطبيق صريح.

الحوسبة بدون خادم والتوسع الأفقي أصبحت أسهل بكثير

أبرز المقال المصدر الحوسبة بدون خادم، وهي واحدة من أكثر النتائج العملية للبروتوكول الجديد.

عندما تكون الطلبات مكتفية ذاتياً، يمكن لخادم MCP العمل بسهولة أكبر في بيئات مثل:

• AWS Lambda.
• Cloudflare Workers.
• Vercel.
• دوال بدون خادم أخرى.
• منصات التوسع التلقائي للحاويات.
• نشر Kubernetes عادي بلا حالة.
• البيئات الطرفية.

هذا لا يعني أن كل عبء عمل MCP سيعمل تلقائياً على كل منصة بدون خادم.

لا يزال على المطوّرين مراعاة مدة التنفيذ، ودعم البث، ووقت البدء البارد، وحالة التطبيق الدائمة، والمفاتيح، والشبكة الصادرة، والمهام طويلة التشغيل، ومتطلبات نظام الملفات، واتصالات قواعد البيانات.

لم يعد البروتوكول يفرض بنية الجلسة، مما يزيل عقبة رئيسية.

موازنة التحميل الدائرية أصبحت الخيار الافتراضي الطبيعي

لم يعد الخادم الموسّع أفقياً بحاجة إلى ربط عميل واحد بمثيل واحد على مستوى البروتوكول.

هذا يعني أن موازنات التحميل الدائرية البسيطة يمكنها توزيع الطلبات بين مثيلات متعددة.

هذا يحسّن:

• التوسع التلقائي.
• استبدال المثيلات.
• استعادة الأعطال.
• النشر المتدرج.
• التوجيه متعدد المناطق.
• بساطة البنية التحتية.

كما يغيّر طريقة تفكير مؤلفي الخوادم في الحالة المخفية في الذاكرة.

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

اختبار ترحيل جيد هو:

إذا وقع كل استدعاء أداة على عملية خادم مختلفة، فهل يستمر نفس سير العمل؟

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

طلبات متعددة الجولات تحل محل الاتصالات المستمرة أثناء الاستدعاء

لا يزال التصميم عديم الحالة بحاجة إلى طريقة للخادم لطلب مزيد من المعلومات من العميل.

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

الآلية الجديدة هي الطلبات متعددة الجولات (Multi Round-Trip Requests، واختصاراً MRTR).

يمكن للأداة إرجاع نتيجة غير مكتملة:

{
  "resultType": "input_required",
  "inputRequests": {
    "confirm": {
      "type": "elicitation",
      "message": "حذف 3 ملفات؟",
      "schema": {
        "type": "boolean"
      }
    }
  },
  "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}

يجمع العميل الإجابات المطلوبة.

ثم يكرر الاستدعاء الأصلي باستخدام inputResponses و requestState المُعاد.

بما أن الحالة تُحمل في تدفق الطلب، يمكن لمثيل خادم آخر معالجة الجولة التالية.

هذا أكثر توافقاً مع البنية عديمة الحالة من اشتراط اتصال طويل الأمد بين الخادم والعميل.

التوجيه القائم على الرؤوس يجعل MCP أكثر ملاءمة للبوابات

يضيف تنسيق Streamable HTTP الجديد بيانات تعريف العملية مباشرة إلى رؤوس HTTP.

تشمل الرؤوس المهمة:

Mcp-Method: tools/call
Mcp-Name: search

هذا مهم للبنية التحتية للإنتاج.

يمكن لبوابات API، وجدران حماية تطبيقات الويب، وموزّعات المعدل، أو طبقات المراقبة تحديد العملية دون تحليل جسم JSON.

تشمل الاستخدامات المحتملة:

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

تتطلب مواصفات البروتوكول أيضاً الاتساق بين الرؤوس وجسم JSON-RPC.

يجب على الخادم رفض الطلبات التي لا يتطابق فيها الاثنان.

نتائج القوائم والقراءة تدعم الوعي بالتخزين المؤقت

غالباً ما يطلب عملاء MCP بيانات وصفية مستقرة نسبياً، مثل قوائم الأدوات والموارد وقوائم المطالبات وقراءة الموارد.

الحصول على نفس المعلومات مراراً وتكراراً يهدر حركة الشبكة وسعة الخادم.

يقدم التنقيح الجديد بيانات تعريف للتخزين المؤقت، مثل:

ttlMs
cacheScope

تتيح هذه القيم للخادم الإشارة إلى المدة التي يجب أن تبقى فيها النتيجة حديثة، وما إذا كان يمكن مشاركة النتيجة عبر المستخدمين أو السياقات.

هذا مشابه لمبدأ التخزين المؤقت في HTTP العادي.

بالنسبة للوكلاء المكثفين في استخدام الأدوات، يمكن أن يقلل هذا من التحميل المتكرر للبيانات الوصفية.

التتبع الموزع أصبح معيارياً

يوثق التنقيح أيضاً نشر W3C Trace Context.

مفاتيح مثل:

• traceparent
• tracestate
• baggage

يمكن نشرها عبر بيانات تعريف MCP.

هذا يتيح لتتبع موزع واحد تتبع العمل عبر السلسلة:

التطبيق المضيف
→ عميل MCP
→ بوابة MCP
→ خادم MCP
→ واجهات برمجية خارجية
→ قاعدة البيانات

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

الامتدادات أصبحت ميزة بروتوكول من الدرجة الأولى

يغيّر البروتوكول أيضاً طريقة تطور الميزات الاختيارية.

الإطار الحالي يمنح الامتدادات:

• معرّفات DNS عكسية.
• تفاوض على القدرات.
• تحكم مستقل في الإصدارات.
• مستودعات أكواد مخصصة.
• مفوّضين مكلفين بالصيانة.
• مسار امتداد رسمي في عملية SEP.

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

يمكن للميزة أن تنضج أولاً كامتداد، ومن ثم يمكن للقدرات المثبتة الاقتراب من النواة.

تطبيقات MCP: واجهات مستخدم تفاعلية في المحادثة

من أبرز امتدادات MCP هو تطبيقات MCP (MCP Apps).

أدوات MCP تُرجع تقليدياً نصاً أو JSON منظم أو موارد.

بعض المهام تحتاج إلى واجهات.

تشمل الأمثلة لوحات المعلومات والرسوم البيانية والخرائط والنماذج ولوحات المهام ولوحات الإعدادات ولوحات التصميم ومشغلات الفيديو.

تتيح تطبيقات MCP للخادم إعلان مورد واجهة مستخدم، يتم عرضه في iframe معزول.

يتفاعل المستخدم مع التطبيق، ويقوم التطبيق بطلب استدعاء أداة، ويعيد الخادم بيانات جديدة، ويقوم التطبيق بالتحديث إلى البيانات الجديدة. هذا الرسم البياني وثيق الصلة بالسياق، ويعرض بشكل مباشر عملية التفاعل الكاملة لتطبيقات MCP من تعليمات المستخدم إلى تحديث التطبيق.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/c7e4e5a5-3b69-4999-be13-41aa3f213186-be0c3bc3-5210-4e7e-971e-c9b0e2d35daf.png)

التدفق المبسّط كما يلي:

1. تعلن الأداة عن مورد واجهة مستخدم.
2. يستدعي النموذج تلك الأداة.
3. يقوم المضيف بتحميل واجهة المستخدم في بيئة معزولة (sandbox).
4. يتم تمرير بيانات الأداة إلى الواجهة.
5. يتفاعل المستخدم مع التطبيق.
6. يمكن للتطبيق طلب استدعاءات أدوات إضافية عبر المضيف.
7. يحتفظ المضيف بتحكم في الأذونات والتدقيق لهذه العمليات.

تطبيقات MCP مدعومة من قبل عدة مضيفات متوافقة، بما في ذلك Claude ومنتجات التطوير الأخرى الداعمة لـ MCP.

التثبيت الأساسي لتطبيقات MCP

يمكن تثبيت حزمة التوسعة الرسمية باستخدام الأمر التالي:

npm install -S @modelcontextprotocol/ext-apps

يمكن تشغيل مستودع الأمثلة الرسمي محليًا:

git clone https://github.com/modelcontextprotocol/ext-apps.git
cd ext-apps
npm install
npm start

هذه الأوامر مأخوذة من وثائق MCP Apps الرسمية، وقد تتغير مع تطور التوسعة.

المهام: أعمال طويلة الأمد لا تحجب الاتصال

تقوم أدوات الوكلاء بشكل متزايد بتشغيل أعمال لا يمكن إكمالها خلال طلب HTTP عادي واحد.

تشمل الأمثلة خطوط أنابيب CI، ومهام معالجة البيانات الكبيرة، والنشر السحابي، ومهام البحث طويلة الأمد، وعرض الفيديو، وعمليات الموافقة البشرية.

تتيح توسعة مهام MCP للخادم إرجاع مؤشر مهمة دائم بدلاً من حظر انتظار اكتمال العملية.

تشمل الطرق المعرّفة في التوسعة الرسمية ما يلي:

tasks/get
tasks/update
tasks/cancel

يمكن أن تنتقل المهام بين الحالات التالية:

working
input_required
completed
cancelled
failed

يمكن للعميل الاستعلام بشكل دوري عن tasks/get.

إذا احتاج الخادم إلى إدخال من المستخدم، يمكن أن تنتقل المهمة إلى حالة input_required.

يمكن للعميل إرسال الإدخال عبر tasks/update.

يعمل هذا التصميم بشكل طبيعي حتى في حالة قطع الاتصال، ولا يتطلب اتصالًا طويل الأمد.

ملاحظة توافق مهمة

كانت وظيفة المهام موجودة كميزة تجريبية في المواصفات الأساسية بتاريخ 2025-11-25.

توسعة المهام الجديدة ليست مجرد نسخة معاد تسميتها من واجهة البرمجة القديمة.

تحذر وثائق SDK الرسمية من أن توسعة المهام الأحدث غير متوافقة مع التطبيقات التجريبية المبكرة على مستوى البروتوكول.

يجب على التطبيقات التي تستخدم وظيفة المهام القديمة أن تقوم بالترحيل، ولا يمكنها الاعتماد على التوافق التلقائي.

التفويض المُدار للمؤسسات

تواجه عمليات النشر المؤسسية مشاكل تفويض مختلفة عن تكاملات المستهلك.

قد يكون لدى الشركة آلاف الموظفين وعشرات خوادم MCP المعتمدة.

ولا ترغب في أن يقوم كل موظف بتفويض كل موصل بشكل مستقل.

تسمح توسعة التفويض المُدار للمؤسسات للمنظمات بإدارة التحكم في الوصول مركزيًا عبر مزود الهوية.

قد تتضمن أنماط IdP المدعومة للمؤسسات منتجات مثل Microsoft Entra ID وOkta وأنظمة SSO للمؤسسات.

يمكن للمنظمة تحديد الموظفين الذين يمكنهم الوصول إلى أي خوادم MCP، ومتى يجب إلغاء هذا الوصول.

يستخدم الموظفون هوية مؤسستهم للمصادقة، دون الحاجة إلى إكمال موافقات OAuth منفصلة لكل خادم MCP.

تصف وثائق MCP الرسمية التفويض المُدار للمؤسسات كتوسعة، وليست ميزة مفعلة افتراضيًا لكل عميل.

يجب أن يدعم كل من العميل والبنية التحتية لهوية المنظمة هذه التوسعة.

آليات التفويض تحظى بتعزيز أمني أوسع

حصلت أعمال التفويض الأساسية أيضًا على عدة تحسينات أمنية.

التحقق من المُصدر وفقًا لـ RFC 9207

يمكن أن تتضمن استجابات التفويض معامل iss الخاص بالمُصدر.

يتحقق العميل من المُصدر قبل استبدال رمز التفويض.

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

بيانات اعتماد العميل المرتبطة بالمُصدر الخاص بها

لا ينبغي إعادة استخدام بيانات اعتماد العميل المسجلة بين خوادم تفويض غير مرتبطة.

عندما يتم نقل الموارد إلى مُصدرين آخرين، يجب على العميل التسجيل بشكل مناسب لدى ذلك المُصدر.

تحسين تسجيل سطح المكتب وواجهة الأوامر

توضح هذه النسخة سلوك application_type أثناء التسجيل الديناميكي للعميل.

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

CIMD هو إرشاد جديد لتسجيل العملاء

يتجه مشروع تفويض MCP نحو وثائق بيانات تعريف معرّف العميل (Client ID Metadata Documents، اختصارًا CIMD) للتنفيذات الجديدة، مع الحفاظ على توافق DCR حيثما كان ذلك مطلوبًا.

التوصية العملية هي اتباع وثائق التفويض الحالية، بدلاً من تنفيذ تسجيل العملاء بناءً على دروس MCP الأقدم.

مخطط JSON Schema الكامل 2020-12 للأدوات

أصبحت مخططات الأدوات أكثر تعبيرًا أيضًا.

يدعم inputSchema وoutputSchema ميزات JSON Schema الكاملة لإصدار 2020-12.

يمكن أن تستخدم مخططات الإدخال ما يلي:

oneOf
anyOf
allOf
$ref
$defs
العبارات الشرطية

لم تعد مخططات الإخراج محصورة في شكل كائن ضيق واحد.

يمكن أن يمثل structuredContent أي قيمة JSON يدعمها المخطط.

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

Roots وSampling وLogging أصبحت مهملة

تم إهمال ثلاث قدرات أساسية أقدم رسميًا:

الوظيفة	الاتجاه الموصى به
Roots	معلمات الأدوات، أو URIs الموارد، أو إعدادات الخادم
Sampling	التكامل المباشر مع مزودي LLM
Logging	استخدام stderr مع stdio؛ واستخدام OpenTelemetry للرصد المنظم

الإهمال لا يعني الإزالة الفورية.

تنص سياسة دورة الحياة الجديدة على أن الميزات المهملة يجب أن تحصل على فترة انتقالية لا تقل عن اثني عشر شهرًا قبل السماح بإزالتها.

قد تستمر حزم SDK الحالية في دعم هذه القدرات للحفاظ على التوافق.

سياسة الإهمال الرسمية تغيّر مخاطر ترقية MCP

يتضمن إعادة التصميم عديم الحالة تغييرات مكسورة.

أشار المشرفون إلى أنهم لا يريدون أن يصبح هذا المستوى من الانقطاع هو القاعدة.

تحدد دورة حياة الميزات الجديدة المراحل التالية:

نشط
مُهمَل
مُزال

تحصل الميزات المُهمَلة على حد أدنى لفترة الدعم قبل الإزالة.

يمكن أيضًا أن تتطور الإضافات بشكل مستقل عن النواة.

يوفر هذا للفرق تخطيط ترحيل أكثر قابلية للتنبؤ.

أنفاق MCP تحل مشكلات مؤسسية مختلفة

تجعل مراجعة البروتوكول خوادم MCP البعيدة العامة أكثر قابلية للتوسع.

غالبًا ما تواجه المؤسسات المشكلة المعاكسة: فهي لا تريد جعل الخوادم عامة على الإطلاق.

ميزة MCP Tunnels من Anthropic تعالج هذه الحالة لعملاء Claude المُدارين وسير عمل منصة Claude المدعومة.

تعمل بوابة خفيفة الوزن داخل شبكة المؤسسة وتنشئ اتصالات صادرة.

تصف Anthropic هذا النمط على النحو التالي:

• لا توجد نقاط نهاية MCP عامة.
• لا توجد قواعد جدار حماية للاتصالات الواردة.
• لا حاجة لعناوين IP عامة.
• حركة مرور مشفرة من طرف إلى طرف.

يمكن أن تبقى قواعد البيانات الداخلية، وأنظمة ERP، وواجهات برمجية خاصة، وقواعد المعرفة، وأنظمة التذاكر داخل حدود شبكة المؤسسة.

تظل أنفاق MCP ميزة منتج من Claude، وليست متطلبًا أساسيًا في بروتوكول MCP.

تصفها Anthropic حاليًا بأنها معاينة بحثية.

تطبيقات MCP والأنفاق لا ينبغي الخلط بينهما

كلتا الميزتين تحسنان MCP في بيئات الإنتاج، لكنهما تحلان مشكلات مختلفة.

الميزة	المشكلة التي تحلها
تطبيقات MCP	واجهات تفاعلية غنية داخل مضيف MCP
المهام	عمليات أدوات طويلة الأمد ومستمرة
تفويض الاستضافة المؤسسية	سياسة وصول مركزية على مستوى الشركة
أنفاق MCP	الوصول إلى خوادم MCP الخاصة دون تعريضها للعامة
نواة MCP عديمة الحالة	نقل بروتوكول قابل للتوسع
MRTR	إدخال العميل أثناء المكالمة دون جلسات بروتوكول طويلة الأمد

يمكن للخوادم استخدام واحدة أو أكثر أو كل هذه الميزات معًا.

ما الذي يحتاج مطورو خوادم MCP الحاليون إلى تغييره؟

إذا كان الخادم يعمل بالفعل مع عملاء MCP الأقدم، فلن يضطر المطورون إلى إعادة كتابة كل شيء فورًا.

يجب عليهم تنفيذ ترحيل منظم.

الخطوة 1: جرد التبعيات الخفية للجلسات

ابحث عن الكود الذي يعتمد على:

• Mcp-Session-Id
• قواميس في الذاكرة لكل جلسة
• التوجيه اللاصق
• حالة العميل المحلية بالاتصال
• تخزين القدرات عند التهيئة فقط
• تقارب مثيل الخادم

حدد ما إذا كان كل تبعية حالة بروتوكول، أو حالة تطبيق، أو حالة مصادقة، أو حالة تنفيذ مؤقتة.

انقل حالة التطبيق إلى مقابض صريحة أو تخزين دائم مناسب.

الخطوة 2: اختبار معالجة الطلبات عديمة الحالة

استخدم إصدارات SDK التي تدعم مراجعة 2026-07-28.

ثم اختبر باستخدام مثيلات خادم متعددة.

إحدى تكوينات الاختبار المفيدة هي:

عميل
  ↓
موازن تحميل دائري
  ↓
خادم A / خادم B / خادم C

أرسل سير عمل متعدد الخطوات وتأكد من أن الطلبات المتتالية يمكن أن تصل إلى مثيلات مختلفة دون مقاطعة المهمة.

الخطوة 3: إضافة مقابض حالة صريحة

لسير العمل الذي يتطلب حالة، قم بإرجاع معرّف ثابت:

{
  "job_id": "job_7f18c9"
}

اطلب من الاستدعاءات اللاحقة تضمين هذا المعرّف:

{
  "job_id": "job_7f18c9",
  "action": "continue"
}

تحقق من صحة كل مقبض على جانب الخادم.

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

الخطوة 4: تحديث قواعد البوابة

إذا كنت تستخدم Streamable HTTP، فاستفد من الترويسات التالية:

Mcp-Method
Mcp-Name

أضف التوجيه، وتحديد المعدل، والمقاييس، وسياسات WAF، وسجلات الوصول.

الخطوة 5: إضافة دعم التخزين المؤقت

للاستجابات المناسبة للقوائم والقراءات، اتبع أو قم بتوليد:

ttlMs
cacheScope

لا تشارك محتوى التخزين المؤقت الحساس الخاص ببيانات مستخدم معين عبر مستخدمين مختلفين.

الخطوة 6: ترحيل المهام القديمة

إذا كان التطبيق يستخدم واجهة برمجة المهام التجريبية 2025-11-25، فقم بتحديثها إلى دورة الحياة الممتدة.

اختبر:

tasks/get
tasks/update
tasks/cancel

بالإضافة إلى حالة input_required.

الخطوة 7: مراجعة الميزات المهملة

ابحث عن Roots وSampling وMCP Logging.

خطط للانتقال إلى معلمات أدوات صريحة أو URIs موارد، واستدعاءات مباشرة لمزودي النماذج، واستخدام stderr أو OpenTelemetry.

الخطوة 8: إعادة اختبار التفويض

تحقق من التحقق من المُصدر، وURIs إعادة التوجيه، وتسجيل العملاء، ورموز التحديث، ومعالجة النطاقات، والتوافق مع مزودي الهوية.

يجب على النشر المؤسسي تقييم ما إذا كان EMA قابلاً للتطبيق.

الخطوة 9: اختبار العملاء القدامى

التوافق الخلفي هو مشكلة بيئية، وليست مشكلة خادم فقط.

حافظ على مصفوفة اختبار:

العميل	مراجعة البروتوكول	النتيجة
عميل حالي	2026-07-28	المسار عديم الحالة المتوقع
عميل قديم	2025-11-25	مسار التوافق
عميل غير مدعوم	إصدار قديم/غير معروف	فشل تفاوض واضح

لا تفترض ضمنيًا أن كل عميل تتم ترقيته في نفس الوقت.

الخطوة 10: إضافة الرصد قبل الإنتاج

يجب قياس ما يلي على الأقل:

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

الأنظمة عديمة الحالة أسهل في التوسع، لكن الأنظمة الموزعة لا تزال بحاجة إلى رصد جيد.

مثال: قبل الترحيل وبعده

قبل الترحيل

يخزن الخادم كائنات التقارير في الذاكرة:

sessions[session_id]["report"] = report

يتوقع استدعاء الأداة التالي أن يصل إلى نفس العملية.

بعد الترحيل

يخزن الخادم الحالة الثابتة:

report_id = save_report(report)
return {"report_id": report_id}

تتلقى الأداة التالية:

{
  "report_id": "report_123"
}

يمكن لأي مثيل خادم تحميل هذا التقرير.

التغيير المهم يحدث على المستوى المعماري:

حالة جلسة النقل الخفية
→ حالة تطبيق صريحة

هل يعني MCP عديم الحالة تكلفة أقل؟

من الممكن، لكنه ليس تلقائيًا.

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

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

يمكن أن يقلل التخزين المؤقت أيضًا من استدعاءات البيانات الوصفية المتكررة.

ومع ذلك، لا تزال حالة التطبيق لها تكلفة.

إذا كان سير العمل يتطلب حالة ثابتة، فقد يظل المطورون بحاجة إلى Redis، أو قواعد بيانات SQL، أو تخزين كائنات، أو قوائم مهام، أو محركات سير عمل.

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

هل أصبح MCP "بروتوكول HTTP في مجال الذكاء الاصطناعي"؟

المقال المصدر استخدم هذا التشبيه.

هذا التشبيه مفيد، لكن لا ينبغي تفسيره حرفياً.

HTTP هو معيار نقل أساسي للويب، ويُستخدم في جميع أنظمة الإنترنت تقريباً.

MCP هو بروتوكول متخصص يهدف إلى ربط عملاء الذكاء الاصطناعي والوكلاء بالأدوات والموارد والموجهات والواجهات والخدمات الخارجية.

ما يلتقطه هذا التشبيه هو اتجاه التطور:

• واجهة موحدة.
• خوادم مستقلة متعددة.
• عملاء متوافقون متعددون.
• اتفاقيات مشتركة.
• بنية تحتية قادرة على توجيه ومراقبة الطلبات بشكل عام.

إعادة التصميم بتاريخ 2026-07-28 عززت هذا التشبيه، لأن حركة مرور MCP أصبحت الآن أكثر انسجاماً مع البنية التحتية التقليدية عديمة الحالة لبروتوكول HTTP.

ما إذا كان MCP سيصل إلى مستوى انتشار مشابه لـ HTTP لا يزال سؤالاً مفتوحاً.

النظام البيئي أوسع من Claude

نشأ MCP من Anthropic، لكنه يُدار الآن كمشروع بروتوكول مفتوح المصدر أوسع نطاقاً.

يشمل هذا النظام البيئي مساهمين مستقلين، ومجموعات عمل، ومقترحات لتحسين المواصفات، وSDK بلغات متعددة، وتطبيقات MCP، والمهام، والإضافات الخاصة بالتفويض المؤسسي، وسجلات، وتنفيذات في منتجات متعددة للذكاء الاصطناعي.

على سبيل المثال، تم تطوير تطبيقات MCP بالتعاون مع مساهمي مجتمع MCP بالإضافة إلى مشاركين من Anthropic وOpenAI وMCP-UI.

هذا مهم لأن قيمة البروتوكول تزداد عندما يمكن للعملاء والخوادم تنفيذه دون الاعتماد على مورد واحد.

المشهد الحالي لـ SDK

يدير مشروع MCP الرسمي أو يعتمد تنفيذات SDK بلغات متعددة.

تشمل المستودعات الرئيسية SDK بلغات TypeScript وPython وGo وC# بالإضافة إلى أنظمة بيئية أخرى.

في يونيو 2026

أبرز إعلان المرشح للإصدار الدعم التجريبي لأربعة SDK من الدرجة الأولى:

• TypeScript.
• Python.
• Go.
• C#.

بحلول أواخر يوليو، أصبحت وثائق SDK الحالية تتضمن سلوك 2026-07-28.

نظراً لأن اعتماد SDK يتم بشكل مستقل، تحقق دائماً من ملاحظات الإصدار للغة والإصدار المحددين اللذين تستخدمهما.

استراتيجية ترحيل أكثر أماناً

بالنسبة للأنظمة الإنتاجية، تجنب الترحيل بنمط "يوم التبديل".

العملية الأكثر أماناً هي:

1. ترقية بيئة التطوير.
2. تشغيل اختبارات الاتساق.
3. اختبار عملاء 2026-07-28.
4. اختبار العملاء القدامى.
5. تفعيل النشر عديم الحالة في بيئة ما قبل الإصدار.
6. إضافة عدة نسخ من الخادم.
7. فرض توزيع الطلبات عبر النسخ.
8. اختبار المصادقة.
9. اختبار المهام طويلة التشغيل.
10. اختبار مقابض حالة التطبيق.
11. مراقبة زمن الاستجابة والأخطاء.
12. الطرح التدريجي.

هذا مهم بشكل خاص لأن المراجعة الجديدة عدّلت عمداً سلوك دورة الحياة الأساسي.

ما لا ينبغي افتراضه

لا تفترض أن كل خادم أصبح تلقائياً بلا خادم

البروتوكول يدعم بشكل أكثر طبيعية النشر بلا خادم.

قد لا يزال تطبيقك يحتاج إلى قاعدة بيانات، أو منفذ مهام دائم، أو تخزين ملفات، أو أوقات تنفيذ أطول.

لا تفترض أن كل الحالة ستختفي

فقط حالة الجلسة على مستوى البروتوكول تُزال من النموذج الجديد عبر الشبكة.

حالة التطبيق تظل مسؤولية التطبيق نفسه.

لا تفترض أن تطبيقات MCP ستعمل في كل عميل

الإضافات تُتفاوض عليها، ودعم المضيفين يختلف.

لا تفترض أن المهام متوافقة مع الإصدارات السابقة

إضافة المهام الحالية تختلف عن التنفيذات التجريبية السابقة.

لا تفترض أن الإهمال يعني التوقف الفوري

الجذور وأخذ العينات والتسجيل تظل متاحة خلال فترة الإهمال.

لا تفترض أن جميع العملاء يدعمون بالفعل 2026-07-28

تقدم اعتماد SDK والمنتجات يختلف.

لا تفترض أن "البروتوكول المفتوح" يعني "لا حاجة لأمن"

يمكن لـ MCP تنفيذ أدوات قوية.

التفويض، وموافقة المستخدم، والعزل، وتصميم الأدوات، وإدارة الأسرار، والتدقيق تظل ضرورية للغاية.

الأسئلة الشائعة

ما هو MCP 2026-07-28؟

MCP 2026-07-28 هو أكبر مراجعة معمارية لبروتوكول نموذج السياق منذ إطلاقه. تشمل تغييراته الرئيسية نواة بروتوكول عديمة الحالة، وإزالة مصافحة الجلسة في النموذج الجديد عبر الشبكة، وإضافات من الدرجة الأولى، وتطبيقات MCP، ومهام مُعاد تصميمها، وMRTR، وتفويضاً أقوى، وبيانات تعريف للتخزين المؤقت، وسياسة إهمال رسمية.

هل أصبح MCP عديم الحالة بالكامل الآن؟

طبقة بروتوكول 2026-07-28 مصممة لتكون عديمة الحالة. يمكن للتطبيقات أن تظل محتفظة بالحالة عبر مقابض صريحة، أو قواعد بيانات، أو أنظمة سير عمل، أو تخزين دائم آخر.

ماذا حدث لـ Mcp-Session-Id؟

نموذج 2026-07-28 عبر الشبكة أزال آلية Mcp-Session-Id على مستوى البروتوكول. قد تظل حزم SDK الحالية تدعم سلوك الجلسات للتوافق مع الإصدارات السابقة عند التفاوض على مراجعات البروتوكول القديمة.

هل يمكنني نشر خادم MCP على AWS Lambda أو Cloudflare Workers؟

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

ما هي تطبيقات MCP؟

تطبيقات MCP هي إضافة رسمية

تتيح للأدوات إرجاع واجهات تفاعلية داخل مضيفات MCP المتوافقة، مثل لوحات المعلومات والنماذج والرسوم البيانية وتجارب HTML أخرى. تعمل الواجهة داخل iframe معزول وتتواصل عبر مضيف MCP.

ما هي مهام MCP؟

ميزة المهام تتيح للخوادم إرجاع مقابض مهام غير متزامنة دائمة للعمل طويل الأمد. يمكن للعميل الاستعلام عن الحالة عبر tasks/get، وتقديم المدخلات المطلوبة عبر tasks/update، أو إلغاء العملية عبر tasks/cancel.

ما هو التفويض المؤسسي المُدار؟

التفويض المؤسسي المُدار هو إضافة لـ MCP تتيح التحكم المركزي في الوصول عبر موفر الهوية الخاص بالمؤسسة. يسمح لمسؤولي تكنولوجيا المعلومات بإدارة الوصول إلى خوادم MCP بناءً على سياسات هوية المؤسسة، دون أن يضطر كل مستخدم إلى تفويض كل خادم على حدة.

هل يجب عليّ الترحيل فوراً من MCP القديم؟

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

أدوات ذات صلة

• Model Context Protocol: الوثائق الرسمية لمواصفات MCP والهندسة المعمارية وSDK والإضافات ودليل المطورين.
• MCP TypeScript SDK: التنفيذ الرسمي لعملاء وخوادم MCP بلغة TypeScript.
• MCP Python SDK: حزمة SDK الرسمية والأمثلة لتطوير MCP بلغة Python.
• MCP Go SDK: التنفيذ الرسمي بلغة Go، ويدعم حالياً مسار البروتوكول عديم الحالة.
• MCP C# SDK: حزمة SDK الرسمية لـ .NET، وتتضمن وثائق مفصلة حول الأنماط عديمة الحالة والمهام والتوافق.
• MCP Apps: الوثائق الرسمية وحزمة SDK للواجهات التفاعلية داخل مضيفات MCP.
• MCP Tasks: الوثائق الرسمية لعمليات MCP غير المتزامنة طويلة التشغيل.
• [MCP Registry](https://registry.modelcontextprotocol.

io/)：البنية التحتية الرسمية للسجل لاكتشاف خوادم MCP المنشورة.

الروابط ذات الصلة

• نظرة عامة على النسخة المرشحة للإصدار MCP 2026-07-28: شرح المسؤولين الرسميين لإعادة الهيكلة عديمة الحالة، والتوسعات، وتغييرات المصادقة، والتخزين المؤقت، والمحتوى المُهمَل.
• إصدارات مستودع مواصفات MCP: سجل إصدارات GitHub الرسمي لتنقيحات البروتوكول.
• خارطة طريق MCP 2026: خارطة الطريق الرسمية التي تغطي قابلية توسعة النقل، واتصالات الوكلاء، والحوكمة، والجاهزية المؤسسية.
• الوثائق الرسمية لتطبيقات MCP: المواصفات، وSDK، والأمثلة، وأدلة المطورين لتطبيقات MCP التفاعلية.
• امتداد مهام MCP:

المواصفات الرسمية للمهام، ودورة الحياة، ونموذج الأمان، والطرق المدعومة.

• التفويض المُدار للمؤسسات: الوثائق الرسمية حول الوصول إلى MCP استنادًا إلى مزودي الهوية المركزيين.
• أنفاق Anthropic MCP: وثائق Anthropic حول اتصالات MCP عبر الشبكات الخاصة في وكلاء Claude المُدارين.

الملخص

يدفع تنقيح MCP 2026-07-28 البروتوكول نحو أنماط البنية التحتية المعتمدة على نطاق واسع في أنظمة الويب الكبيرة. تصبح الطلبات ذاتية الاحتواء، وتختفي الجلسات على مستوى البروتوكول من التنسيق الجديد عبر الإنترنت، ويصبح توجيه البوابات أسهل، ولم يعد التوسع الأفقي العادي يتطلب جلسات MCP مُلصقة.

في الوقت نفسه، يتطور النظام البيئي صعودًا. تضيف تطبيقات MCP واجهات مستخدم تفاعلية، وتدعم المهام الأعمال غير المتزامنة المستمرة، ويُركّز التفويض المُدار للمؤسسات وصول المؤسسات، وتوفر أنفاق MCP مسارًا للمستخدمين على منصة Claude للوصول إلى الخوادم الداخلية الخاصة.

الانتقال ليس مجرد "حذف معرّفات الجلسات". تحتاج الفرق إلى تحديد التبعيات المخفية للحالة، وترحيل حالة التطبيق إلى مقابض صريحة أو تخزين مستمر، واختبار MRTR والمهام، وتحديث المصادقة، والحفاظ على التوافق مع العملاء القدامى، وإضافة قابلية مراقبة مناسبة.

التغيير الأهم هو على المستوى المعماري: ينتقل MCP من نمط تكامل الوكلاء الموجّه بالاتصال إلى بروتوكول عديم الحالة وقابل للتوسعة يتناسب بشكل أكثر طبيعية مع البنية التحتية السحابية الحديثة.