أطلقت WebAsk خادم MCP للاستبيانات واكتشفت أن AI يقرأ أكثر مما ينشئ

قامت WebAsk بربط منشئ الاستطلاعات والاختبارات الخاص بها بـ MCP حتى يتمكن Claude و Cursor والعملاء LLM الآخرون من العمل مع الخدمة دون تبديل علامات التبويب في المتصفح. بعد الإطلاق، اكتشفت الفريق أن الطلب الرئيسي لم يأتِ من توليد استبيانات جديدة، بل من قراءة وتحليل وتصدير الإجابات المجمعة بالفعل.

لماذا تحتاج WebAsk إلى MCP

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

• نشر وتستضيف استطلاع لآلاف المجيبين
• تجميع الإجابات بدون خسارة وتخزين البيانات
• التحليلات مثل NPS والتقسيم والخرائط الحرارية
• تصدير النتائج إلى CSV و Excel و PDF و Word
• التكامل مع الأنظمة الخارجية والخطافات الويب

كيف تم بناء الخادم

بنى الفريق خادم MCP كطبقة Node.js رقيقة بين عملاء مثل Claude و Cursor والخادم الرئيسي لـ WebAsk. من الخارج، إنه JSON-RPC 2.

0 مع التفويض عبر رمز Bearer؛ من الداخل، إنه موجه وأنماط التحقق ومعالج منفصل لكل أداة. تبين أن البنية بسيطة وسهلة: يأتي الطلب باسم الأداة، يتم التحقق من المعاملات مقابل النمط، ثم يستدعي الخادم طريقة REST API المقابلة ويعود بالاستجابة إلى النموذج. تبين أن المشكلة العملية الرئيسية لم تكن في الكود، بل في التوافق بين العملاء.

وفقاً للمواصفات، يمكن لـ MCP العمل مع tools و resources و prompts، لكن في Claude Desktop رأى الفريق الدعم فقط لـ tools. لذا قام WebAsk بتغليف 19 مورد—مثل قراءة الإجابات وهيكل الاستطلاع والملخصات—في أدوات wrapper منفصلة. كنتيجة لذلك، نما الخادم إلى حوالي 60 أداة، مقسمة إلى مجموعات: دورة حياة الاستطلاع والمحتوى والتنسيق والتحليلات والتصدير وأكواس الترويج.

أين كانت العقبات

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

"توفير الأموال على الأوصاف هو توفير كاذب."

في الوقت نفسه، كان عليهم إعادة النظر في الحدود والنهج نفسه للاختبار. إذا كان الشخص بخير مع 60 طلباً في الدقيقة، فإن الوكيل يقوم بسهولة بـ 50-70 استدعاء في بضع ثوان، لذا استقرت WebAsk على عتبة 180 طلب في الدقيقة. وأصبح الاختبار بمثابة تشغيل يدوي لحوالي 20 سيناريو: يمكن للنموذج تغيير ترتيب الإجراءات وإضافة شاشة ترحيب أو مظهر التنسيق من تلقاء نفسه وإظهار مبادرة مفرطة. في الممارسة العملية، أصبحت الحالة الأكثر شيوعاً ليست المنشئ، بل التحليلات: يقرأ Cursor مئات الإجابات النصية، ويجمعها حسب الموضوع، ويجهز ملخصاً للتقرير أسرع مما يستطيع الشخص فتح لوحة التحكم الصحيحة.

ماذا يعني هذا

تظهر قصة WebAsk بوضوح أن MCP للبرمجيات كخدمة لم تعد لعبة للعروض التوضيحية، بل واجهة جديدة فوق منتج موجود. لكن الفائز ليس من فتح الوصول إلى API لـ LLMs ببساطة، بل من فكر بعمق في أوصاف الأدوات وقيود العملاء وسير عمل المستخدمين الفعليين حيث توفر الذكاء الاصطناعي ليس النقرات، بل ساعات من العمل اليدوي.