DearAgent: خادم MCP يمنح وكلاء الذكاء الاصطناعي بريداً إلكترونياً مستضافاً ذاتياً

DearAgent هو واجهة برمجية للبريد الإلكتروني لوكلاء الذكاء الاصطناعي تُستضاف ذاتياً على Cloudflare Workers، حيث تُخزَّن الرسائل في D1 والمرفقات في R2، ويتم تسويقه كبديل مفتوح المصدر لـ AgentMail، كما يوفّر خادم MCP عديم الحالة بنمط Streamable HTTP عبر نقطة النهاية /mcp على الـ Worker.

لمن هذا مناسب؟

• مناسب للمطورين الذين يريدون منح وكلاء الذكاء الاصطناعي قدرة حقيقية على استلام البريد: فالتدفق النموذجي هو إنشاء صندوق وارد، وانتظار رسالة التحقق، ثم قراءة رابط التحقق.
• المتطلبات واضحة: تحتاج إلى حساب Cloudflare، ونطاق مستوى أعلى مخصص لخدمة Cloudflare Email Routing، وNode 20+ مع تنفيذ npx wrangler login. الاستلام مجاني؛ ولا تحتاج إلى Workers Paid إلا لإرسال الرسائل.
• تستخدم كل من واجهة API وMCP مفتاح API_KEY نفسه كرمز bearer وحيد، أي أن مفتاحاً واحداً يمنح كامل الصلاحيات (مستأجر واحد)، وهو ما لا يناسب السيناريوهات متعددة المستخدمين التي تتطلب عزلاً دقيقاً للصلاحيات.
• الحالات غير المناسبة: من لا يملك نطاقاً خاصاً به، أو لا يستطيع تحمّل مسؤولية النشر الذاتي وصيانته، أو يحتاج إلى عزل صلاحيات متعدد المستأجرين. الجوانب التي لم توضّحها الأدلة الرسمية (مثل سياسات الاحتفاظ بالبيانات والحذف) تبقى مجهولة، فيجب التحقق منها بنفسك.

أول تجربة خلال 3 دقائق

المسار الرئيسي الوحيد الموصى به رسمياً هو استنساخ المستودع ثم تشغيل سكربت التثبيت التفاعلي، الذي يهيّئ تلقائياً D1 وR2 والمفاتيح وEmail Routing/Sending، وينشر المشروع وينشئ قاعدة catch-all:

git clone https://github.com/panda-sandeep/dearagent && cd dearagent
npm install
npm run setup

المتطلبات المسبقة: تسجيل الدخول إلى Cloudflare عبر npx wrangler login، وأن يكون النطاق جاهزاً للاستخدام مع Email Routing. يرشدك السكربت إلى تعيين مفتاح API_KEY الإلزامي (يمكن أيضاً تعيينه عبر npx wrangler secret put API_KEY)، وهو رمز bearer الوحيد لكل من API وMCP.

يُنصح في الاستدعاء الأول باستخدام أداة القراءة منخفضة المخاطر list_inboxes: بعد تهيئة عميل MCP ليشير إلى نقطة النهاية /mcp على الـ Worker مع تضمين مفتاح bearer، استدعِ list_inboxes. إذا أرجعت قائمة بالصناديق الواردة فهذا يعني نجاح النشر والمصادقة. تذكّر أن هذه خدمة مستضافة ذاتياً، وليست كتابةً عبر طرف ثالث مستضاف عن بُعد؛ فـ create_inbox تكتب في قاعدة بيانات D1 الخاصة بك.

إذا كنت تريد الاستلام فقط، فلن تحتاج إلى Workers Paid؛ أما إذا كنت تنوي استدعاء send_message لإرسال الرسائل، فتأكد من تفعيل Workers Paid، لأن الإرسال ينتج رسائل صادرة حقيقية (لا يمكن التراجع عنها على مستوى MCP، ويجب تقييمها وفق السلوك الفعلي لخدمة Email Sending).

حالات الاستخدام

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

الحالة الثانية: استرجاع الرسائل السابقة. استدعِ search_messages للبحث بالكلمات المفتاحية، أو استخدم list_threads / get_thread لعرض المحادثات، وget_message لقراءة رسالة معينة، وget_attachment لتنزيل المرفقات. كلها عمليات استعلام تقرأ البيانات الموجودة في D1/R2 لديك، وهي مناسبة لتتبع الرسائل التي استلمها الوكيل سابقاً.

أما بقية الأدوات (مثل send_message وreply_to_message وforward_message وlist_webhooks وcreate_webhook) فقد ذُكرت في الأدلة كأدوات متاحة، لكن تفاصيل معاملاتها لم تُقدَّم، فارجع إلى ملف README في المستودع قبل استخدامها.

حدود الاستخدام

• طبيعة القراءة والكتابة: list_* وget_* وsearch_messages وwait_for_message من عمليات الاستعلام؛ بينما create_inbox وcreate_webhook وsend_message وreply_to_message وforward_message تكتب بيانات أو تُنتج إجراءات صادرة حقيقية، فتأكد قبل استدعائها.
• بيانات الاعتماد والبيانات: مفتاح API_KEY واحد يمنح وصولاً كاملاً، فاحفظه جيداً؛ وجميع بيانات البريد تُخزَّن في Cloudflare D1/R2 الخاصة بك.
• الآثار الجانبية: الإرسال يتطلب Workers Paid ويتم فعلياً؛ ولم تشرح الجهة الرسمية إلى آلية للتراجع بعد الإرسال، فلا يجب اعتباره عملية قابلة للإلغاء.
• نقاط مجهولة: لم توضّح الأدلة الرسمية مدة الاحتفاظ بالرسائل أو أدوات الحذف أو تفاصيل معالجة الخصوصية؛ فهذه المعلومات غير مؤكدة ولا تشكّل دليلاً على خلوّ الاستخدام من المخاطر.