12 خادمًا، بروتوكول واحد: كيف غيّر MCP طريقة تدريسي

بدأ كل شيء بمشكلة: كنت جالسًا أمام Moodle مساء الأحد، أنقر عبر القوائم. إنشاء مقرر. إضافة قسم. إعداد اختبار. إدخال أسئلة. مقرر واحد كان يستغرق ساعات. خمسة صفوف تأخذ نصف يوم الأحد.

في لحظة ما فكّرت: لا بد أن هناك طريقة أفضل.

خادم واحد، مشكلة واحدة

كان أول خادم MCP بسيطًا. خدمة Node.js صغيرة تتواصل مع واجهة برمجة خدمات الويب في Moodle. ثلاث نقاط اتصال: إنشاء مقرر، إنشاء اختبار، إضافة أسئلة. خلف Traefik كوكيل عكسي، وLet's Encrypt لـ HTTPS، وانتهى الأمر.

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

من 3 إلى 73 أداة

اليوم يمتلك خادم Moodle-MCP وحده 73 أداة. مقررات، أقسام، اختبارات، أنشطة H5P، تسجيلات، درجات، تقييمات، تسميات، صفحات، روابط، موارد، مجلدات — كلها عبر API. بالإضافة إلى العمليات الجماعية: moodle_bulk_add_questions ينشئ أي عدد من الأسئلة في استدعاء واحد. وmoodle_import_gift يستورد تنسيق GIFT الخاص بـ Moodle مباشرة.

لكن خادم Moodle كان مجرد البداية.

المنظومة

اثنا عشر خادمًا. أكثر من مئة أداة. بروتوكول واحد.

كل خادم هو حاوية Docker مستقلة. كل واحد يتحدث MCP — بروتوكول سياق النموذج. كل واحد يمكن نشره بشكل مستقل، وتوسيعه بشكل مستقل، واستبداله بشكل مستقل.

فلسفة البنية: خوادم صغيرة مستقلة كثيرة

لماذا لا نستخدم خادمًا واحدًا كبيرًا يحوي كل شيء؟ لأن الخوادم الصغيرة أفضل. من كل النواحي.

تحمّل الأعطال. إذا تعطل خادم الصوت، يستمر Moodle في العمل. إذا احتاج SharePoint لتحديث، يعمل الباقي بشكل طبيعي.

سرعة التطوير. يمكنني إعادة كتابة خادم IMAP في ساعة واحدة دون لمس أي شيء آخر.

البساطة. لكل خادم مهمة واحدة. خادم Moodle يتحدث مع Moodle. خادم Teams يتحدث مع Teams. لا يحتاج أي خادم لمعرفة ما يفعله الآخرون.

هذا ليس صدفة. إنه مبدأ الستيغمرجي — المبدأ الذي يعمل به النمل. لا يوجد منسق مركزي. كل فاعل يستجيب لبيئته ويترك آثارًا يبني عليها الآخرون.

سير عمل مساء الأحد

هكذا يبدو الأمر عمليًا. مساء الأحد، الساعة 8 مساءً. غدًا تبدأ وحدة تعليمية جديدة حول "عمليات الشراء في تجارة الجملة".

في السابق كنت سأقضي ثلاث ساعات أمام Moodle. اليوم:

1. أصف الوحدة التعليمية بلغة طبيعية
2. يُنشئ Claude قسم المقرر في Moodle عبر Moodle-MCP
3. تُولَّد أسئلة الاختبار وتُستورَد — 71 سؤالًا في أقل من دقيقة
4. تُنشأ أنشطة H5P وتُرفَع — خط أنابيب H5P
5. يُنسَّق كل شيء كورقة عمل بالتصميم المؤسسي لمدرستي
6. يُرسَل ملخص قصير إلى قسمي عبر IMAP-MCP

الساعة 8:45 مساءً. انتهى. ليس "المسودة جاهزة". كل شيء مباشر في Moodle.

بقية المساء لي. أو أستخدمه لبناء خادم MCP التالي.

مبدأ الستيغمرجي

ما يميّز هذا النظام عن هندسة البرمجيات التقليدية هو المبدأ الكامن وراءه. في الأنظمة التقليدية يوجد منسق مركزي — مُنسِّق يحدد من يفعل ماذا ومتى.

في نظامي لا يوجد ذلك. كل خادم موجود بذاته. يقدم أدوات. ينتظر الطلبات. لا يعرف شيئًا عن الآخرين.

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

هذا هو مبدأ الستيغمرجي. البيئة — الخوادم المتاحة — تُشكِّل السلوك. ليس خطة. ليس هيكلًا تنظيميًا. الأدوات نفسها.

ما تعلمته

سنة مع خوادم MCP علمتني بعض الأشياء:

الأتمتة ليست رفاهية. إنها واجب أخلاقي. كل ساعة أقضيها في النقر عبر Moodle هي ساعة لا أملكها لطلابي.

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

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

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

ما التالي؟

المزيد من الخوادم. المزيد من الأدوات. المزيد من الأتمتة. الخطوة التالية هي خادم MCP لإدارة Microsoft 365 — إدارة المستخدمين، تعيين التراخيص، كل ما يحتاج مسؤول تكنولوجيا المعلومات في المدرسة للقيام به.

وفي يوم ما، عندما تصبح المنظومة كبيرة بما يكفي، ربما لن تحتاجني بعد الآن.

لكن حتى ذلك الحين، سأكون جالسًا أمام الحاسوب مساء كل أحد. لم أعد أنقر عبر قوائم Moodle. بل لأبني الخادم التالي.