WebMCP: اجعل موقعك جاهزًا لوكلاء الذكاء الاصطناعي في المتصفح

ظلّ وكلاء الذكاء الاصطناعي لسنوات يتفاعلون مع المواقع بالطريقة الأصعب: عبر قراءة الصفحة المعروضة، وتخمين مواقع الأزرار، والنقر عبر الـ DOM مثل إنسان حائر. إنها طريقة بطيئة وهشّة وتنهار في اللحظة التي تطلق فيها تصميمًا جديدًا. في مؤتمر Google I/O 2026 يوم 19 مايو، اقترحت Google وMicrosoft حلًّا يقلب النموذج رأسًا على عقب: بدلًا من أن يكشط الوكلاء موقعك، يُخبر موقعك الوكيلَ بالضبط بما يمكنه فعله.

هذا الاقتراح هو WebMCP — أي Web Model Context Protocol — وقد يصبح أساسيًا للويب الوكيلي بقدر ما كان عنصر <form> أساسيًا للويب التفاعلي.

ما هو WebMCP؟

إن WebMCP هو معيار ويب مفتوح مقترح يتيح للموقع كشف أدوات منظَّمة — دوال JavaScript ونماذج HTML — مباشرةً لوكلاء الذكاء الاصطناعي العاملين داخل المتصفح. فبدلًا من أن يقوم الوكيل بهندسة عكسية لواجهتك، تنشر صفحتك قائمة إجراءات قابلة للقراءة آليًا: "أضف إلى السلة"، "ابحث في الطلبات"، "احجز طاولة"، ولكل منها اسم ووصف ومخطط JSON Schema لمدخلاته.

يجري تطوير المعيار عبر مجموعة W3C Web Machine Learning Community Group، مع مشاركة Google وMicrosoft في تأليف المواصفة. وقد ظهرت معاينة مبكرة في Chrome 146 في فبراير 2026، وأصبح origin trial لـ Chrome 149 متاحًا الآن للمطورين المسجَّلين. وتشير مشاركة Microsoft إلى دعم Edge، بينما يُتوقع أن تقوم Safari وFirefox بتقييم الاقتراح.

وإن كنت قد تابعت صعود بروتوكول سياق النموذج (MCP)، فاعتبر WebMCP بمثابة شقيق MCP الأصيل في المتصفح.

كيف يختلف عن MCP الخادمي

يربط MCP القياسي الوكلاءَ بخوادم خلفية عبر JSON-RPC، ويعمل عادةً خارج المتصفح. أما WebMCP فيُبقي كل شيء داخل تبويب المتصفح. وهذا الفارق المعماري الوحيد يحلّ بعضًا من أعقد المشكلات في أتمتة الوكلاء:

ولأن الأدوات تُنفَّذ داخل الصفحة نفسها، فإنها تشارك أي جلسة يملكها المستخدم بالفعل. لا يوجد تسجيل دخول ثانٍ، ولا مفتاح API يجب توفيره، ولا نظام صلاحيات موازٍ. فإذا كان المستخدم مسجَّل الدخول، يتصرف الوكيل ضمن تلك الجلسة نفسها — وضمنها فقط.

واجهة برمجة التطبيقات الأساسية: navigator.modelContext

يوسّع WebMCP المتصفحَ بواجهة ModelContext، المتاحة فقط على الصفحات الآمنة (HTTPS). وتقوم الطريقة الأساسية بتسجيل أداة لدى المتصفح ليتمكّن أي وكيل زائر من اكتشافها واستدعائها.

navigator.modelContext.registerTool({
  name: "add_to_cart",
  description: "Add a product to the shopping cart by ID and quantity.",
  inputSchema: {
    type: "object",
    properties: {
      product_id: { type: "string" },
      quantity: { type: "number" }
    },
    required: ["product_id", "quantity"]
  },
  async execute({ product_id, quantity }) {
    await cart.addItem(product_id, quantity);
    return {
      content: [
        { type: "text", text: `Added ${quantity} of ${product_id}.` }
      ]
    };
  }
});

لكل أداة أربعة أجزاء أساسية: اسم name فريد (من حرف واحد إلى 128 حرفًا)، ووصف description بلغة طبيعية يقرأه الوكيل ليقرر متى يستخدمها، ومخطط inputSchema اختياري مُعبَّر عنه بصيغة JSON Schema، ودالة استدعاء execute تؤدي العمل وتُرجِع نتيجة. وتُشغّل دالة execute منطق تطبيقك الحقيقي — الكود نفسه الذي تستدعيه أزرارك أصلًا — بحيث يستخدم الوكيل والإنسان مسارات الكود ذاتها.

ملاحظة: لا تزال المواصفة في طور الاستقرار خلال origin trial. كما تشير المسودات الحديثة إلى الواجهة عبر document.modelContext، وقد تتغير التسمية الدقيقة قبل المسار المعياري. تعامل مع هذه الواجهة باعتبارها قيد التطور وثبِّت إصدارك على ما يقابل رمز origin trial الخاص بك.

لا حاجة إلى JavaScript: النماذج التعريفية

أكثر أجزاء الاقتراح المُقلَّل من قدرها هو أن المواقع البسيطة لا تحتاج إلى JavaScript على الإطلاق. يمكنك إضافة بعض السمات إلى نموذج HTML قائم فيصبح فورًا أداة قابلة للاستدعاء من الوكيل:

<form tool-name="book_table"
      tool-description="Reserve a table at the restaurant">
  <input name="party_size"
         tool-param-description="Number of guests" />
  <input name="date"
         tool-param-description="Reservation date in YYYY-MM-DD format" />
</form>

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

لماذا يهم هذا عملك

التحوّل هنا أكبر من مجرد واجهة برمجة جديدة. فعلى مدى العقد الماضي، كان الويب مُحسَّنًا لأعين البشر ونقرات الفأرة. أما WebMCP فيُحسّنه للنية المُفوَّضة — يقول المستخدم "أعد طلب المعتاد" فيستدعي الوكيل أداة reorder لديك مباشرةً، وبموثوقية، في كل مرة.

بعض الفوائد الملموسة:

• الموثوقية بدل الكشط. تنهار الوكلاء المعتمدة على الـ DOM مع كل إعادة تصميم. أما الأداة المُسجَّلة فتظل تعمل ما دام عقدها قائمًا، مهما تغيّرت الواجهة.
• تبقى أنت المتحكِّم. أنت تقرّر بالضبط أي الإجراءات يمكن للوكلاء تنفيذها. فأداة تحليلات للقراءة فقط يمكن وسمها ليعرف الوكلاء أنها آمنة؛ بينما يمكن لإجراء مُدمِّر أن يتطلّب تأكيدًا.
• قابلية الاكتشاف في عصر الوكلاء. مع تزايد تصرّف المستخدمين عبر الوكلاء، ستكون المواقع التي تكشف أدوات نظيفة هي التي يمكن للوكلاء استخدامها فعلًا. وهذا يتشكّل ليصبح SEO الخاص بالويب الوكيلي.

بالنسبة للتجارة الإلكترونية، يكون ذلك "ابحث لي عن أحذية رياضية بأقل من 100 دينار وأضف مقاسي إلى السلة." وبالنسبة للوحات تحكم SaaS، يكون "اعرض كل حساب جُدِّد في الربع الأول وصدِّر القائمة." هذه هي المسارات نفسها التي استكشفناها في دليلنا عن وكلاء المتصفح وأتمتة الويب — لكن الآن يتعاون الموقع بدلًا من أن يُكشَط.

الأمان والإنسان ضمن الحلقة

إن إبقاء التنفيذ داخل المتصفح أمرٌ قوي، لذا فإن التصميم متحفّظ عن قصد. فلا يمكن تسجيل الأدوات إلا في سياق آمن، ويخضع الوصول إليها لسياسة صلاحيات tools التي تكون افتراضيًا مقصورة على origin الصفحة نفسها. وتتلقى دالة execute كائن عميل يتيح للأداة أن تتوقف وتطلب تأكيدًا صريحًا من المستخدم قبل القيام بأي شيء حساس — وهي نقطة تحقّق مدمجة تضع الإنسان ضمن الحلقة.

يمكن للأدوات أيضًا أن تحمل تعليقات توضيحية مثل readOnlyHint وuntrustedContentHint، مما يساعد الوكلاء على التفكير في المخاطر. والكشف عبر الأصول المتعددة (cross-origin) اختياري عبر قائمة سماح exposedTo، ولا تزال سياسات الوصول إلى الأدوات على نمط CORS قيد الإنهاء لمنع تسريب البيانات بين التبويبات. وكما هو الحال دائمًا مع معيار سريع التطور، فإن نموذج الأمان جزء مما لا يزال قيد الحضانة — راجعه بعناية قبل كشف الإجراءات عالية المخاطر.

كيف تبدأ اليوم

1. فعِّل العلَم (flag). في Chrome 146 أو أحدث، افتح chrome://flags، وابحث عن "Experimental Web Platform features" أو "WebMCP"، وفعِّلها، ثم أعد التشغيل.
2. سجِّل أداة واحدة. اختر إجراءً واحدًا آمنًا للقراءة فقط على موقعك — بحثًا أو فلترًا — ولُفّه بـ registerTool.
3. اختبر مع وكيل. استخدم وكيلًا أو امتدادًا متوافقًا مع WebMCP لاستدعاء الأداة والتأكد من أن المخطط والنتيجة يمرّان ذهابًا وإيابًا بشكل سليم.
4. توسّع تدريجيًا. أضف إجراءات كتابة خلف تأكيد، وضع تعليقات توضيحية على أدوات القراءة فقط، وقم بتركيب الأدوات أو إزالتها مع تنقّل المستخدمين.

ابدأ صغيرًا. فأداة واحدة موصوفة جيدًا تعلّمك عن التصميم الجاهز للوكلاء أكثر مما تعلّمه مئة صفحة من المواصفات.

الخلاصة

إن WebMCP في مراحله الأولى — فهو origin trial وليس معيارًا مُطلَقًا، وستتغير واجهة الـ API. لكن الاتجاه واضح لا لبس فيه. فالويب يتحوّل إلى مكان يتشارك فيه البشر والوكلاء أدوات التحكم نفسها، وستكون المواقع التي تنشر أدوات نظيفة وموصوفة جيدًا هي التي تعمل حين يفوّض المستخدم مهمةً بدلًا من القيام بها يدويًا.

في نقطة، نبني بالفعل تجارب جاهزة للوكلاء داخل المنتجات التي نطلقها. وإن كنت تريد أن يكون موقعك جاهزًا للويب الوكيلي — لا أن يُكشَط منه — فإن هذا العمل يبدأ الآن. تحدّث إلينا حول جعل موقعك جاهزًا للوكلاء.