أضافت Cloudflare مفتاح تبديل (toggle) جديدًا إلى لوحة التحكم الخاصة بها يقوم بحقن جسر WebMCP في صفحات أي موقع، مما يتيح لوكلاء الذكاء الاصطناعي (AI agents) اكتشاف واستدعاء الأدوات التي يوفرها الموقع دون المساس بكود الخادم الأصلي (origin server). وتزيل هذه الخطوة الخطوة الأكثر استهلاكًا للجهد في جعل الموقع الإلكتروني "جاهزًا للوكلاء" (agent-ready)، ولكن لا يزال يتعين على المطورين تحديد الأدوات المفيدة ومراقبة استخدامها.

لماذا يهم مفتاح التبديل عند الحافة (edge)

WebMCP هو API يُستخدم لتسجيل الأدوات. وحتى الآن، كان إدراج موقع ما في هذا البروتوكول يتطلب إدراج نص برمجي (script) للجسر يدويًا في كل صفحة. يقوم مفتاح Cloudflare الجديد "Browser Run → Agent Readiness" بأتمتة عملية الحقن هذه عند الحافة (edge)، حيث يتم إضافة النص البرمجي أثناء خروج HTML من شبكة Cloudflare ووصوله إلى متصفح الزائر.

الفائدة واضحة: يمكن الآن لأي موقع ثابت (static site) مستضاف في أي مكان عرض محتواه لوكلاء الذكاء الاصطناعي بنقرة واحدة. دون الحاجة لإجراء تغييرات على الخادم الأصلي، ودون الحاجة لإعادة بناء الواجهة الأمامية (front-end).

ما تفعله هذه الميزة فعليًا

عند تفعيل مفتاح التبديل، يحدث أمران:

  • الحقن عند الحافة (Edge injection) – تقوم Cloudflare بإلحاق حمولة JavaScript صغيرة بملفات HTML الصادرة. وهي تعمل مع كل من الصفحات الثابتة التقليدية وتطبيقات الصفحة الواحدة (SPAs) الحديثة التي تعتمد على التوجيه من جانب العميل (client-side routing).
  • جسر المتصفح (Browser bridge) – يعمل النص البرمجي في متصفح المستخدم ويسجل الموقع في WebMCP API، معلنًا عن الأدوات التي يمكنه توفيرها.

توفر Cloudflare هذه النسخة التجريبية مع حزمتين من الأدوات الجاهزة:

  1. Content Credentials – تكشف عن البيانات الوصفية (metadata) الخاصة بـ C2PA (Coalition for Content Provenance and Authenticity) المرفقة بملفات الوسائط، مما يسمح للوكلاء بالتحقق من المصدر.
  2. Site MCP Server – يعمل كوكيل (proxy) يقوم بتوجيه استدعاءات الأدوات إلى خادم MCP تقوم بتشغيله بالفعل في الخلفية.

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

ما يقع لا يزال على عاتق المطور

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

  • يجب أن يكون خادم MCP قيد التشغيل في مكان يمكن للوكيل (proxy) الوصول إليه.
  • يجب على المطور تسجيل كل أداة عبر document.modelContext API، مع تحديد اسم الأداة، ومخطط الإدخال (input schema)، وتنسيق المخرجات المتوقع.

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

تعد قابلية المراقبة (Observability) قطعة أخرى مفقودة. فالإصدار الحالي لا يوفر سجلات (logs) توضح أي الوكلاء استدعوا أي الأدوات أو أين فشلت الاستدعاءات. يجب على الفرق تطوير أدوات القياس الخاصة بها — مثل التقاط معرفات الطلبات (request IDs)، وأوقات الاستجابة، وأكواد الخطأ — للتحقق من أن الجسر وخادم MCP الأساسي يعملان كما هو مخطط لهما.

من المستفيد، ومن يجب عليه التحرك

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

الخلاصة

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