WebMCP: حين يصبح موقعك الإلكتروني أداةً يفهمها الذكاء الاصطناعي

منذ بدأت الضجة حول وكلاء الذكاء الاصطناعي (AI Agents)، كان هناك سؤال جوهري يؤرّق مطوري الويب: كيف يتفاعل هذا الوكيل مع مواقع الويب فعليا ؟

وكلاء الذكاء الاصطناعي يفهمون صفحات الويب بإحدى طريقتين: إما عبر لقطات الشاشة (Screenshots) حيث يُحلّل نموذج بصري (Vision-Language Model) الصورة ليُخمّن مكان العناصر، أو عبر قراءة DOM مباشرة واستخراج بنية HTML لتحديد الأزرار والحقول وروابط التنقل. كلا الطريقتين هشّتان — يكفي أن تتغيّر أسماء الكلاسات أو يتحرك عنصر حتى يضيع الوكيل تماما 😅

جوجل ومايكروسوفت قرّرتا أن هذا الوضع لا يمكن أن يستمر، فجاءتا بمقترح جديد يُحدث تحولا جذريا في طريقة تعامل الذكاء الاصطناعي مع الويب، وجعل الأخير صديقا لوكلاء الذكاء الإصطناعي أو Agent-friendly.

المقترح الجديد اسمه WebMCP.

ما هو WebMCP ؟

WebMCP أو Web Model Context Protocol هو معيار ويب جديد قيد التطوير تحت مظلة منظمة W3C، ويهدف إلى منح مواقع الويب طريقة رسمية وموحّدة للتعريف بوظائفها للوكلاء الأذكياء مباشرة، عوض ترك هؤلاء يُخمّنون ويجتهدون.

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

الواجهة البرمجية المسؤولة عن هذا كلّه تمرّ عبر:

navigator.modelContext;

طريقتان للتعريف بوظائف موقعك

يُقترح في WebMCP طريقتان تتكاملان:

الأولى: الطريقة التصريحية (Declarative)

إذا كان موقعك يحتوي على نماذج HTML عادية ومُنظَّمة بشكل جيد، فأنت لست بعيدا عن الهدف. يكفي أن تُضيف سمات جديدة لوسوم <form>الخاصة بك كاسم الأداة ووصفها، ليفهمها الوكيل تلقائيا دون أي كود إضافي.

<form
  toolname="checkout"
  tooldescription="Place a food delivery order and complete checkout. Requires a delivery address. Use this tool AFTER items have been added to the cart using the add_to_cart tool. The cart must have at least one item. Returns the full order confirmation including order ID and estimated delivery time."
>
  <!-- Form fields here -->
</form>

الثانية: الطريقة البرمجية (Imperative)

للحالات الأكثر تعقيدا والتي تحتاج لمنطق جافا سكريبت، تستعمل دالة registerTool() لتُسجّل وظيفة كاملة مع مخططها (Schema) ووصفها الطبيعي:

navigator.modelContext.registerTool({
  name: "searchProducts",
  description:
    "يُمكّن الوكيل من البحث عن منتجات بناءً على كلمة مفتاحية وفئة السعر",
  inputSchema: {
    type: "object",
    properties: {
      query: { type: "string" },
      maxPrice: { type: "number" },
    },
    required: ["query"],
  },
  readOnly: true,
  execute: async ({ query, maxPrice }) => {
    // نفس منطق البحث المستخدم أصلا في موقعك
    return await fetchProductsFromDB(query, maxPrice);
  },
});

لاحظ شيئا مهما هنا: لا تكتب كودا جديدا من الصفر. أنت تلفّ المنطق الموجود أصلا في موقعك وتُقدّمه للوكيل في صورة منظّمة.

ما الفرق بينه وبين MCP الخاص بـ Anthropic ؟

سؤال وجيه، لأن التشابه في الاسم قد يُربك 😄

MCP الخاص بـ Anthropic هو بروتوكول خادم-عميل يعمل على مستوى الباكند، يربط الذكاء الاصطناعي بخدمات وأدوات تعمل على الخادم (APIs، قواعد البيانات، إلخ).

WebMCP في المقابل يعمل بالكامل داخل المتصفح من جانب العميل. لا خوادم إضافية، لا بنية تحتية جديدة. الصفحة نفسها هي من تُشغّل الأدوات وتُعيد النتائج.

المقارنة السريعة:

	MCP (Anthropic)	WebMCP
مكان العمل	الخادم (Backend)	المتصفح (Client-side)
متى يُستخدم	لا يوجد مستخدم أمام الشاشة	المستخدم حاضر ويُشارك
الهدف	خدمات وأنظمة	مواقع وتطبيقات ويب

المقترحان مُكمّلان لبعضهما وليسا منافسين، تماما كما يُكمّل كل من REST وWebSockets بعضهما في الاستخدامات المختلفة.

نقطة مهمة: الإنسان لا يزال في قلب المعادلة

من أبرز ما يُميّز WebMCP أنه لم يُصمَّم للأتمتة الكاملة. المعيار ينصّ صراحةً على أن المستخدم يظل حاضرا ومُشاركا في العملية.

هذا يعني عمليا أنه حين يريد الوكيل تنفيذ إجراء حسّاس — كإتمام دفع أو حذف بيانات — يمكنك استدعاء requestUserInteraction()لطلب تأكيد صريح من المستخدم قبل المتابعة. الوكيل يقترح ويُنجز، لكن القرار النهائي يبقى بيد الإنسان.

navigator.modelContext.registerTool({
  name: "pause_campaign",
  description:
    "إيقاف حملة إعلانية قيد التشغيل بواسطة ID. يتطلب تأكيد المستخدم.",
  inputSchema: {
    type: "object",
    properties: {
      campaignId: { type: "string" },
      reason: { type: "string", description: "سبب الإيقاف" },
    },
    required: ["campaignId"],
  },
  readOnly: false, // يغيّر الحالة → المتصفح سيطلب تأكيد المستخدم
  execute: async ({ campaignId, reason }, client) => {
    // WebMCP يسمح بطلب تأكيد المستخدم أثناء تنفيذ الأداة
    const confirmed = await client.requestUserInteraction(async () => {
      return confirm(`إيقاف الحملة ${campaignId}? السبب: ${reason}`);
    });
 
    if (!confirmed)
      return { success: false, reason: "تم إلغاء العملية من قبل المستخدم" };
 
    await api.pauseCampaign(campaignId, reason);
    return { success: true };
  },
});

وهنا مثال بسيط على منصة Github على كيفية الإستعانة بال WebMCP بشكل عملي وما يمكن أن تؤول إليه الأمور في المستقبل القريب في تطبيقات الويب.

https://github.com/Doriandarko/webmcp-starter

مع التنويه بأن الأمثلة الرسمية من W3C أو Google Chrome قد تظهر تباعاً في المستقبل القريب، مع نضج المقترح بشكل أكبر.

هل هو جاهز للإنتاج ؟

WebMCP متاح فقط في Chrome Canary (الإصدار 146) خلف علَم تجريبي (Experimental feature)، والمعيار لا يزال في مرحلة المسوّدة تحت إشراف مجموعة Web Machine Learning Community Group في W3C.

المواصفة قد تتغيّر قبل أن تستقر.

لكن الإشارات واضحة: جوجل ومايكروسوفت يقودان العمل معا، وهذا وحده يُرجّح أنك ستسمع عن WebMCP كثيرا في مؤتمرات Google I/O و Build خلال الأشهر القادمة.

في الختام

WebMCP ليس مجرد واجهة برمجية جديدة تُضاف إلى قائمة طويلة من Web APIs. إنه تحوّل في الطريقة التي نُفكّر بها في مواقع الويب: من صفحات يتصفحها الإنسان، إلى أدوات تستطيع الآلة استدعاءها، فهمها والتعامل معها.

السؤال الذي يطرحه هذا المعيار على كل مطور ويب: عندما يصل وكيل ذكاء اصطناعي إلى موقعك، ماذا ستُقدّم له؟ صورة يُخمّن من خلالها ماذا تفعل؟ أم عقدا واضحا يعرف بموجبه بالضبط ما يستطيع فعله؟

WebMCP يُريد أن يجعل الخيار الثاني هو المعيار الجديد للويب.

بما أن المعيار لا يزال في مرحلة المسودة (Draft)، يُنصح بمتابعة مستودع W3C Web Machine Learning CG الرسمي لأي تغييرات في أسماء الدوال.