MCP

MCP Events: عندما يتحول الاشتراك إلى بيانات اعتماد لا يمكنك إبطالها

بقلم IdeaBosqueآخر تحديث: 2026年10月3日

النقاط الرئيسية

يضيف MCP Events مشغّل استيقاظ ثالثًا للوكلاء — إلى جانب جُدوال cron ورسائل البشر، أصبح بإمكان خادم MCP الآن دفع webhook موقّع إلى ChatGPT عندما يتغيّر شيء ما في تطبيق متصل.
الاشتراك يعيش أطول من رمز الوصول الذي أنشأه — ttlMs: null يطلب اشتراكًا بلا انتهاء، والصفّة (tuple) التي تعرّفه لا تحمل رمزًا ولا نطاقات ولا وقت انتهاء.
يدعم ChatGPT وضع التسليم عبر webhook لكنه لا يدعم مغلف الإبطال terminated الموجود في المسودة — الإشارة الوحيدة المتبقية للإبطال هي تحديث (refresh) فاشل يعيد -32012 Forbidden.
معيار النجاح الذي وضعه فريق العمل نفسه — تقديم SEP — لم يُنفّذ بعد — جدول الميثاق ما زال يقرأ "Ideating" ببطلٍ "TBD" وسجل تغييرات وحيد بتاريخ 24 مارس 2026.
تأطّر WorkOS للاشتراك بوصفه بيانات اعتماد — سجل دائم، أُنشئ تحت رمز وصول أحد المستخدمين، يخوّل خادمك دفع بيانات ذلك المستخدم إلى وكيلٍ ما بعد انتهاء صلاحية الرمز طويلًا.

حتى الآن، كان وكيل الذكاء الاصطناعي يستيقظ لأحد سببين: إطلاق جدول cron، أو كتابة إنسان رسالة. وفي 29 سبتمبر 2026، في DevDay، أعلنت OpenAI أنها تضيف دعم مواصفة MCP Events المقترحة، لتتمكن الإضافات من بدء الأتمتة عندما يحدث شيء ما في تطبيق متصل. تصف الوثائق كيف يدفع خادم MCP التحديثات إلى ChatGPT — حدث message.created مفلترًا بالقناة، أو comment.created مفلترًا بالمستند — بحيث يتصرف الوكيل عندما يصل تقرير خلل أو يُنشر تعليق مراجعة، لا عندما تتذكر أن تسأل. كتب ناثان باشيز، الذي يعمل في تصميم المنتجات في Notion، في 3 أكتوبر أنه لم يرَ حماسًا في هذا المقدار من الضآلة: "المشغّلات المدفوعة بالأحداث أمر ضخم."

يرسم هذا المقال ما ينفّذه MCP Events فعلًا، وفجوة عمر بيانات الاعتماد في مركزه، وما يجب أن يخزّنه خادم MCP الإنتاجي ويتحقق منه قبل أن يرسل webhook. يبني على MCP 2026-07-28: What the Stateless Protocol Means for B2B Agent Deployments، الذي غطّى النواة عديمة الحالة؛ ونحن هنا نركّز على الامتداد المدفوع بالأحداث ومشكلة دورة حياة الاشتراك التي لم يُنهِ فريق العمل تحديدها بعد.

ما ينفّذه ChatGPT فعلًا

يُدرج ميثاق فريق عمل MCP Triggers and Events بند عمل نشطًا واحدًا فقط: "SEP: Events in MCP v1 RFC"، الحالة "Ideating"، التاريخ المستهدف "End April"، البطل "TBD". للميثاق سجل تغييرات وحيد بتاريخ 2026-03-24: "Initial charter". يقود فريق العمل كلير ليغاوري من AWS وبيتر ألكسندر من Anthropic.

يحكي مستودع التبويج قصة أخرى. يحتوي على رسم تصميمي معلَّم بـ"Status: Draft proposal"، كاتبه بيتر ألكسندر، تاريخه 2026-02-19. وREADME صريح: المحتويات استكشافية و"لا تمثل مواصفات أو توصيات MCP رسمية". والمنفّذون يقدّمون بالفعل تقارير ميدانية ضده. أما غير الموجود فهو SEP مُقدَّم — معيار النجاح الذي أعلنه الميثاق نفسه: "SEP مقبول يعرّف آلية المشغّل/الاستدعاء ودورة حياة اشتراكه."

ينفّذ ChatGPT شريحة من تلك الوثيقة غير المكتملة. تتطلب دليل MCP Events من OpenAI الإصدار MCP 2.0 وإصدار البروتوكول 2026-07-28، ويدعم التسليم عبر webhook والتحقق من الاستدعاء من المسودة. أما الاستقصاء (polling) والبثّ وإشعارات التحكم gap وterminated في المسودة فلا تُدعم. وذاك الأخير مهم.

الميكانيكا مباشرة. يعلن الخادم إمكانية events في ردّ server/discover. يخبر المستخدم ChatGPT بما يريد مراقبته وكيف يريد الاستجابة. يستدعي ChatGPT التابع events/subscribe مع اسم الحدث ووسائط التصفية ورابط استدعاء (callback) وسر توقيع. يتحقق الخادم من الاستدعاء بتحدٍّ أحادي الاستخدام، ويخزّن الاشتراك، ثم يدفع الأحداث المطابقة webhooks موقّعة. ثلاثة توابع — events/list وevents/subscribe وevents/unsubscribe — تعمل على نقطة النهاية الموثّقة ذاتها التي تعمل عليها الأدوات.

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

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

قارن الاشتراك بالرمز الذي خوّل الاستدعاء. بموجب مواصفة التخويل 2026-07-28، على الخوادم أن تتحقق من أن رموز الوصول صدرت خاصّةً لها، وأن يُدرَج التخويل في كل طلب HTTP، وأن تتلقى الرموز غير الصالحة أو المنتهية 401. قصيرة العمر، ضيقة النطاق، يُعاد التحقق منها في كل طلب. أما الاشتراك فلا يرث شيئًا من ذلك. يعيّن الرسم التصميمي اشتراك webhook بالمفتاح (principal, delivery.url, name, arguments) — الحامل (principal) هو المعرّف القانوني للفاعل الموثّق من منظور الخادم. والصفّة لا تضم الرمز نفسه ولا نطاقاته ولا انتهاء صلاحيته. والعمر قابل للتفاوض حتى الأبد: ttlMs: null يطلب اشتراكًا بلا انتهاء، والخادم الذي يمنحه يعيد refreshBefore: null.

	رمز الوصول	اشتراك الأحداث
العمر	قصير، انتهاء ثابت	الـ TTL الذي تمنحه، حتى لا انتهاء إطلاقًا (`ttlMs: null`)
مرتبط بـ	خادمك كجمهور، مع النطاقات	`(principal, url, name, arguments)` — لا رمز ولا نطاقات ولا انتهاء
يُفحص	في كل طلب HTTP، و401 عند الانتهاء	يجب (MUST) عند الاشتراك؛ ينبغي (SHOULD) "بشكل دوري" بعدها، بلا فترة محددة
ينتهي عندما	ينتهي صلاحيته أو يبطله خادم التخويل	تنقضي مدة الـ TTL، أو يلغي العميل اشتراكه، أو ينهيه خادمك

رمز الوصول ينتهي. والاشتراك الذي أنشأه يواصل التسليم.

الإبطال غير متماثل في ChatGPT

المسودة واضحة بشأن الواجب وغامضة بشأن الإيقاع. عند الاشتراك يجب أن يكون الحامل موثّقًا ومخوّلًا. وعند التسليم: "ينبغي (SHOULD) أن يتحقق الخادم دوريًا من الأذونات مرة أخرى. إذا بُطل وصول المستخدم (على سبيل المثال، أُزيل من قناة Slack)،" ينهي الخادم الاشتراك. وتعيد مقدمة OpenAI الصياغة ذاتها: "أعد التحقق من وصول المستخدم خلال عمر الاشتراك وأوقف التسليم إذا بُطل الوصول."

كلمة "دوريًا" تؤدي عملًا كبيرًا في تلك الجملة. لا فترة محددة، ولا MUST، ولا اختبار توافق خلفها.

ثم تأتي الإشارة نفسها. في المسودة، ليكل وضع تسليم طريقته الخاصة في قول "توقّف". وبالنسبة إلى webhooks، فهي مغلف موقّع {"type":"terminated"} يُرسل بـ POST إلى رابط الاستدعاء. بعد ذلك لا يعد الاشتراك موجودًا، فيعيد التحديث اللاحق -32012 Forbidden إذا كانت سبب الإنهاء ما يزال قائمًا. ذلك المغلف هو طريقة البروتوكول في إخبار الوكيل "توقف هذا، وهذا السبب". وهو أيضًا أحد إشعارَي التحكم اللذين لا يدعمهما تكامل ChatGPT.

وضع التسليم	كيف تقول المسودة "توقّف"	في ChatGPT
الاستقصاء	خطأ في الاستقصاء التالي	الوضع غير مدعوم
البثّ الدفعي	`notifications/events/terminated`	الوضع غير مدعوم
Webhook	مغلف `terminated` موقّع يُرسل بـ POST إلى الاستدعاء	الوضع مدعوم، المغلف غير مدعوم
أي وضع	يفشل التحديث التالي بـ `-32012 Forbidden`	الإشارة الوحيدة المتبقية

في تكامل ChatGPT، تكون الإشارة الوحيدة المتبقية للإبطال تحديثًا فاشلًا. إذا بُطل وصول مستخدم وأوقف خادمك التسليم، فلا يتعلم الوكيل ذلك إلا عندما تنقضي مدة TTL للاشتراك ويفشل التحديث. وإذا منحت ttlMs: null، فلن يتعلم الوكيل أبدًا.

ما يجب أن يتحقق منه خادمك

تحدد المسودة ودليل OpenAI معًا سطح أمن حقيقيًا. الأجزاء غير القابلة للتفاوض:

اطلب حاملًا موثّقًا. يجب استدعاء events/subscribe وevents/unsubscribe مع حامل موثّق؛ والاستدعاءات التي تفشل في التخويل تتلقى -32012 Forbidden.
تحقق من نقطة النهاية قبل أول تسليم حقيقي. HMAC يوقف التزوير لا الإغراق. يجب ألا يبدأ الخادم التسليم إلى رابط استدعاء قبل تأكيد نية نقطة النهاية في استلام التسليمات — تحدٍّ بتوقيع مصادقة، أو قائمة سماح، أو تحقق مسبق خارج النطاق.
نفّذ فحوصات SSRF وقت التسليم. يجب أن تستخدم روابط الاستدعاء HTTPS. حُلّ عنوان الوجهة وتحقق منه عند كل اتصال، واحجب النطاقات الخاصة والمحلية، ولا تتبع عمليات إعادة التوجيه قط، وطبّق ذلك كله على طلبات التحقق كما على التسليمات.
أبقِ الأعباء في حدها الأدنى. تحمل أعباء الأحداث خطر الحقن نفسه الذي تحمله مخرجات الأدوات. تقول مقدمة OpenAI أرسل ملخصًا واكشف أداة قراءة للسجل الكامل، واعتبر النص المكتوبَ من المستخدمين بيانات، ولا تضف تعليمات تخبر النموذج كيف يتصرّف داخل العبء.
اجعل الكتابات مرجعية (idempotent). قد تصل الأحداث بترتيب مضطرب، فلا يجوز للاستدعاءات المتكررة أن تكرّر التغييرات. تُسقّط التسليمات عند 256 KiB، ولا تُعاد المحاولات لاستجابات 410 و413.
خوّل وقت الفعل لا وقت الاستلام. استلام الحدث لا يشكل تخويلًا للتصرف. تمرّ استدعاءات الأدوات التي يجريها الوكيل استجابةً بفحوصاتك المعتادة — الفحوصات ذاتها التي تراقب استدعاءات أدوات MCP بما يتجاوز نطاقات OAuth.

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

ثلاث قرارات لا بد أن تتخذها بنفسك

دورة حياة الاشتراك هي تحديدًا ما عهّد فريق العمل في مثاقه إلى نفسه بتحديده وما لم يقدّم SEP له بعد. وحتى ذلك الحين، ثلاث قرارات تكون لك، والقيم الافتراضية ستقررها قرارًا سيئًا.

أولًا، امنح مدد TTL محدودة قصيرة وارفض ttlMs: null. الـ TTL هو الفاصل الذي يصبح عنده الاشتراك المبطول مرئيًا للعميل. والاشتراك بلا انتهاء منحٌة OAuth لا يستطيع أحد رؤيتها.

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

ثالثًا، احتفظ بفهرس اشتراكات لكل مستخدم. بدونه، إخراج مستخدم يعني افتراض موت اشتراكاته بدل تأكيده. وحين يترك موظف، ليس سؤال الإبطال "هل انتهى رمزه؟" — بل "هل توقّف كل webhook خوّله؟".

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