بروتوكول HTTP القابل للبث، الحقب الثلاث وعقد النقل الحالي

شهد بروتوكول النقل HTTP عن بُعد الخاص بـ MCP ثلاثة تصميمات متميزة خلال عامين تقريبًا. استخدم بروتوكول النقل HTTP+SSE الصادر في 05-11-2024 نقطتي نهاية وتدفقاً طويل الأمد؛ وقد تم إيقاف دعمه منذ 26-03-2025 وهو مرشح للإزالة مستقبلاً. حلّ بروتوكول Streamable HTTP محله في 26-03-2025 بنقطة نهاية واحدة، لكن ذلك الشكل الأول كان لا يزال يحمل جلسات على مستوى البروتوكول، وتدفق GET مستقلاً، وطلبات يبدأها الخادم عبر SSE، وتدفقات قابلة للاستئناف. أزالت مراجعة 28-07-2026 تلك الآليات. وما تبقى هو تصميم نظيف بشكل استثنائي: حيث يتم إرسال كل رسالة JSON-RPC من العميل كطلب POST خاص بها، وتكون استجابات الطلبات إما كائن JSON واحداً أو تدفق SSE مخصصاً لذلك الطلب، كما يتم تكرار بيانات وصفية مختارة للطلب في الرؤوس (headers) حتى تتمكن الوسائط من توجيه وفحص حركة المرور دون الحاجة إلى تحليل نص الرسالة. هذا القرار التصميمي الأخير هو ما يستحق القراءة بتمعن.

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

1. العصور الثلاثة

05-11-2024 — بروتوكول HTTP+SSE. نقطتا نهاية. كان العميل يرسل طلب GET يفتح تدفق SSE، وكان أول حدث فيه هو حدث endpoint يخبر العميل بالمكان الذي يجب إرسال طلب POST إليه. كانت كل العمليات التي يبدأها الخادم تصل عبر هذا التدفق طويل الأمد. تم إيقاف دعمه منذ 26-03-2025 بموجب سياسة دورة حياة الميزات، ويُنصح بعدم اعتماده في أي تطبيقات جديدة.

من 26-03-2025 إلى 25-11-2025 — بروتوكول Streamable HTTP، الشكل الأول. نقطة نهاية واحدة لـ MCP، وهو ما مثل تبسيطاً جوهرياً. لكن أربع آليات أبقت البروتوكول معتمداً على الحالة: كان بإمكان الخوادم تعيين جلسة عبر رأس Mcp-Session-Id يتم إنهاؤها بطلب HTTP DELETE؛ وكان بإمكان العملاء فتح تدفق SSE مستقل باستخدام GET لاستقبال الرسائل التي يبدأها الخادم؛ وكان بإمكان الخوادم إرسال طلبات JSON-RPC عبر تدفقات SSE؛ وكانت التدفقات قابلة للاستئناف عبر Last-Event-ID.

28-07-2026 — الشكل الحالي. لم يعد أي من تلك الآليات الأربع موجوداً. تسرد ملاحظات المراجعة عمليات الإزالة بوضوح: اختفت نقطة نهاية تدفق GET والجلسات على مستوى البروتوكول، وتضيف الأقسام أدناه أن التدفقات غير قابلة للاستئناف وأنه يجب على الخوادم عدم إرسال طلبات مستقلة عبر التدفق.

يتعامل الخادم الذي يطبق المراجعة الحالية فقط مع حركة المرور القديمة بسلوك محدد: طلبات GET أو DELETE إلى نقطة نهاية MCP تتلقى 405 Method Not Allowed؛ ويتم تجاهل ترويسة Mcp-Session-Id ولا يتم إنشاء أو تكرار أي معرف جلسة؛ كما يتم تجاهل ترويسة Last-Event-ID .

2. بروتوكول النقل (Wire Protocol)

يكشف الخادم عن مسار نقطة نهاية HTTP واحد — وهو نقطة نهاية MCP — الذي يدعم POST. تعتبر أساسيات أمان النقل مهمة قبل أي تحسين للبروتوكول: يجب على الخوادم التحقق من ترويسة Origin في الاتصالات الواردة وإرجاع رمز 403 إذا كان المصدر موجوداً ولكنه غير صالح؛ ويجب على الخوادم التي تعمل محلياً الارتباط بـ localhost بدلاً من جميع الواجهات؛ كما يجب على الخوادم مصادقة الاتصالات. توجد هذه المتطلبات لتقليل مخاطر إعادة ربط DNS والوصول غير المصرح به.

الإرسال. كل رسالة JSON-RPC من العميل تكون في طلب POST مستقل. يجب على العميل تضمين ترويسة Accept التي تدرج كلاً من application/json و text/event-stream، ويجب أن يكون نص الرسالة عبارة عن طلب أو إشعار JSON-RPC واحد. يجب ألا يرسل العملاء استجابات JSON-RPC. هناك نقطة دقيقة تهم المطورين: على الرغم من أن بروتوكول النقل يحدد كيفية عمل إشعار POST، إلا أن البروتوكول الأساسي بتاريخ 2026-07-28 لا يحدد أي إشعارات من العميل إلى الخادم عبر Streamable HTTP ولا يحدد متطلبات ترويسة البيانات الوصفية لإشعارات POST.

الإشعارات. إذا قبل الخادم الطلب، فإنه يعيد 202 Accepted بدون محتوى؛ وإذا لم يتمكن من ذلك، فإنه يعيد حالة خطأ HTTP، مع إمكانية تضمين استجابة خطأ JSON-RPC بدون id.

الطلبات. يعيد الخادم إما Content-Type: application/json مع كائن JSON واحد، أو Content-Type: text/event-stream مع تدفق SSE مخصص لهذا الطلب. يجب أن يدعم العميل كلاهما، حيث يختار الخادم نوع الاستجابة لكل طلب على حدة، لذا فإن العميل الذي يدعم نوعاً واحداً فقط سيتعرض لأخطاء غير متوقعة.

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

الإلغاء. يجب أن يتعامل الخادم مع إغلاق تدفق استجابة SSE على أنه إلغاء لهذا الطلب، ولأن لكل طلب تدفقاً خاصاً به، فإن قطع الاتصال يكون واضحاً ولا لبس فيه. يُستخدم إشعار الإلغاء الخاص بالبروتوكول الأساسي فقط عبر stdio؛ أما في وسيلة النقل هذه، فلا توجد رسالة إلغاء ولا يُتوقع وجودها.

3. أين ذهبت المهام التي يبادر بها الخادم

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

طلب شيء من العميل — مثل أخذ العينات، أو الاستيضاح، أو الجذور — أصبح الآن مضمناً في النتائج كطلبات إدخال ضمن نمط طلبات الجولات المتعددة. يعيد الخادم InputRequiredResult تحمل inputRequests؛ يجمع العميل ما طُلب منه ويعيد إرسال الطلب الأصلي مع مطابقة inputResponses. إنه طلب POST ثانٍ، وليس عملية دفع (push).

إشعارات التغيير طويلة الأمد — تغييرات قائمة الأدوات، وتحديثات الموارد — يتم الحصول عليها عن طريق إرسال طلب subscriptions/listen يكون رده عبارة عن تدفق SSE يظل مفتوحاً ويوفر فقط أنواع الإشعارات التي اختار العميل الاشتراك فيها. لا تظهر الإشعارات المرتبطة بنطاق الطلب مثل التقدم هنا؛ بل تتدفق فقط عبر مسار الطلب الذي تنتمي إليه.

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

4. تفصيلان يسببان مشاكل خلف الوكيل (Proxy)

تتضمن المواصفات ملاحظتين تشغيليتين موجودتين لأن العلاقة بين SSE والوكلاء العكسيين (reverse proxies) غالباً ما تكون معقدة.

التخزين المؤقت (Buffering). عند بدء تدفق SSE، يجب على الخوادم تضمين X-Accel-Buffering: no. يوجه هذا الوكلاء العكسيين مثل nginx لتعطيل التخزين المؤقت للاستجابة. وبدونه، قد يقوم الوكيل بتجميع الرسائل قبل إعادة توجيهها — مما يؤدي إلى زيادة زمن الاستجابة وتقويض الغرض من البث. إذا وصلت تحديثات التقدم المتدفقة دفعة واحدة في النهاية، فإن التخزين المؤقت للاستجابة هو أحد أول السلوكيات الوسيطة التي يجب التحقق منها.

رسائل الحفاظ على الاتصال (Keep-alives). بالنسبة للتدفقات طويلة الأمد، وخاصة استجابة subscriptions/listen ، يُنصح الخوادم بإرسال سطر تعليق SSE بشكل دوري — وهو سطر يبدأ بنقطتين رأسيتين — كإشارة للحفاظ على الاتصال، وذلك لضمان عدم قيام الوسائط أو مهلات الخمول بإغلاق الاتصال الهادئ. وفقاً لمواصفات SSE، لا يحمل التعليق أي بيانات للحدث، ويجب على العملاء تجاهل هذه الأسطر بدلاً من التعامل معها كبيانات تالفة.

5. اتفاقية الترويسة (Header Contract)

هذا هو الجزء الذي يجعل وسيلة النقل مختلفة حقاً عن اتفاقية JSON-RPC-over-HTTP، وتوضح المواصفات غرضها مباشرة: تقوم وسيلة النقل بعكس حقول محددة من جسم JSON-RPC إلى ترويسات HTTP، بحيث يمكن للوسائط — مثل موازنات التحميل، والبوابات، وأدوات المراقبة — توجيه الطلبات وفحصها دون الحاجة إلى تحليل جسم الطلب.

MCP-Protocol-Version — مطلوب في كل طلب POST، ويجب أن تتطابق قيمته مع إصدار البروتوكول الموجود في حقل _metaالموجود في جسم الطلب. يتم رفض أي عدم تطابق بالرمز 400 Bad Request وخطأ من نوع HeaderMismatch . أما الإصدار الذي لا يدعمه الخادم فيتم الرد عليه بالرمز 400 مع خطأ يدرج الإصدارات التي يدعمها الخادم بالفعل. بينما يتم الرد على الطريقة غير المنفذة بالرمز 404 مع خطأ JSON-RPC -32601، وهو ما يميزه عن الخادم التقليدي الذي يستخدم الرمز 404.

Mcp-Method — يعكس method. مطلوب في جميع طلبات JSON-RPC.

Mcp-Name — يعكس params.name أو params.uri. مطلوب لـ tools/call، resources/read، و prompts/get.

بالنسبة لطلبات JSON-RPC، تُعد ترويسات الطلب القياسية هذه مطلوبة للامتثال في النطاقات المذكورة أعلاه. تُعد طلبات POST للإشعارات حالة استثنائية منفصلة: يحدد هذا الإصدار آليات النقل الخاصة بها ولكن ليس متطلبات ترويسة البيانات الوصفية الخاصة بها. الحد الأدنى المتوافق لـ tools/call يبدو الطلب على الشبكة على النحو التالي:

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

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"get_weather","arguments":{"location":"Seattle, WA"},
 "_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28"}}}

يمكن للخوادم المضي قدماً وتحديد معلمات أدوات معينة ليتم عكسها، باستخدام x-mcp-header كملحق في مخطط المعلمة، مما ينتج عنه ترويسات باسم Mcp-Param-{Name}. الخادم الذي يضيف تعليقاً توضيحياً لمعلمة المنطقة يحصل على Mcp-Param-Region: us-west1 بجانب النص الأساسي — وهو بالضبط الشكل الذي يحتاجه الموجه لإرسال استعلام إلى الواجهة الخلفية الإقليمية الصحيحة دون قراءة الحمولة.

القيود المفروضة على هذا الملحق صارمة وتستحق المعرفة قبل التصميم بناءً عليها. يجب أن تكون القيم غير فارغة، ويجب أن تتوافق مع صيغة رموز HTTP، ويجب ألا تحتوي على أي رموز تحكم، ويجب أن تكون فريدة بغض النظر عن حالة الأحرف داخل المخطط. يُسمح فقط بالأنواع البدائية — السلسلة النصية (string)، والقيمة المنطقية (boolean)، والرقم الصحيح (integer)، مع استبعاد number صراحةً. كما يجب أن تكون الخاصية التي تم التعليق عليها قابلة للوصول بشكل ثابت من جذر المخطط عبر سلسلة تتكون فقط من مفاتيح properties : وليس من خلال كلمات مفتاحية للمصفوفات، ولا من خلال oneOf، anyOf، allOf، أو not، وليس من خلال الشروط، وليس من خلال $ref. الكائنات المتداخلة مقبولة طالما أن كل خطوة هي properties مفتاح. أي تعليق توضيحي في أي مكان آخر يجعل تعريف الأداة غير صالح، ويجب على العميل المتوافق استبعاد تلك الأداة من tools/list مع تسجيل تحذير — بحيث لا يؤدي تعريف واحد غير صالح إلى تعطيل البقية.

يتم ترميز القيم التي لا يمكن تمثيلها بأمان كنص ASCII عادي باستخدام Base64 داخل علامة حجز، =?base64?...?=، وينطبق نفس الترميز على Mcp-Name. تفصيل دقيق: يجب أيضاً ترميز أي قيمة ASCII عادية تبدو مطابقة لعلامة الحجز، وذلك لإزالة أي غموض.

6. لماذا يعتبر عدم التطابق خطأً

يجب على الخوادم التي تعالج نص الطلب رفض الطلبات التي لا تتطابق فيها قيم الترويسة مع قيم النص المقابلة، وإرجاع 400 مع خطأ JSON-RPC -32020. توضح المواصفات السبب بشكل صريح، وهو حجة أمنية وليست مجرد مسألة تنظيمية: فهذا يمنع الثغرات الأمنية عندما تعتمد مكونات مختلفة في الشبكة على مصادر حقيقة مختلفة — مثل موازن الأحمال الذي يوجه الطلب بناءً على قيمة الترويسة بينما ينفذ خادم MCP العمل بناءً على قيمة النص.

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

7. ماذا يعني هذا بالنسبة للبوابة (Gateway)

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

التوجيه دون تحليل. Mcp-Method و Mcp-Name يعنيان أن بإمكان الوكيل التمييز بين استدعاء الأداة وقراءة المورد، وتحديد الأداة المطلوبة، من خلال الترويسات (headers) فقط. وهذا هو الفرق بين طبقة مدركة لبروتوكول MCP وأخرى تضطر إلى إلغاء تسلسل كل حمولة لاتخاذ قرار (نظرة عامة على MCP).

كشف هوية الأداة لطبقة التخويل دون الحاجة إلى تحليل نص الطلب. يحمل طلب tools/call المتوافق اسم الأداة في Mcp-Name. وهذا يمنح الوسيط المدرك لبروتوكول MCP مدخلاً محدداً بالبروتوكول يمكنه استخدامه عند تطبيق سياسات خاصة بكل أداة؛ ومع ذلك، يجب أن تظل المصادقة والتخويل مفروضين من قبل البوابة/الخادم بدلاً من استنتاجهما من الترويسة نفسها (وثائق المصادقة والأمان في MCP).

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

المراقبة بأبعاد مفيدة. إن توفر اسم الأداة والطريقة دون الحاجة إلى تحليل النص الأساسي هو بالضبط ما تتطلبه القياسات عن بُعد (telemetry) لكل أداة، وهو يتماشى مع اتفاقيات استدعاء الأدوات الناشئة في معايير القياس عن بُعد (وثائق التحليلات والتتبع).

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

هناك التزام واحد يسير في الاتجاه الآخر، وينطبق على أي شيء يقع في المسار. الوسيط الذي لا يتعرف على Mcp-Param-{Name} يجب عليه تمريره وتجاهله بخلاف ذلك. إن إزالة الترويسات غير المعروفة — وهو إجراء افتراضي شائع في الوكلاء المحصنين — سيؤدي إلى تعطيل الخوادم المتوافقة التي تتوقع وجودها.

أين يتناسب إطار عمل الوكيل. لا يزال النقل بحاجة إلى متصل يقرر متى يجب استدعاء الأداة. TrueForge، وهو إطار عمل الوكيل مفتوح المصدر من TrueFoundry، يقوم بتشغيل حلقة التنفيذ تلك عبر استدعاءات النموذج، وأدوات MCP عن بُعد، والمهارات، والبيئات المعزولة، والموافقات، وإدارة السياق، وحالة الجلسة. ويدعم موصل MCP الخاص به الخوادم البعيدة باستخدام مصادقة الترويسة أو OAuth، بما في ذلك إيقاف مؤقت للتفويض داخل الدردشة عندما لا يكون المستخدم قد ربط خادماً بعد. وهذا يجعل الفصل واضحاً: يقوم TrueForge بتنسيق خطوة الوكيل؛ ويحدد Streamable HTTP عقد الاتصال بين العميل والخادم؛ ويمكن لبوابة TrueFoundry MCP التحكم في حركة مرور الأدوات التي يتم توجيهها عبرها عمداً. لا تغني أي من هذه الطبقات عن الأخرى.

8. وضعية قابلة للنشر

إذا كنت تشغل خوادم MCP، فتحقق من الأصل، وقم بمصادقة الاتصالات، واربط الخوادم المحلية بشكل متحفظ قبل القلق بشأن تحسين البث. ثم قم بإصدار X-Accel-Buffering: no في استجابات SSE وتعليقات keep-alive على التدفقات طويلة الأمد؛ إذ يمكن أن تتنكر مهلات التخزين المؤقت والخمول في هيئة زمن انتقال للتطبيق أو فشل في البث. تحقق من توافق الترويسة مع المتن بدلاً من الوثوق بأي منهما بمفرده، وقم بفك تشفير القيم المشفرة بـ sentinel قبل المقارنة. بالنسبة لحركة المرور من إصدارات Streamable HTTP السابقة، أرجع سلوك التوافق المحدد — 405 عند استخدام GET و DELETE، وتجاهل ترويسات الجلسة ومعرف الحدث — حتى تفشل العملاء القدامى أو تتكيف بشكل يمكن التنبؤ به.

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

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

9. ما الذي يعالجه البروتوكول — وما الذي لا يعالجه

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

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

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

المراجع

• بروتوكول سياق النموذج (Model Context Protocol) — مواصفات نقل HTTP القابلة للبث (28-07-2026)، وهو المصدر لآليات النقل، وأساس الأمان، وبيانات الطلب الوصفية، والتحقق، وقواعد التوافق الموضحة هنا.
• بروتوكول سياق النموذج (Model Context Protocol) — سجل تغييرات 28-07-2026، و مراجعة النقل بتاريخ 25-11-2025 للشكل السابق.
• بروتوكول سياق النموذج (Model Context Protocol) — طلبات الرحلات المتعددة (Multi Round-Trip Requests) و الاشتراكات.
• TrueFoundry — stdio مقابل بروتوكول HTTP القابل للبث — سياق النقل الأولي؛ مصادقة وأمن بروتوكول MCP؛ تحديد معدل الطلبات؛ التحليلات.
• TrueForge — بيئة اختبار الوكلاء مفتوحة المصدر و إعداد خادم MCP، وتوثيق موصلات MCP عن بُعد باستخدام مصادقة الترويسة (Header Auth) أو OAuth، والتفويض داخل الدردشة، والموافقات، وإدارة السياق، والجلسات المستمرة.

تمت صياغة الآليات، ومستويات المتطلبات، وأسماء الترويسات، ورموز الخطأ، وقواعد التوافق، ومتطلبات أمن الحالة MRTR بناءً على نص المواصفات المرتبط بتاريخ 28 يوليو 2026؛ كما تم تكييف طلب المثال من التوضيح الوارد في المواصفات نفسها. لقد تغير تصميم بروتوكول HTTP عن بُعد الخاص بـ MCP بشكل جوهري عبر ثلاث حقب، وتعتبر المواصفات هي المرجع الأساسي لهذا الملخص. تقتصر ادعاءات منتج TrueFoundry على القدرات الموثقة في الصفحات الحالية المرتبطة؛ ولا يؤكد هذا المنشور أن إصداراً معيناً من البوابة المنشورة يستخدم كل ترويسة من الترويسات المذكورة في مواصفات 28 يوليو 2026 داخلياً.

‍