WebMCP: عندما تستخدم وكلاء الذكاء الاصطناعي موقعك بالحديث لا بالنقر

في أحد الأيام كنت أقوم بعمل روتيني تماماً. فتحت موقع أحد عملائنا وأدخلته إلى PageSpeed Insights. لا أستطيع إحصاء عدد المرات التي أفعل فيها هذا يومياً؛ فقراءة تقرير السرعة في عملنا أمر روتيني بقدر شرب قهوة الصباح. كنت أتصفح التقرير من الأعلى إلى الأسفل حين لفت نظري سطر واحد: agentic browsing.

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

عملنا في Detartech هو جعل المواقع مرئية في محركات البحث، والآن في محركات الذكاء الاصطناعي أيضاً، أي SEO وGEO. لذلك فإن سؤال "كيف تقرأ الآلات الموقع" ليس بالنسبة لي فضولاً أكاديمياً، بل مصدر رزق مباشر. حين قرأت عن WebMCP أدركت أن السؤال لم يعد فقط "كيف ستقرأ الآلات موقعك". بل أصبح السؤال الحقيقي: كيف ستستخدم الآلات موقعك؟

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

عصور الويب الثلاثة: الإنسان ينقر، والبوت يفهرس، والوكيل ينجز العمل

يمكنني تقسيم تاريخ الويب تقريباً إلى ثلاث مراحل.

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

وأصبحت المرحلة الثانية مرحلة الروبوتات. جاء Googlebot، وفهرس صفحتك، وأدرجها، ورتّبها. وكل ما نسميه اليوم SEO هو في الحقيقة وليد هذه المرحلة. كتبنا ملف robots.txt حتى "تقرأ الروبوتات صفحتي بشكل صحيح"، وأنشأنا خرائط الموقع، وأضفنا وسوم schema.org. كانت الروبوتات تقرأ لكنها لم تفعل شيئاً. كانت فقط تفهم وتُدرج في القوائم.

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

في توثيق Chrome، أُعطيت هذه العملية اسماً دقيقاً: actuation (التفعيل أو التنفيذ). وهو أن يقوم الوكيل، مثل الإنسان تماماً، بمحاكاة النقر بالماوس والكتابة على لوحة المفاتيح لتنفيذ العمل على موقعك. قد تكون مهمة بسيطة من خطوة واحدة مثل النقر على رابط، أو سلسلة معقدة مثل إتمام عملية شراء من البداية إلى النهاية.

يبدو هذا رائعاً، أليس كذلك؟ المشكلة أن هذه الطريقة هشّة للغاية. وهنا بالضبط تبدأ القصة الحقيقية.

المشكلة الأساسية: الوكيل يتجول في موقعك كالأعمى

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

كل خطوة تفسير. وكل تفسير مقامرة.

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

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

وهنا يظهر WebMCP تحديداً لإنهاء هذا التجول الأعمى.

ما هو WebMCP؟

WebMCP هو معيار ويب مقترح يتيح للمواقع تعريف أدوات منظّمة (tools) لوكلاء الذكاء الاصطناعي. المنطق واضح تماماً: بدلاً من انتظار أن يخمّن الوكيل وظيفة زرّك، يُعلن الموقع نفسه بشكل صريح: "هذه الميزة كذا، تُستدعى بهذه الطريقة، وتقبل هذه المدخلات".

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

وفقاً لشرح Chrome، يتيح WebMCP ثلاثة أمور:

• الاكتشاف (Discovery): تعريف الصفحة للوكيل بالأدوات التي تمتلكها بصيغة موحدة قياسية. مثل odeme_al وsonuclari_filtrele وrandevu_olustur.
• مخططات JSON: تعريف دقيق للمدخلات التي تقبلها كل أداة والمخرجات التي تعيدها. وهذا يقلل بشكل كبير من احتمال أن يقوم النموذج بالاختلاق (الهلوسة)، لأن الآلة تعرف الآن بالضبط ما هو المطلوب منها.
• الحالة (State): مشاركة السياق الحالي للصفحة مع الوكيل؛ أي أن الوكيل يعرف في الوقت الفعلي على أي الموارد يمكنه تنفيذ العمليات.

وبالنسبة لمن أتوا من عالم SEO مثلنا، دعني أبني جسراً هنا: عندما نضيف بيانات منظّمة عبر schema.org، فإننا في الواقع نضع على الصفحة وسوماً مثل "هذا منتج، وهذا سعره، وهذا تقييمه" كي يفهم Google. أما WebMCP فهو أشبه بنسخة أرقى من ذلك: تضع وسوماً على الصفحة، لكن هذه المرة ليس فقط لكي تفهم الآلة، بل لكي تنجز العمل. بدلاً من "افهم"، أصبحت الرسالة "نفّذ". والفرق بينهما هائل.

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

لنلقِ نظرة على الكود الآن: طريقتان مختلفتان

هناك طريقتان لإضافة WebMCP إلى موقعك. سأعرض كلتيهما، لأن الشرارة الحقيقية تنطلق فقط عندما ترى الكود.

1. واجهة Imperative API - تعريف الأداة باستخدام JavaScript

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

document.modelContext.registerTool({
  name: 'randevu_olustur',
  description: 'Seçilen hizmet, tarih ve müşteri için randevu oluşturur.',
  inputSchema: {
    type: 'object',
    properties: {
      hizmet:  { type: 'string', enum: ['sac-kesimi', 'sakal', 'boya'] },
      tarih:   { type: 'string', description: 'YYYY-AA-GG biçiminde randevu tarihi' },
      adSoyad: { type: 'string' }
    },
    required: ['hizmet', 'tarih', 'adSoyad']
  },
  execute: async ({ hizmet, tarih, adSoyad }) => {
    const sonuc = await randevuKaydet({ hizmet, tarih, adSoyad });
    return `Randevu oluşturuldu: ${adSoyad} - ${hizmet} - ${tarih}`;
  }
});

ما يحدث هو التالي: من خلال registerTool تمنح الأداة هوية. يساعد description الوكيل على فهم وظيفة هذه الأداة؛ ويحدد inputSchema الحقول المطلوبة (مثلاً أن حقل hizmet يقبل فقط قيماً معينة)؛ أما execute فيحدد ما يحدث فعلياً عند استدعاء الأداة. حين يتلقى الوكيل مهمة "احجز لهذا الشخص موعد قص شعر غداً"، لم يعد يبحث عن زر على الشاشة، بل يستدعي هذا العقد مباشرة.

ملاحظة: أصبح navigator.modelContext، الذي كان يُستخدم في الإصدارات السابقة، مهملاً بدءاً من Chrome 150؛ والاستخدام الصحيح هو عبر document.modelContext. إذا كنت ستبدأ من جديد، فادخل من الباب الصحيح منذ البداية.

2. واجهة Declarative API - تحويل نموذج HTML عادي إلى أداة

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

<form toolname="iletisimGonder"
      tooldescription="Ziyaretçinin iletişim formunu gönderir."
      action="/iletisim">

  <label for="ad">Ad Soyad</label>
  <input type="text" name="ad">

  <label for="eposta">E-posta</label>
  <input type="email" name="eposta">

  <label for="mesaj">Mesajınız</label>
  <textarea name="mesaj"></textarea>

  <button type="submit">Gönder</button>
</form>

بمجرد إضافة خاصيتَي toolname وtooldescription، يبدأ المتصفح بتفسير هذا النموذج كأداة منظّمة؛ وتصبح حقول النموذج معاملات الأداة. حين يستدعي الوكيل الأداة، يقوم المتصفح بالتركيز على النموذج وملء الحقول، ويبقى النموذج مرئياً للمستخدم. يمكنك أتمتة الإرسال باستخدام toolautosubmit إذا أردت، أو ترك التأكيد للمستخدم.

أول ما خطر ببالي عند رؤية هذا هو: إنه schema.org للإجراءات. في البيانات المنظّمة تضع على الصفحة إشارة "هذا حدث، وهذا تاريخه"؛ وهنا تضع إشارة "هذه أداة تواصل، وهذه الحقول التي تقبلها". المنطق واحد تماماً؛ فقط الهدف تحوّل من "أن أُفهَم" إلى "أن أُنجز عملاً". بالنسبة لمن اعتاد لسنوات على شرح محتوى الصفحة للآلة عبر SEO، هذا الانتقال ليس غريباً على الإطلاق، بل هو تمرين جديد لنفس العضلة.

"هل سيحل WebMCP محل MCP؟" - لا، وهذا سوء فهم مهم

يبدو أن هذه هي أكثر النقاط التباساً عند قراءة هذا الموضوع، وقد أجاب فريق Chrome مباشرة على هذا السؤال. MCP (Model Context Protocol) وWebMCP ليسا متنافسين، بل شريكين. كل منهما يخدم احتياجات مختلفة، وأقوى تجارب الوكلاء تستخدمهما معاً.

تشبيهي المفضل مأخوذ من التوثيق نفسه: يمكنك تشبيه هذا بالفرق بين مركز اتصال الشركة ومستشار المبيعات الخبير في المتجر.

• MCP هو الواجهة الخلفية (backend). يمكن الوصول إليه من أي منصة وفي أي وقت. يجلب البيانات وينجز المهام الأساسية. يعيش على جانب الخادم، وهو دائم. تماماً مثل مركز الاتصال: أينما كنت يمكنك الاتصال والوصول إليه.
• WebMCP هو الواجهة الأمامية (frontend). يعيش فقط في موقعك، وفقط عندما يكون الموقع مفتوحاً. يصل إلى بيانات الجلسة الحقيقية في تبويب المتصفح النشط، وإلى ملفات تعريف الارتباط، وعناصر DOM. تماماً مثل الخبير في المتجر: موجود فقط في ذلك المتجر، وفقط عندما تكون أنت بالداخل.

دعني ألخّص الفرق الأساسي بينهما في جدول، لأن ذلك يرسخ في الذهن بشكل أوضح:

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

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

إذن، ماذا يعني هذا بالنسبة لـSEO وGEO؟

هذا هو الجزء الذي أثار حماستي فعلاً. لأنني دخلت في هذا الموضوع وأنا أقرأ تقريراً، لكنني خرجت منه وفي ذهني سؤال مختلف تماماً.

لسنوات كان لـSEO هدف واحد فقط: الترتيب. أن تصل إلى مرتبة عالية في الكلمة المفتاحية، وأن تحصل على النقرة. ثم ظهر GEO، أي Generative Engine Optimization. أي إنتاج محتوى لكي تشير إليك المحركات التوليدية مثل ChatGPT وPerplexity وملخصات الذكاء الاصطناعي من Google كمصدر عند تقديم إجابة. كان SEO يقول "رتّبني"؛ بينما يقول GEO "افهمني واقتبس مني".

أما WebMCP فيذهب خطوة أبعد: "استخدمني".

تخيّل هذه الأمور الثلاثة كسُلّم:

1. SEO - اجعل الآلة تجدك وترتبك.
2. GEO - اجعل الآلة تفهمك وتذكرك كمصدر في إجابتها.
3. توافق الوكلاء (WebMCP) - اجعل الآلة تنجز العمل من خلالك.

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

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

لهذا السبب نتعامل في Detartech مع SEO وGEO ليس كأمرين منفصلين، بل كجزأين من المستقبل نفسه. لأن مستقبل ظهورك يمرّ بالضبط عبر طريقة تفاعل الآلة مع موقعك، هل تقرؤه؟ هل تفهمه؟ هل يمكنها تنفيذ إجراءات عليه؟

سيناريو ملموس من تركيا

لنتجنب الحديث المجرد. لنفترض أنك تدير موقع تجارة إلكترونية، أو لديك، مثلي، منصة قائمة على حجز المواعيد.

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

في السيناريو الثاني، أنت الخاسر. وذلك دون أن تدرك حتى، لأن ذلك العميل لم "يزُر" موقعك أبداً، بل زاره وكيله ثم عاد أدراجه.

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

لنكن صادقين: لهذا الأمر حدوده أيضاً

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

هذا الأمر ما زال جديداً جداً. يوجد WebMCP حالياً في مرحلة "origin trial"، ومتاح للتجربة اعتباراً من Chrome 149. أي أن المعيار لم يستقر بعد، وقد يتغير مستقبلاً. إذا أردت تجربته محلياً يمكنك تفعيل العلامة chrome://flags/#enable-webmcp-testing والبدء بالتجربة، لكن لا تنسَ أن هذه ليست بنية تحتية مضمونة للإنتاج.

يتطلب الأمر تبويباً مفتوحاً. بما أن استدعاءات الأدوات تتم عبر JavaScript، لا بد من وجود واجهة مرئية، أي تبويب متصفح مفتوح. لا يمكن لوكيل بدون واجهة (headless) أن يستدعي هذه الأدوات. أما بالنسبة للجزء الذي يعمل بصمت في الخلفية، فهناك MCP أصلاً لهذا الغرض.

الواجهات المعقدة تتطلب جهداً. إذا كان موقعك متعدد الطبقات ومعقداً، فقد تحتاج إلى كتابة كود، بل وإجراء بعض إعادة الهيكلة، لنقل إدارة الحالة بشكل صحيح إلى الوكيل.

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

لماذا أخبرك بكل هذا؟ لأنه من السهل أن أقول "غداً سيتغير كل شيء، اركض الآن"، لكن ذلك ليس صادقاً. الحقيقة هي أن هذا اليوم بذرة. لكن معرفة متى تزرع البذرة هي ما يحدد من سيجلس في ظل الشجرة.

ماذا أفعل أنا، وماذا أنصحك به؟

بعد أن أنتهي من كتابة هذا المقال، سأقوم بما يلي بالترتيب:

أولاً، سأنظر إلى النماذج والعمليات الحساسة في منتجاتي بعين الوكيل. نموذج التواصل، مسار حجز الموعد، خطوة الدفع، هل يمكن للآلة أن تراها بوضوح، أم أنها مضطرة للتقدم بالتخمين؟ بعدها سأبدأ بالتفكير بعقلية "الأداة": سأتخيل كل إجراء مهم في موقعي كأداة واضحة يمكن للوكيل استدعاؤها. البدء بـDeclarative API يبدو أسهل طريقة لخوض هذه التجربة دون الدخول في JavaScript؛ وربما أبدأ من هناك.

نصيحتي لك لا تختلف. لست بحاجة اليوم إلى إعادة كتابة بنية تحتية كاملة من الصفر. لكن يمكنك القيام بثلاثة أمور: ابنِ نماذج HTML بهياكل name وlabel نظيفة وذات معنى (فهذه أصلاً ذات قيمة عالية سواء لإمكانية الوصول أو لتوافق الوكلاء)، وتعوّد على التفكير في العمليات الأساسية في موقعك كـ"أدوات"، وتابع هذا المعيار ولو من بعيد. القطار لم يغادر المحطة بعد؛ لكن لا ضرر في شراء تذكرتك من الآن.

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

الويب يتغير. مرة أخرى. وهذه المرة، ما يتغير ليس كيف تقرأ الآلات صفحتك، بل كيف تستخدمها.

الأسئلة الشائعة

ما هو WebMCP؟
WebMCP هو معيار ويب مقترح يتيح للمواقع تعريف أدوات منظّمة (tools) لوكلاء الذكاء الاصطناعي. بدلاً من أن يخمّن الوكيل وظيفة الأزرار الموجودة في الصفحة، يجعل الموقع نفسه يُعلن بوضوح عن هدف كل ميزة وكيفية استدعائها. وبذلك تُنجز الوكلاء المهام بشكل أكثر موثوقية ودون أخطاء.

ما الفرق بين WebMCP وMCP؟
يعيش MCP (Model Context Protocol) في الواجهة الخلفية؛ يعمل على جانب الخادم، وهو دائم ويمكن الوصول إليه من أي منصة. أما WebMCP فيعيش في الواجهة الأمامية، طالما تبويب المتصفح مفتوحاً؛ ويصل إلى الجلسة الحية وملفات تعريف الارتباط وDOM. الاثنان ليسا متنافسين؛ فأقوى تجارب الوكلاء تستخدم MCP للمنطق الأساسي والبيانات، وWebMCP للتفاعل في الواجهة الحية.

ماذا يعني agentic browsing (التصفح القائم على الوكلاء)؟
هو أن يقوم وكيل ذكاء اصطناعي بالتصفح وتنفيذ العمليات في المواقع نيابة عن المستخدم. يقوم الوكيل بتنفيذ إجراءات مثل ملء النماذج وحجز المواعيد وإتمام الطلبات، إما عن طريق محاكاة سلوك النقر والكتابة البشري (actuation)، أو عن طريق استدعاء أدوات معرّفة مباشرة بواسطة معايير مثل WebMCP.

كيف يؤثر WebMCP على SEO وGEO؟
يهدف SEO إلى أن تجد الآلة صفحتك وترتّبها، ويهدف GEO إلى أن تفهمك محركات الذكاء الاصطناعي وتذكرك كمصدر. أما WebMCP فيذهب خطوة أبعد ويتيح للوكلاء تنفيذ إجراءات من خلال موقعك. وبما أن الوكلاء سيفضلون في المرحلة القادمة المواقع ذات الأدوات المعرّفة بوضوح والنماذج النظيفة، فإن توافق الوكلاء مرشح ليصبح عاملاً جديداً للظهور والتحويل.

كيف أجرّب WebMCP؟
يتوفر WebMCP حالياً كـorigin trial اعتباراً من Chrome 149. للتطوير المحلي، يمكنك تفعيل العلامة chrome://flags/#enable-webmcp-testing في Chrome وإعادة تشغيل المتصفح لبدء التجربة. يمكنك تعريف أدواتك بطريقتين: باستخدام JavaScript (Imperative API)، أو بإضافة خصائص إلى نماذج HTML (Declarative API).

هل سيحل WebMCP محل MCP؟
لا. هذا سوء فهم شائع. WebMCP ليس امتداداً لـMCP ولا تقنية ستحل محله؛ بل يخدم كل منهما احتياجات مختلفة على مستويات مختلفة، وقد صُمِّما للعمل معاً.