أحداث MCP في ChatGPT: أنشئ أول أتمتة إضافة تُطلقها الأحداث، خطوة بخطوة

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

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

ما هي أحداث MCP وما الذي يدعمه ChatGPT فعلًا

تُبقي وثائق المطورين لدى OpenAI الوصف موجزًا: يشترك ChatGPT في التحديثات الصادرة عن خادم MCP الخاص بك، مثل الرسائل الجديدة أو تحديثات المحتوى أو تغيّرات الحالة، ويقرر المستخدم ما يحدث بعد ذلك. أما مسودة التصميم المبدئي فطموحها أكبر، إذ تريد أن يشترك عميل MCP في أحداث نظام مصدر، مثل رسالة في Slack أو عملية push في GitHub أو حادثة في PagerDuty، حتى يتمكن الوكيل من الاستجابة دون حضور المستخدم.

أهم حقيقة تصميمية هي ما يستبعده ChatGPT. يدعم ChatGPT التسليم عبر webhook والتحقق من عنوان رد النداء من مسودة مواصفة أحداث MCP. أما الاستطلاع الدوري (polling) والبث (streaming) وإشعارات التحكم gap وterminated الواردة في المسودة، فلا يدعمها هذا التكامل.

تصف شركة Svix، المتخصصة في البنية التحتية لـwebhook، ChatGPT بأنه أول عميل رئيسي يدعم أحداث MCP. وتشير أيضًا إلى أن خادمك يسلّم الأحداث إلى ChatGPT بصيغة Standard Webhooks. ويذكر دليل بناء من طرف ثالث على DEV Community أن دعم ChatGPT بدأ في مؤتمر OpenAI DevDay يوم 29 سبتمبر 2026، بإصدار البروتوكول 2026-07-28. تأكّد من كلا الأمرين في وثائق OpenAI نفسها قبل أن تثبّت أي شيء يعتمد عليهما في الشيفرة.

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

قبل أن تبدأ البناء: واقع حزم SDK وحالة المواصفة

بعد DevDay، أفاد مطوّر على مجتمع مطوري OpenAI بأن حزمة Python SDK الرسمية (mcp 2.2.0) لم تكن تدعم أحداث MCP بعد، وأن حزمة TypeScript SDK لم تكن تدعمها كذلك. ربما تغيّر ذلك، فاقرأ ملاحظات الإصدار الحالية. ومع ذلك، نرى أن تخصص وقتًا لكتابة بعض أجزاء الربط يدويًا.

وضع Go أفضل. إذ تشير مشكلة مفتوحة في Go SDK إلى أن دعمها للأساليب المخصصة يتيح لك بالفعل تنفيذ events/list وevents/subscribe وevents/unsubscribe. أما الناقص فهو طريقة للإعلان عن قدرة events على المستوى الأعلى.

والمواصفة نفسها لا تزال تتحرك. يذكر ميثاق مجموعة العمل أن العملاء يعرفون حاليًا بالتحديثات من جهة الخادم عبر الاستطلاع الدوري أو إبقاء اتصال SSE مفتوحًا، وأن المجموعة تخطط لتحديد آلية رد نداء موحّدة تمكّن الخوادم من دفع الإشعارات بدلًا من ذلك. وفي 2026-10-16 أُعيدت تسمية المجموعة إلى Tasks and Events WG، وتولّت نطاق Tasks من Agents WG. توقّع مزيدًا من المراجعات.

نصيحتنا أن تكتب معالجات مخصصة رفيعة الآن وأن تبقيها معزولة. خصّص لمعالجات أساليب JSON-RPC وحدة مستقلة، وافعل الشيء نفسه لتخزين الاشتراكات وللتوقيع والتسليم. وعندما يصل دعم SDK، تستبدل طبقة ربط البروتوكول وتبقى منطق أعمالك في مكانه.

الخطوة 1 من ASVD (الإعلان): صرّح بالقدرة وعرّف events/list

صرّح بقدرة events

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

صمّم كل نوع حدث لقارئين

نقترح أن تصمّم كل مدخل في events/list حول هذه الأجزاء:

• اسم واضح يظل ثابتًا مع مرور الوقت.
• وصف يصلح للمستخدم وللنموذج معًا. يقرؤه المستخدم أثناء اختيار ما يراقبه، ويقرؤه النموذج أثناء تقرير ما يفعله.
• inputSchema يحدد المرشّحات التي يمكن للمشترك ضبطها.
• payloadSchema يصف بدقة ما ستُرسله.

المثال أدناه توضيحي. تحقق من أسماء الحقول الدقيقة في وثائق OpenAI قبل نسخه.

{
  "name": "ticket.status_changed",
  "description": "A support ticket in a project you can access changed status.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "project_id": { "type": "string" },
      "status": { "type": "string", "enum": ["open", "pending", "closed"] }
    },
    "required": ["project_id"]
  },
  "payloadSchema": {
    "type": "object",
    "properties": {
      "ticket_id": { "type": "string" },
      "new_status": { "type": "string" },
      "summary": { "type": "string" }
    }
  }
}

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

قيّد الأحداث بالمستخدم الموثَّق

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

الخطوة 2 من ASVD (الاشتراك): events/subscribe وevents/unsubscribe متكررا الأمان

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

الاشتراك

خزّن كل اشتراك مع نوع الحدث، والمرشّحات بعد توحيد صيغتها، وعنوان رد النداء، وسر التوقيع، والمالك. ابنِ مفتاحًا حتميًا من المالك ونوع الحدث والمرشّحات الموحّدة وعنوان رد النداء. وعندما يكرر مستخدم مفوَّض الطلب، يحصل على الاشتراك الموجود.

authorize(owner_id, event_name, filters)   // always first, even on repeats
key = hash(owner_id, event_name, canonical_json(filters), callback_url)
if store.exists(key): return store.get(key)
verify_callback(callback_url)              // ASVD Step 3
sub = store.create(key, secret=new_secret(), status="active")
return sub

يُنفَّذ التفويض قبل التحقق من الوجود عن قصد. فلو بدّلت ترتيبهما، لأمكن لمستخدم أُلغي وصوله أن يعيد إرسال استدعاء اشتراك قديم ويستعيد الاشتراك بصمت.

إلغاء الاشتراك

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

الاستمرارية والتفويض

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

وتحتاج أيضًا إلى مسار للتنظيف. تقول وثائق OpenAI إنه لا تُعاد محاولة تسليم يعيد 410. وقراءتنا لذلك أن المستقبِل لم يعد يريد الاشتراك، فضع عليه علامة «متقاعد» بدلًا من تركه يفشل مع كل حدث مستقبلي.

الخطوة 3 من ASVD (التحقق): أكّد عنوان رد النداء بالتحدي الموقَّع

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

إذا فشل التحقق، تقول وثائق OpenAI بإعادة خطأ JSON-RPC رقم ‎-32015 (CallbackEndpointError) مع data.reason مصنَّف، مثل challenge_failed أو timeout.

انتبه للانجراف هنا. تذكر المسودة المبدئية الحالية أن مراجعاتها السابقة استخدمت النطاق من ‎-32011 إلى ‎-32015، وهو نطاق فرعي لا تخصصه المواصفة أبدًا، وأن تطبيقات تلك المراجعات بحاجة إلى إعادة الترقيم. ببساطة، الرمز الوارد في وثائق OpenAI مأخوذ من مراجعة أقدم للمسودة. اتبع وثائق OpenAI حاليًا، لأن ChatGPT هو العميل الذي تبني له، وعرّف الرمز مرة واحدة بوصفه ثابتًا مسمّى حتى يكون أي تغيير مستقبلي تعديلًا في سطر واحد.

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

الخطوة 4 من ASVD (التسليم): وقّع الأحداث وأرسلها بصيغة Standard Webhooks

تتبع عمليات التسليم مواصفة Standard Webhooks. ووفقًا لـSvix، فإن X-MCP-Subscription-Id هو الترويسة الوحيدة الخاصة بـMCP، وهي تخبر المستقبِل بالاشتراك، وبالتالي بالسر، الذي يتحقق به من التوقيع.

الحجم والشكل

تقول وثائق OpenAI بإرسال حدث واحد في كل طلب، بجسم طلب كامل لا يتجاوز 256 KiB (262,144 بايت). ويمكن لـChatGPT تجميع الأحداث المسلَّمة منفصلة في تشغيل مهمة واحد، بناءً على إعدادات التجميع الخاصة بالمهمة. لا تعامل 256 KiB بوصفه هدفًا. توصي Standard Webhooks بإبقاء الحمولات صغيرة، وعادةً أقل من 20 KB. أرسل المعرّفات وملخصًا قصيرًا، ودع ChatGPT يستدعي أدواتك عندما يحتاج إلى السجل الكامل.

إعادة المحاولة وشروط التوقف

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

وتقول وثائق OpenAI أيضًا إنه لا تُعاد محاولة عمليات التسليم التي تعيد 410 أو 413. وعندما يُرفض تسليم بهذه الطريقة، نقترح مراجعة حالة الاشتراك وتصميم الحمولة بدلًا من إرسال الطلب مجددًا.

توصي Standard Webhooks بمهلة طلب من 15 إلى 30 ثانية. اختر رقمك عن قصد بدلًا من وراثة القيمة الافتراضية التي تأتي بها مكتبة HTTP لديك.

استخدم مكتبة رسمية

وقّع باستخدام مكتبة Standard Webhooks رسمية، مثل مكتبة Standard Webhooks لـJavaScript أو المكتبة الرسمية الخاصة بحزمة تقنياتك، بدلًا من كتابة شيفرة HMAC بنفسك. فالمكتبة المبنية وفق المواصفة هي الطريقة الأكثر أمانًا لإنتاج توقيعات يستطيع المستقبِلون التحقق منها.

اختبر قبل الإطلاق: قائمة تحقق ASVD قبل الإصدار

مرّ على هذه القائمة في بيئة التجهيز (staging)، متصلًا باشتراك ChatGPT حقيقي، قبل الإصدار. يختبر كل بند مرحلة واحدة من الحلقة.

تحافظ إعادات المحاولة على معرّف الحدث، وتجدّد التوقيع، وتتوقف عند 410 و413.

• [ ] الإعلان، المرشّحات: لا تُسلَّم أبدًا الأحداث الواقعة خارج مرشّحات الاشتراك. اختبر بأحداث تطابق بعض المرشّحات لا كلها.
• [ ] الاشتراك، التكرارات: يعيد تكرار استدعاء الاشتراك الاشتراكَ الموجود ولا ينشئ شيئًا جديدًا.
• [ ] الاشتراك، إلغاء الاشتراك: بعد إلغاء الاشتراك، لا يُرسَل أي شيء آخر، بما في ذلك إعادات المحاولة المصطفّة بالفعل. ويعيد استدعاء ثانٍ لإلغاء الاشتراك نجاحًا.
• [ ] الاشتراك، إعادة التشغيل: بعد إعادة التشغيل وإعادة النشر، تبقى الاشتراكات والأسرار محفوظة وتُستأنف عمليات التسليم.
• [ ] الاشتراك، التفويض: ألغِ وصول مستخدم إلى مورد مرشَّح. تتوقف عمليات التسليم الخاصة به، ويُرفض استدعاء الاشتراك المكرر.
• [ ] التحقق، تحدي رد النداء: شغّل تحديًا ناجحًا وآخر فاشلًا. يعيد الفشل رمز الخطأ الموثَّق مع data.reason.
• [ ] التسليم، الأحداث المعادة: أعد إرسال معرّف الحدث نفسه ودوّن ما يفعله ChatGPT به. لا تفترض إزالة تكرار لم تلاحظها بنفسك.
• [ ] التسليم، حدود الحجم: تُعالَج الحمولات التي تقل قليلًا عن 256 KiB والتي تزيد عليها قليلًا كلٌّ بالطريقة التي قصدتها.

أخطاء شائعة عند بناء خوادم أحداث MCP

• بناء أوضاع لا يستدعيها أحد. الاستطلاع الدوري والبث وإشعارات gap أو terminated ليست جزءًا من تكامل ChatGPT. ونبضات القلب (heartbeats) تنتمي إلى الفئة نفسها. تقول المسودة إنه ينبغي للخادم إرسال نبضة قلب كل 30 ثانية على الأقل، لكن ذلك ينطبق على البث بوضع الدفع، الذي لا يدعمه ChatGPT.
• عكس منطق إعادة المحاولة. يؤدي استخدام معرّف حدث جديد في كل إعادة محاولة إلى حرمان المستقبِل من مفتاح إزالة التكرار. وإعادة استخدام الطابع الزمني والتوقيع القديمين تستدعي الرفض بسبب القِدم.
• إعادة محاولة الطرق المسدودة. تقول وثائق OpenAI إنه لا تُعاد محاولة عمليات التسليم التي تعيد 410 أو 413. فالجسم نفسه سيُرفض مجددًا.
• إرسال سجلات كاملة. تدفع المستندات الكاملة الحمولات نحو 256 KiB، في حين تقترح Standard Webhooks البقاء دون 20 KB.
• الاحتفاظ بالاشتراكات في الذاكرة. تختفي عند إعادة التشغيل، ولا شيء يحذّرك.
• الثقة بنص الحمولة. عندما يحمل حدثٌ نصًا من إنشاء المستخدم، كرسالة عميل مثلًا، فقد يحتوي ذلك النص على تعليمات موجّهة إلى النموذج. تعامل مع الحمولات بوصفها مدخلات غير موثوقة، تمامًا كما تتعامل مع نتائج الأدوات، وأزل ذلك النص أو حدّد بدايته ونهايته بوضوح.

تحفظات: انجراف المواصفة والقيود التشغيلية

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

شيفرتك المخصصة مؤقتة. دعم SDK غير متكافئ. خطّط لاستبدال المعالجات بمجرد صدور الدعم الرسمي.

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

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