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

كاتب المقال، المصدر: 0x9999in1، ME News

ملخص

في 28 يوليو 2026، أصدر MCP الإصدار الخامس من المواصفات 2026-07-28، وتم تصنيفه رسميًا على أنه أكبر تعديل منذ نشأة البروتوكول. الإجراء الأساسي الوحيد هو حذف الجلسة من طبقة البروتوكول.
initialize/initialized لم يعد هناك تبادل مفاتيح،Mcp-Session-Id لم يعد هناك رأس الطلب. كل طلب يحتوي تلقائيًا على إصدار البروتوكول وهوية العميل وإعلانات القدرات، المكتوبة في _meta . يمكن لأي طلب أن يصل إلى أي مثيل، ويكفي توازن الحمل الدوراني العادي.
هذا ليس تحسينًا للأداء، بل هو خطأ في التصميم المعماري. كانت الجلسات المتمسكة وتخزين الجلسات المشتركة، في يوم من الأيام، الجزء الأغلى في فواتير خوادم MCP.
الحالة لم تختفِ. لقد نُقلت من طبقة النقل إلى معلمات الأداة، وتُسمى "مُعامل صريح". النموذج يرى بها، وبالتالي يمكنه التحكم بها.
تم دمج واجهة التفاعل (MCP Apps) والمهمات الطويلة (Tasks) رسميًا في إطار التوسع المُصدَّر، ولا يُضاف المزيد من الوظائف الجديدة إلى البروتوكول الأساسي. تم توحيد المصادقة مع OAuth 2.0 وOIDC في العالم الحقيقي، وانتقلت ميزات التفويض المُدارة للشركات إلى الإصدار المستقر في نفس اليوم.
التكلفة حقيقية: إنها تغيير جذري. دخلت Roots و Sampling و Logging مع نقل HTTP+SSE القديم جميعها في مرحلة التقاعد، وتم منح فترة انتقالية لا تقل عن 12 شهرًا.
جملة تقييم: لم يعد MCP يشبه واجهة إضافية لشركة مصنعة، بل بدأ يشبه أنبوبًا عامًا. الأنابيب ستكون أكثر متانة، لكنها أيضًا ستكون أقل تقبلًا.

السطران اللذان تم حذفهما هما جوهر هذه التحديثات.

أولاً، دعنا نذكر حقيقة غير بديهية.

الجزء الأهم في هذا التحديث، الذي يُسمى "أكبر تحديث في التاريخ"، ليس ما أُضيف، بل ما أُزيل.

initialize و initialized هذه المجموعة من الإيماءات كانت موجودة منذ يوم ولادة MCP في نوفمبر 2024.Mcp-Session-Id هذا رأس الطلب هو الأساس لجميع حلول النشر بعد تنفيذ MCP عن بُعد. في 28 يوليو، تم إزالة الشيئين معًا.

كيف يبدو الطلب الجديد؟ بسيط جدًا.

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

تم رفع أسماء الطرق والأدوات إلى رؤوس HTTP. لم يعد يحتاج الجسر، ومُحدِّد التدفق، وجدار الحماية من تحليل محتوى JSON للاستنتاج عن طبيعة الاستدعاء، بل يكفي النظر إلى الرأس. تم تضمين إصدار البروتوكول، ومعلومات العميل، وإعلانات القدرات في _meta ليتم إرسالها مع الطلب. هل تريد أن تسأل الخادم مسبقًا عن قدراته؟ أُضيف جديد server/discover، لكنه اختياري وليس إلزاميًا.

ماذا يعني هذا؟ يعني أن خوادم MCP أصبحت أخيرًا عبارة عن حمل HTTP عادي.

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

يبدو كأنه كلام نموذجي من الشركة المصنعة. لكن هذه المرة مختلفة، لأنها تتحدث عن شيء محدد واحد: اختفى الجلسة، لذا يمكن لـ Lambda أن تعمل، ويمكن لـ Workers أن تعمل، ويمكن للعقد الحافة أن تعمل.

ثانيًا، الجلسة المتمسكة هي السقف الحقيقي على طريق توسعة الوكلاء

لماذا يتم اتخاذ هذا الإجراء الصارم؟

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

لذلك اضطر الجميع جميعًا إلى فعل الشيء نفسه: إما فتح جلسات لاصقة بحيث يتذكر توازن الحمل إلى أي خادم يجب توجيه كل عميل؛ أو إنشاء طبقة من تخزين مشترك مثل Redis لتخزين حالة الجلسة وجعلها قابلة للقراءة من قبل جميع المثيلات.

كلا الطريقين ممكنان. لكن كلاهما يفرض ضريبة خفية.

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

عندما يكون الحجم صغيرًا، هذا ليس مشكلة. عندما يزداد الحجم، يصبح مشكلة.

لمعرفة كيف تغير الحجم، انظر إلى الأرقام: في ديسمبر 2025، بمناسبة الذكرى السنوية الأولى لظهور MCP، بلغ عدد تنزيلات SDK الشهرية 97 مليون مرة. وفي هذا الإصدار في يوليو 2026، أشارت Anthropic إلى أن عدد التنزيلات الشهرية تجاوز 400 مليون مرة، بينما ذكرت المدونة الرسمية أن العدد "قريب من خمسة مليارات"، بزيادة أربع مرات خلال العام. وتجاوز إجمالي عدد تنزيلات SDKs لـ TypeScript وPython عتبة المليار كل منهما.

يحتوي دليل موصلات Claude الخاص بـ Anthropic الآن على أكثر من 950 خادم MCP. وتوفر بيانات شركة المراقبة Honeycomb دليلاً أوضح على أن الوكلاء يعملون فعليًا: فما يقارب 20% من جميع الاستعلامات التفاعلية الشهرية الخاصة بهم تُطلقها الوكلاء.

أربعة أضعاف في ستة أشهر. تحت هذا المنحنى، ستُضخم أي "ضرائب خفية" هندسية إلى فواتير واضحة.

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

ثلاثةً، لم تختفِ الحالة، بل نُقلت أمام النموذج

هناك سوء فهم يجب توضيحه.

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

البديل المحدد في المواصفات يُسمى مُعالجًا صريحًا. هل تحتاج أداتك إلى الحفاظ على الحالة عبر المكالمات؟ إذًا، اجعل الأداة تُرجع مُعرّفًا، مثل basket_id، ثم يُعيد النموذج هذا المُعرّف كمعلمة في المكالمة التالية.

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

توقف قليلاً وفكّر في وزن هذه الجملة.

المنطق السابق كان: الحالة هي شأن البنية التحتية، ولا ينبغي للنموذج أن يهتم بها. أما المنطق الحالي فهو معكوس: الحالة جزء من سلسلة استدلال النموذج، وإخفاؤها يجعل تقييم النموذج أقل دقة.

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

نفس الفكرة تم تطبيقها على مسار طلبات الخادم التي تُبادر بالطلب. في الماضي، كان الأداة تطلب من المستخدم: "هل تؤكد حذف هذه الملفات الثلاثة؟" عبر تدفق SSE مستمر يُعيد الطلب إلى العميل. بعد الانتقال إلى الحالة غير المخزنة، اختفى هذا التدفق، وحل محله طلبات متعددة الجولات، وتُعرف اختصارًا بـ MRTR.

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

قال مسؤول منتج Supabase، إنيان باراميشواران، شيئًا حقيقيًا: كان دعم elicitation معلقًا في خارطة طريقهم لفترة طويلة، لكن لم يكن يمكن تنفيذه لأن Supabase MCP يعمل بشكل غير محفوظ للحالة. بعد MRTR، أصبح ذلك ممكنًا، حيث يمكن للأدوات التحقق من التكلفة قبل إنشاء المشروع، وسؤال المستخدم قبل حذف البيانات.

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

رابعًا: الإطار الموسع: البروتوكول يبدأ في تعلم "عدم اكتساب الوزن"

الرهان الحقيقي الثاني هو أن إطار التوسع تحول من عادة إلى نظام.

تسمية DNS العكسية، من خلال extensions تنفيذ تفاوض القدرات، مستودعات منفصلة لـ ext-* مع مُوَكَّلين معتمدين، وإصدارات مستقلة عن المواصفات الأساسية. يبدو ذلك مملًا، لكنه يحل المشكلة التي تواجه جميع البروتوكولات الناجحة: تضخم الجزء الأساسي.

تم ترسيخ التوسيعين الآن رسمياً.

تُمكّن تطبيقات MCP الخادم من إرسال واجهة التفاعل مباشرةً إلى المحادثة. ليست نصًا بسيطًا، ولا JSON منظمًا، بل واجهة HTML كاملة تعمل داخل iframe في بيئة معزولة. يمكن أن تتضمن الرسوم البيانية، النماذج، والمحددات. يكمن التصميم الأساسي في ضرورة إعلان الأدوات مسبقًا عن قوالب واجهة المستخدم، بحيث يمكن للعميل تنزيلها مسبقًا، كما يمكنه إجراء مراجعة أمنية قبل عرض أي شيء. تتم عمليات التفاعل على الواجهة عبر قناة JSON-RPC العادية الخاصة بالأدوات.

معالجة مشكلة النصف الآخر: المهام المستهلكة للوقت. لقد تمت ترقيتها من ميزة تجريبية إلى امتداد رسمي، وتم إعادة تصميم دورة حياتها لتكون بدون حالة:tools/call تُرجع معرف مهمة، ويستخدم العميل tasks/get للتحقق الدوري، مع إضافة tasks/update و tasks/cancel.

يجب ملاحظة أن tasks/list تم حذفه. السبب واضح: بدون جلسة، فإن عملية "سرد جميع المهام" لم تعد آمنة، حيث لا يمكنك تحديد من تنتمي إليه "الجميع".

هذا التوسيع مقدّم من AWS. وقال سوامي سيفاسوبورامانيان، نائب رئيس الذكاء الاصطناعي الوكيلي في أمازون، إن المواصفات الجديدة والهيئة الأساسية بدون حالة قد دُمجت في Bedrock AgentCore. أما من جانب مايكروسوفت، فقد أفادت تينا شوكمان، نائبة رئيس هندسة Foundry، أن MCP مكّنهم من التوسع من عشرات التكاملات إلى آلاف التكاملات، حيث يجمع Foundry toolbox الأدوات عبر نقطة نهاية MCP موحدة لتوحيد الإدارة والهوية والقابلية للرصد.

بروتوكول يُستخدم في آنٍ واحد من قبل AWS وMicrosoft وGoogle Cloud وCloudflare كأساس لبناء أشياء عليه. هذا لم يعد معيار إضافي لشركة واحدة.

خامساً، المشكلة الحقيقية ليست الاتصال، بل الهوية

في المدونة الرسمية، هناك اعتراف صادق: خلال العام الماضي، كان الترخيص هو المجال الذي قضوا فيه أكبر قدر من الوقت عند التحدث مع المُنفِّذين.

هذه النسخة أضافت ستة SEP في الترخيص، وكلها أمور غير مثيرة ولكنها ضرورية. يجب على خادم الترخيص إرجاع معلمة iss وفقًا لـ RFC 9207، ويجب على العميل التحقق منها قبل تبديل الرمز، وهذا الإجراء يسد هجوم التخليط على خادم الترخيص. يجب على العميل الإعلان عن application_type أثناء التسجيل الديناميكي، وأخيرًا لن يتم رفض مراجعات localhost للتطبيقات المكتبية وواجهة سطر الأوامر دون سبب. يتم ربط الشهادات بالissuer الذي أصدرها، ولا يمكن إعادة استخدامها عبر خوادم ترخيص مختلفة.

الأكثر دلالةً هو: تم إيقاف استخدام تسجيل العميل الديناميكي (DCR) رسميًا، مع توجيه الاتجاه نحو وثيقة بيانات تعريف العميل (CIMD). لا يزال يمكن استخدام DCR مع الحفاظ على التوافق العكسي، لكنه سيتم إزالته في الإصدارات المستقبلية.

في نفس اليوم، تحول التوسيع المُصرح به للتخزين المؤسسي (EMA) إلى الإصدار المستقر. قد يكون لهذا الأمر أهمية أكبر لتقنية المعلومات المؤسسية من الحالة غير المحفوظة.

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

يُحوّل EMA مزود الهوية الخاص بالشركة إلى جهة قرار. يتم استخدام إفادة ID-JAG الصادرة من مزود الهوية أثناء تسجيل الدخول الأحادي، ويستخدم العميل هذه الإفادة لاستبدالها برمز وصول من خادم التفويض MCP. لا يمر المستخدم أبدًا عبر صفحة موافقة على خادم واحد.

أوكتا هي أول مزود هوية مدعوم عبر وصوله عبر التطبيقات المتقاطعة. تم توصيل جميع منتجات كلاود و VS Code من جانب العميل. من جانب الخادم، تم دعم أسانا، أتلسيان، كانفا، فيجما، جرانولا، لينيار، وسوبابيس، بينما يجري تطبيق سلاك. ووصف توم مور، مدير الهندسة في لينيار، التجربة بأنها ممتعة: "تسجيل دخول واحد، وجميع موصلات MCP تُضبط تلقائيًا — إنه سحري."

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

لكن يجب أن أكمل القول: الحالة غير المحفوظة وEMA تحلان مشكلتي الهوية والحجم، وليس كل جوانب أمان الوكلاء. الأرقام العشرة من تقرير سيسكو "حالة أمان الذكاء الاصطناعي لعام 2026" لا تزال معلقة هناك: 83% من المنظمات تخطط لتنفيذ قدرات الوكلاء، بينما فقط 29% يشعرون أنهم مستعدون. مشاكل حقن التوجيهات، وتسميم وصف الأدوات، واستخدام الوكلاء كمنصات للحركة الأفقية، لن تختفي فقط لأن البروتوكول حذف الجلسة.

الخبر السار هو أنMcp-Method وMcp-Name بعد التفعيل، انخفضت تكلفة تنفيذ الاستراتيجية من قبل البوابة. كما تطلب المعيار من الخادم رفض الطلبات التي لا تتطابق رؤوسها مع محتواها، مما يسد فجوة من نوع تضارب التوجيه والأمان. هذا تحسن جوهري في الموقف الدفاعي. لكنه ينتهي هنا.

سادساً: التكلفة: هذا تغيير تدميري، وقد صدرت الفاتورة

أنا لا أحب الحديث عن العوائد فقط دون الحديث عن الحساب.

هذه النسخة هي من مستوى تغيير مُحطم. دخلت ثلاث ميزات — Roots و Sampling و Logging — جميعها في حالة الإيقاف الرسمي. كما تم إيقاف نقل HTTP+SSE القديم رسميًا. كما أنشأت المواصفات سياسة رسمية لدورة حياة الميزة: Active إلى Deprecated إلى Removed، مع مرور ما لا يقل عن 12 شهرًا في كل مرحلة.

هناك أيضًا بعض التفاصيل الصغيرة التي قد تُسبب إزعاجًا: الآن يدعم مخطط الإدخال والإخراج للأدوات مفردات JSON Schema 2020-12 الكاملة،oneOf،anyOf، ويمكن استخدام الشروط؛ كما تم تغيير رمز الخطأ "المورد غير موجود" من -32002 المخصص إلى -32602 القياسي لـ JSON-RPC. إذا كنت قد ثبتّ -32002 مباشرة في الكود، فعليك تعديل هذا السطر.

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

لذلك، يستحق الجدول الزمني أن يُعاد ذكره. تم تأكيد الإصدار التجريبي في 21 مايو، مع الإصدار الرسمي في 28 يوليو، مما ترك عشرة أسابيع كاملة لمُدراء SDK ومُنفذي العميل للتحقق. دعمت جميع واجهات برمجة التطبيقات من المستوى الأول الأربعة (TypeScript وPython وGo وC#) الإصدار الجديد في نفس اليوم، بينما كانت واجهة برمجة التطبيقات Rust في مرحلة بيتا.

نافذة التحقق العامة لمدة عشرة أسابيع + فترة انتقالية للتقاعد مدتها 12 شهرًا + معيار SEP القياسي يجب أن يكون له سيناريو متوافق في مجموعة اختبارات التوافق قبل أن يتم تأكيده. هذه العناصر الثلاثة معًا هي ما أراه أبرز جوانب هذا التحديث من حيث الاحترافية.

إنه ليس تجميل التغييرات التدميرية، ولا رمي التغييرات التدميرية على عاتق المجتمع لوحده.

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

من المثير للاهتمام أن الهجرة أدت أيضًا إلى عوائد إيجابية. قدم إنريكو تونياتو، الرئيس التنفيذي للتقنية في Manufact وراء الإطار المفتوح mcp-use، أرقامًا محددة: باستخدام SDK v2 الجديد لفصل العميل عن الخادم، تم تقليل حجم الحزمة بنسبة حوالي 83%، وازداد السرعة بنسبة 25%.

عملية تخفيف للهيكل، وتم أيضًا تخفيف الحزمة. مثل هذه الأمور لا تحدث غالبًا.

سابعًا: حكمي

كيف ترى هذا التحديث؟

أول تقييم لي هو: هذا خطأ تم الاعتراف به، واعتراف جميل.

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

عندما تصبح التصحيحات كثيرة بدرجة كافية، حان الوقت لتغيير الأساس. وفقًا لـ ديفيد سوريا بارا، أحد المخترعين المشتركين للبروتوكول، فإن هذه النسخة تضم جميع الدروس المستفادة من الـ 18 شهرًا الماضية. ويتّضح ذلك بشكل أدق من خلال نيك كوبر، المُحافظ الأساسي: MCP يبلغ من العمر عامًا ونصف، وهو يمتص خبرات عقود من تصميم بروتوكولات الويب ليصبح بروتوكولًا أكثر نضجًا.

الحكم الثاني: النقطة الفاصلة الحقيقية لهذا التحديث هي الحوكمة، وليس التقنية.

يجب مراجعة خط الزمن مرة أخرى. في 25 نوفمبر 2024، أطلقت Anthropic MCP مفتوح المصدر. في 9 ديسمبر 2025، تبرعت MCP إلى Agentic AI Foundation الجديد التابع لمؤسسة Linux، وهو صندوق مخصص أُطلق بالتعاون بين Anthropic وBlock وOpenAI، مع دعم من Google وMicrosoft وAWS وCloudflare وBloomberg. بعد ثمانية أشهر، تم إطلاق الإصدار الكبير الأول.

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

يمكن أيضًا رؤية تغيير في الأولويات من خلال قائمة منصات النظام البيئي. تتحدث Figma عن دمج التصميم مع الكود، وIntuit تتحدث عن تقديم تجربة مالية ذكية موثوقة لمليار من المستهلكين والعملاء المؤسسيين، وZoom تتحدث عن نقل الذكاء في الاجتماعات بأمان إلى منصات الذكاء الاصطناعي. هذه ليست لغة ألعاب المطورين، بل لغة خطوط المنتجات.

الحكم الثالث، وهو الذي أعتقد أنه يجب التعبير عنه أكثر من غيره: نضج البروتوكول يتطلب ثمنًا، والثمن يُسمى "عدم القدرة على التمرد".

عديم الحالة، قابل للترحيل، قابل للتخزين المؤقت، قابل للتتبع. يُمرر سياق التتبع W3C الآن عبر _meta بمفاتيح ثابتة، وهو متوافق مع OpenTelemetry للتعقب الموزع من الصندوق. هذه المصطلحات التي رأيتها جميعًا في تطور HTTP وREST وgRPC.

MCP يتحول إلى أنبوب لن تتحدث عنه. مثلما لا يتحدث أحد عن مدى إثارة TCP اليوم.

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

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

هذا الإصدار قدم هذه الأمور خطوة كبيرة إلى الأمام.

أما من حيث الإثارة، فالأنبوب لا يتحمل مسؤولية توفير الإثارة. فهو فقط مسؤول عن عدم التسرب عندما لا تنظر إليه.

Source citation

مدونة بروتوكول سياق النموذج، "مواصفات 2026-07-28"، 28 يوليو 2026. https://blog.modelcontextprotocol.io/posts/2026-07-28/
مدونة بروتوكول سياق النموذج، "التوثيق المُدار من قبل المؤسسة: OAuth بدون تدخل لـ MCP"، 2026. https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/
Claude بواسطة Anthropic، "إحضار MCP 2026-07-28 إلى Claude"، 2026 年 7 月 28 日. https://claude.com/blog/bringing-mcp-2026-07-28-to-claude
مدونة خوادم MCP، "مواصفات MCP لعام 2026-07-28: مستقبل خالٍ من الحالة وقابل للتوسيع"، 2026 年. https://blog.mcpservers.org/posts/mcp-spec-2026-07-28
مؤسسة لينكس، "مؤسسة لينكس تُعلن عن تأسيس مؤسسة الذكاء الاصطناعي الوكيلي"، 9 ديسمبر 2025. https://linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
Anthropic، "التبرع ببروتوكول سياق النموذج وإنشاء مؤسسة الذكاء الاصطناعي الوكيلي"، ديسمبر 2025. https://anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
Cisco، "حالة أمن الذكاء الاصطناعي 2026"، 2026. https://blogs.cisco.com/ai/cisco-state-of-ai-security-2026-report
IT之家، أكبر تحديث منذ الإطلاق: إصدار مواصفات MCP 2026-07-28 والانتقال إلى النواة "غير الحالة"، 29 يوليو 2026. https://www.ithome.com/0/983/102.htm