خادم MCP البعيد قيد العمل: نقطة دخول جديدة لمنتجات SaaS في عصر الذكاء الاصطناعي

منتجات SaaS تعاني من مشكلة قديمة: الوقت المطلوب لتحقيق القيمة بطيء جدًا. كثير من المستخدمين يغادرون قبل أن يصلوا إلى لحظة “آها”.

لقد كررنا عملية الإعداد في Logto عدة مرات. ساعد ذلك، لكن عنق الزجاجة لم يختفِ. ما زلت في النهاية تقرأ المستندات، تتصفح الشروحات، تثبت حزم SDK، تضبط الإعدادات، تكتب الكود، ثم تقوم بإصلاح آخر 10٪ قبل أن يعمل أي شيء.

لذا جربنا نهجًا مختلفًا: خادم MCP بعيد كمنصة تحكم أصلية في البيئة التطويرية الخاصة بـ Logto. بدلاً من التنقل في لوحة الإدارة، تقوم بتكوين Logto وتوليد كود التكامل عبر محادثة، مباشرة في المكان الذي تبني فيه التطبيق.

سطر طلب واحد يمكن أن يأخذك من الصفر إلى تكامل يعمل. الوكيل لا يقوم فقط بتوليد الكود، بل ينشئ ويكوّن تطبيق Logto في مستأجرك. كل ذلك من داخل بيئة التطوير الخاصة بك. (جرب خادم Logto MCP)

في هذه المقالة، سأشارك تجربتنا وأفكارنا حول بناء خادم Logto MCP، بما في ذلك:

• MCP مقابل مهارات الوكيل: لماذا اخترنا MCP
• المشاكل التي واجهتنا عند إطلاق خادم MCP وكيف حللناها
• كيف نصمم أدوات MCP، وكيف يجب أن تصمم أدواتك
• توقعاتنا لمستقبل MCP

MCP مقابل مهارات الوكيل: لماذا اخترنا MCP#

قبل اتخاذ قرار حول كيفية وصول الذكاء الاصطناعي إلى Logto، قيّمنا خيارين: خوادم MCP ومهارات الوكيل.

خوادم MCP لها شكلان: محلي وبعيد.

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

الخادم البعيد مستضاف على جهة الخادم. يتصل المستخدمون عبر رابط URL ويقومون بالتفويض باستخدام OAuth. هذا النموذج أقرب إلى توسيع خدمة SaaS.

من حيث البنية، مهارة الوكيل هي مزيج من "المنطق التجاري + الإمكانيات الأساسية". هذه الإمكانيات يمكن أن تكون أدوات، أو أدوات سطر أوامر (CLI)، أو استدعاءات API. يمكن لأدوات MCP حمل هذه الطبقة بطريقة موحدة.

إذاً السؤال الرئيسي ليس كيف تم تنفيذ الإمكانيات، بل كيف تم تسليمها للمستخدمين.

• مهارات الوكيل تسلم: سلسلة أدوات كاملة محليًا (حزمة مهارة + بيئة تشغيل محلية + مفاتيح API أو بيانات منصة + أدوات CLI + التثبيت، التكوين، التحديث، وصيانة العمليات).
  في الجوهر، تعطي الإمكانية للمستخدمين ليشغلوها بأنفسهم.

• خوادم MCP البعيدة تسلم: نقطة دخول خدمة عن بعد (رابط + تسجيل دخول OAuth).
  الجوهر هنا هو تقديم الإمكانية كخدمة.

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

تجربة المستخدم#

مهارات الوكيل عادة تعتمد على APIs أو CLIs للمنصة. يجب على المستخدمين إنشاء مفاتيح API أو تثبيت وتسجيل الدخول إلى CLIs. هذه الخطوات ليست معقدة، لكنها ترفع حاجز الدخول.

خوادم MCP تدعم OAuth. يسجل المستخدمون الدخول بحساب SaaS الخاص بهم. التجربة مشابهة لـ "تسجيل الدخول باستخدام Google".

بالنسبة للمستخدمين، استخدام خادم MCP بسيط: أدخل رابطًا، سجل الدخول، اتصل. هذه هي التجربة التي نريد تقديمها.

مدى الوصول في النظام البيئي#

على موقع MCP، هناك بالفعل 104 تطبيق ذكاء اصطناعي تدعم MCP، بما في ذلك أدوات مثل VS Code، Cursor وWindsurf.

مهارات الوكيل لا تزال متخصصة بحسب المنصة. حتى وإن بدأت منصات متعددة دعمها، عند إطلاق خادم MCP يمكن للمستخدمين استعماله مباشرة. لكن عند إطلاق مهارة، فقط مستخدمي تلك المنصة يمكنهم استخدامها.

MCP مدرج أيضًا من قبل مؤسسة الذكاء الاصطناعي العميق (AAIF). إنه معيار على مستوى البروتوكول. النظام البيئي سيواصل النمو. بالنسبة لنا، هذا يجعل الاستثمار في MCP طويل الأمد.

تكاليف التسليم والصيانة#

مهارات الوكيل تعتمد على APIs أو CLIs للمنصة، وهذا يجلب مشاكل بسرعة:

• ماذا لو تغيرت الـ API؟
• ماذا لو تعطلت CLI التوافقية مع القديم؟
• كيف تقوم بالتحديث وتوزيع المهارة من جديد؟

عليك أيضًا توزيع CLIs، إدارة بيانات اعتماد متفرقة، التكيّف مع منصات متعددة، وإرشاد المستخدمين للتحديث. العائد الاستثماري هنا منخفض جدًا.

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

معظم منتجات SaaS لديها بنية تحتية قوية: APIs متينة وأنظمة مصادقة ناضجة. خادم MCP يتناسب طبيعيًا كـ "واجهة ذكاء اصطناعي" للـ API، مثلما أن لوحة الإدارة هي واجهة أخرى مبنية على نفس الـ APIs.

بالنسبة لـ Logto، اختيار خادم MCP يتناسب مع بنيتنا المعمارية ويستغل نقاط قوتنا.

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

المشاكل التي واجهتنا عند إطلاق خادم MCP وكيف حللناها#

MCP ليس مثاليًا. معظم المشاكل بسبب نضج النظام البيئي. ستتحسن الأمور مع الوقت. حتى يحدث ذلك، نستعمل حلولاً مؤقتة لتلبية الاحتياجات الفعلية.

دعم ميزات MCP المتجزئ#

مواصفة MCP تحدد العديد من الميزات، لكن دعم العملاء يختلف:

• الأدوات: مدعومة على نطاق واسع
• OAuth: مدعومة جيدًا في VS Code؛ أدوات مثل Cursor تحتاج mcp-remote كجسر
• ميزات أخرى (الموارد، التعليمات، الإرشادات): دعم غير متسق

حاليًا، الأدوات هي الطبقة الأكثر موثوقية (راجع صفحة مجتمع MCP لمعرفة ميزات كل عميل).

استراتيجيتنا بسيطة: البناء على الأدوات.

الـ LLM لا يعرف كيف يستخدم أدواتك#

هذه مشكلة في طبقة الأعمال.

في مهارات الوكيل، المنطق التجاري والسياق معبئين سويًا. الـ LLM يعرف كيف يستخدمها. أما في MCP توفر أدوات فقط. بعد الاتصال، الـ LLM لا يعرف:

• سيناريوهات الاستخدام
• ترتيب الاستدعاء
• القيود التجارية

MCP لديه مفهوم الإرشادات، لكن ليس كل العملاء يدعمونها. أيضًا، الإرشادات تدخل كل المحتوى في السياق عند الاتصال، مما يستهلك الرموز.

هناك فكرة لوضع الإرشاد في أوصاف الأدوات. لكن هذا يسبب مشكلتين:

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

حلنا المؤقت: توفير أداة getInstructions

الفكرة بسيطة: إذا لم يتم دعم الإرشادات جيدًا، حولها إلى أدوات.

يمكن للـ LLM استدعاء getInstructions عند الحاجة.
لمهمة A، يستدعي getTaskAInstructions. يُرجع خادم MCP رسالة إرشاد تشرح كيفية إتمام مهمة A وكيفية دمج الأدوات الأخرى.

المنطق التجاري المعقد يبقى خلف أدوات الإرشاد. الأدوات الأخرى تظل بسيطة. أوصاف الأدوات تركز فقط على وظيفتها.

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

الـ LLM قد يسرب أسرارك#

بالنسبة للعديد من منتجات SaaS، هناك أسرار يجب ألا تكشف أبدًا (مثل أسرار العميل أو مفاتيح الـ API أو مفاتيح التوقيع على Webhook). إن تسربت، يمكن للآخرين انتحال هويتك أو الوصول مباشرة للموارد.

المخاطر مع نماذج الذكاء أن الدردشة ليست قناة آمنة. يمكن تسجيل، نسخ، إعادة توجيه المحادثة، أو تظهر في سجلات تصحيح الأخطاء. لا يمكنك الافتراض أن "أنا والنموذج فقط من يمكنهم رؤية هذا". لذا إعطاء سر طويل الأجل للـ LLM أو طلب إخراجه للمستخدمين لنسخه مخاطرة كبيرة.

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

لجعل الإعداد سهلاً بدون المساس بأمان الأسرار، نقوم بثلاثة أشياء:

• استخدام أسرار مؤقتة أثناء التكامل

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

• جعل حدود الأمان واضحة

  نحذر المستخدمين بوضوح: لا تقم بإنشاء أو لصق أو تخزين أسرار الإنتاج في الدردشة. كما نذكر المطورين بأن حتى متغيرات البيئة أو ملفات التكوين يمكن أن تتسرب إذا كان بإمكان وكيل / LLM قراءتها عبر أدوات أو وصول غير مباشر. ضع أسرار الإنتاج فقط في بيئة لا يستخدم فيها التكامل المساعد بالذكاء الاصطناعي.

• عدم التعامل مع أسرار الإنتاج في الدردشة؛ إرشاد المستخدم للوحة التحكم

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

كيف نصمم أدوات MCP#

مسارنا#

يمتلك Logto واجهة برمجة إدارة كاملة. فكرتنا الأولى كانت بسيطة: إتاحة كل نقطة نهاية في الـ API كأداة MCP.

فشل ذلك بسرعة.

أولاً، انفجار السياق. لدى Logto العديد من الـ APIs. ربطها واحدًا بواحد يملأ نافذة السياق. كل وصف أداة يكلف رموزًا.

ثانيًا، فقدان المعنى. الـ APIs وحدات بناء ذرية للمطورين. لكن مستخدمي خادم Logto MCP لا يبنون أنظمة. هم فقط يريدون إكمال مهمة. لا يهتمون بعدد الـ APIs الموجودة.

مثال: لدى Logto API باسم sign-in-experience للعلامة التجارية وطرق الدخول والتسجيل وسياسات الأمان.
في البداية، فكرنا في كيفية عرض جميع المعلمات على الـ LLM. كيف نعلمه دمج الاستدعاءات.

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

لذا يجب أن تكون الأدوات هي updateBranding، updateSignInMethod، updateSignUpMethod. يقوم خادم MCP بتجميع الاستدعاءات داخليًا.

يجب معاملة خادم Logto MCP كمنتج، لا مجرد غلاف API. هو "لوحة إدارة أخرى".

كيف تصمم أدوات MCP#

القاعدة واضحة:

• إذا كان المستخدمون يخدمون نفسك (مثل لوحة إدارة)، اصنع أدوات تركز على الأعمال.
• إذا كنت توفر إمكانيات أساسية ليبني عليها الآخرون، اجعل الأدوات ذرية وبسيطة. مثال: خادم نظام ملفات MCP مع read_file، write_file، ثم يقوم الوكلاء البرمجيون بدمجها.

مبادئ إضافية:

• حافظ على منطق ووصف الأدوات بسيطًا للحفاظ على السياق.
• لسير العمل المعقدة، استخدم أدوات getInstructions للتحميل الإرشادي عند الطلب. وابقِ أوصافها بسيطة أيضًا.

توقعاتنا لمستقبل MCP#

أثناء بناء خادم MCP، فكرنا أيضًا فيما يمكن أن يحسن النظام البيئي.

تسليم الإمكانيات على مستوى المهارة#

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

هذا أمر شائع في SaaS. على سبيل المثال، خادم GitHub MCP، خادم Logto MCP، أو منصات التحليلات. المستخدمون يريدون سير عمل لا استدعاءات ذرية.

أداة getInstructions هي حل مؤقت. الدعم على مستوى البروتوكول سيكون أفضل.

تفعيل MCP على مستوى الجلسة#

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

عزل السياق لاستدعاءات أدوات MCP#

استدعاءات الأدوات تستهلك كثير من السياق. إذا تمت معالجة تفاعلات MCP بواسطة وكلاء فرعيين، يمكن للمحادثة الرئيسية تلقي النتائج المكثفة فقط.

خاتمة#

هذه تجربتنا في بناء خادم MCP بعيد.

إذا كنت تستكشف هذا الاتجاه، جرّب خادم Logto MCP أو انضم إلى Discord لتبادل الخبرات العملية مع المجتمع.

سنشارك أيضًا تفاصيل تصميم البنية وتفاصيل تدفق OAuth في مقالات لاحقة.