بناء خادم MCP للمطوّرين: تصميم الأدوات، النقل، والأمان من أول سطر

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

الأساسيات بسرعة

الخادم يعلن قدراته للعميل: أدوات (tools) يستدعيها النموذج، وموارد (resources) يقرؤها التطبيق، وقوالب أوامر (prompts). التواصل عبر JSON-RPC. فيه SDKs رسمية بعدة لغات منها TypeScript و Python، تتكفل بتفاصيل البروتوكول وتخليك تركز على المنطق. كل أداة لها اسم، ووصف، ومخطط JSON Schema للمدخلات.

اختيار طريقة النقل

• stdio: الخادم عملية محلية يشغلها العميل على نفس الجهاز. مناسب للأدوات الشخصية وأدوات التطوير، وبسيط في الإعداد.
• HTTP (Streamable HTTP): الخادم خدمة بعيدة يتصل بها عملاء متعددون. مناسب لما تقدم خادمك كخدمة لعملائك، ويحتاج مصادقة وإدارة جلسات.

القرار سهل غالباً: لو الخادم يلمس ملفات جهاز المستخدم، محلي. لو يمثّل منصتك السحابية، بعيد مع مصادقة مثل OAuth.

صمّم الأدوات للنموذج، مو لـ API

الخطأ الأشهر: تحويل كل endpoint في الـ API إلى أداة. النتيجة عشرات الأدوات منخفضة المستوى، والنموذج يحتاج يسلسل خمس استدعاءات لإنجاز مهمة واحدة، ويغلط في الترتيب. الأفضل أدوات مبنية حول المهام:

• بدل get_customer ثم get_orders ثم get_shipments، أداة واحدة: summarize_customer_activity.
• أسماء واضحة الفعل والمفعول، ولا تتشابه بين أداتين.
• وصف يشرح متى تُستخدم الأداة ومتى لا، مو بس وش تسوي.
• مدخلات قليلة، بأنواع محددة وقيم enum حيث أمكن بدل نص حر.
• مخرجات مختصرة ومفيدة للنموذج — لا ترجع سجل قاعدة بيانات كامل فيه خمسين حقلاً.
• دعم التصفح (pagination) والحدود للنتائج الكبيرة بدل إغراق السياق.

الأخطاء كرسائل يفهمها النموذج

لو فشل الاستدعاء، لا ترجع stack trace. ارجع رسالة تساعد النموذج يصلح نفسه: «التاريخ لازم يكون بصيغة YYYY-MM-DD، وصلني 18/9». النموذج غالباً يعيد المحاولة بالشكل الصحيح. وفرّق بين خطأ في المدخلات يقدر النموذج يصلحه، وخطأ في النظام لازم يبلّغ عنه المستخدم.

الأمان: افترض إن المدخلات عدائية

النموذج اللي يستدعي أداتك قد يكون قرأ قبلها بريداً أو صفحة ويب فيها تعليمات مدسوسة. يعني مدخلات أداتك ممكن تكون مصاغة من طرف ثالث. تعامل معها مثل مدخلات مستخدم مجهول تماماً:

• تحقق من كل مدخل على الخادم، ولا تعتمد على المخطط وحده.
• استعلامات مُعلَّمة (parameterized) دائماً، ولا تبني SQL أو أوامر shell بدمج النصوص.
• حصر مسارات الملفات داخل مجلد مسموح، وامنع ../ والروابط الرمزية الخارجة عنه.
• أقل صلاحيات ممكنة: مفتاح قراءة فقط لو الأدوات كلها قراءة.
• علّم الأدوات الخطرة (حذف، دفع، إرسال) عشان يطلب العميل موافقة المستخدم.
• لا تكتب أسراراً في المخرجات أو السجلات.
• في الخوادم البعيدة: مصادقة صحيحة، تحقق من الجمهور المقصود للتوكن، وحدود معدل الطلبات.

الاختبار

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

الإصدارات والتغييرات بعد النشر

بعد ما يستخدم الناس خادمك، أي تغيير في اسم أداة أو مدخلاتها قد يكسر سير عمل بنوه عليه، أو يغيّر سلوك النموذج بطريقة ما توقعتها. تعامل مع الأدوات كواجهة عامة:

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

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

في منصة أزهل الرقمية نبني الأنظمة والتكاملات مع مراعاة الأمان من البداية. لو عندك منصة وتبي تفتحها للذكاء الاصطناعي عبر MCP بشكل آمن، تواصل معنا على واتساب ونراجع معك التصميم قبل البناء.