WebMCP: حين يعلن موقعك أدواته للوكلاء بدل أن يخمّنوها
معيار WebMCP يجعل موقعك يعلن أدواته للوكلاء بدل أن يخمّنها بصرياً: ما الذي يتغيّر لمطوّري الويب، وأين الحافة الأمنية الحادّة قبل أن تجرّبه فعلاً.
منذ عامين ووكلاء الذكاء الاصطناعي يتعاملون مع موقعك بالطريقة نفسها التي يتعامل بها لصّ مع قفل: من الخارج، بالتخمين، وبلا إذن منك. يلتقط الوكيل صورة للصفحة ويمرّرها على نموذج رؤية، أو يحلّل شجرة العناصر ويحاول أن يستنتج أي زرّ هو زرّ «إتمام الطلب». تنجح العملية أحياناً، وتفشل بصمت أحياناً أكثر، وأنت صاحب الموقع لا تعرف أصلاً أن ذلك يحدث.
معيار WebMCP يقلب هذه المعادلة: بدلاً من أن يخمّن الوكيل ما يستطيع موقعك فعله، يعلن موقعك بنفسه قائمة الأشياء التي يسمح باستدعائها. الفكرة بسيطة إلى حدّ يبدو معه السؤال الحقيقي ليس «كيف أنفّذها؟» بل «هل يجب أن أنفّذها أصلاً؟».
ما هو WebMCP بالضبط؟
هو واجهة برمجية داخل المتصفح نفسه، تُطوَّر تحت مجموعة W3C المعنية بتعلّم الآلة في الويب، وتتيح للصفحة أن تسجّل «أدوات» عبر واجهة navigator.modelContext. كل أداة لها اسم ووصف ومعاملات محدّدة — تماماً كما تصف نقطة نهاية في واجهة برمجية، لكن المستهلك هنا هو الوكيل الذي يعمل داخل متصفح المستخدم.
موقع حجز طيران مثلاً يمكنه أن يعلن أداة searchFlights بمعاملات واضحة: المغادرة، الوجهة، التاريخ. الوكيل لا يبحث عن حقول الإدخال ولا يحاول ملأها بالنقر — يستدعي الأداة مباشرة ويستقبل نتيجة منظّمة.
أين يختلف عن بروتوكول MCP الذي تعرفه؟
الالتباس هنا شائع، والفرق جوهري:
| MCP | WebMCP | |
|---|---|---|
| مكان التشغيل | خادم منفصل (خلفية) | داخل الصفحة نفسها (واجهة أمامية) |
| من يبني الخادم | فريق الخلفية | مطوّر الواجهة الأمامية |
| المصادقة | تدفّق OAuth مستقل | يرث جلسة المستخدم وكوكيزه |
| الوصول للبيانات | ما تفتحه الخلفية | ما تراه الصفحة بالفعل |
النقطة الثالثة هي أصل الفكرة كلها. المشروع بدأ كتجربة شخصية لمهندس واجه مشكلة عملية: مواصفة MCP كانت تفترض OAuth، بينما خدمات شركته الداخلية تعمل بتسجيل دخول موحّد عبر المتصفح. فجعل المتصفح نفسه هو الوسيط. لاحظت فرق Chrome وEdge الفكرة عبر قنوات W3C، وتحوّلت إلى مقترح مشترك قُدّم في أغسطس 2025، ثم صار مسودة رسمية في فبراير 2026.
لماذا يهتم أحد أصلاً؟ الرقم الذي يُروَّج له
الحجّة التقنية المركزية اقتصادية بحتة: الوكيل الذي يقرأ صفحتك بالصورة يستهلك عشرات الآلاف من الرموز في كل خطوة. الوكيل الذي يستدعي أداة معلنة يستهلك جزءاً صغيراً من ذلك — والرقم الذي يتكرّر في العروض هو توفير يقارب 89% مقارنةً بالتفاعل القائم على لقطات الشاشة.
تعامل مع هذا الرقم بوصفه سقفاً تسويقياً لا متوسطاً واقعياً؛ فهو يقارن أفضل حالة معلنة بأسوأ حالة قديمة. لكن حتى لو كان النصف، فالفارق يكفي ليجعل الوكلاء يفضّلون المواقع المزوّدة بأدوات على المواقع التي تتطلب تخميناً. وهنا يبدأ الجزء الذي يخصّك.
الموقع الذي يعلن أدواته لا يصبح «أسرع» فحسب — يصبح مفضَّلاً. وحين يصير التفضيل تقنياً وقابلاً للقياس، يتحوّل المعيار الاختياري إلى شرط دخول خلال دورتين أو ثلاث.
الاعتراض الجدّي: هل هذا AMP جديد؟
انقسم المجتمع التقني بين وصفين متناقضين للمعيار نفسه: «أهم واجهة متصفح منذ Service Workers»، و«AMP بثوب جديد». والمقارنة الثانية ليست تهكّماً — هي قراءة لنمط متكرّر.
نمط AMP كان: شركة تملك محرّك البحث تقترح صيغة تقنية «أسرع»، وتمنح المواقع المتبنّية أفضلية في العرض، فيتبنّاها الجميع ليس اقتناعاً بل خوفاً من الخسارة. ثم يجد الناشرون أنفسهم يصونون نسخة إضافية من مواقعهم وفق مواصفة يتحكّم بها طرف واحد.
التشابه هنا حقيقي في العنصر الحاسم: الجهة التي تحدّد شكل الأداة هي نفسها الجهة التي تبني الوكيل الذي يستهلكها. والاختلاف حقيقي أيضاً: WebMCP يمرّ فعلاً عبر W3C بمشاركة أكثر من متصفح، ولا يطلب منك نسخة ثانية من موقعك بل طبقة إعلان فوق ما لديك. أيّ العاملين يغلب؟ لم يُحسم بعد، وهذا بالضبط سبب عدم استعجال القرار.
الحافة الحادّة التي يقلّ الحديث عنها
الميزة التي تجعل WebMCP عملياً — وراثة جلسة المستخدم المسجَّل — هي نفسها سطح الخطر. حين تعلن أداة، فأنت تصنع مساراً يُستدعى داخل جلسة المستخدم المصادَق عليها وبكامل صلاحياته، بناءً على قرار يتخذه نموذج لغوي متأثّر بكل ما يقرأه في تلك الصفحة.
عملياً هذا يعني أن نصاً في تعليق مستخدم، أو في وصف منتج، أو في رسالة واردة معروضة على الصفحة، يمكن أن يوجّه الوكيل لاستدعاء أداتك أنت. المواصفة نفسها لا تخفي هذا: أقسام الأمان والخصوصية فيها لم تكتمل بعد، ولديها عشرات المشكلات المفتوحة، وهي تحذّر صراحةً من الشحن إلى الإنتاج.
الخلاصة العملية إن قرّرت التجربة: لا تعلن أداة تفعل شيئاً لا يمكن التراجع عنه. أدوات قراءة وبحث وفلترة — نعم. أدوات تُنشئ طلباً، أو تحذف بيانات، أو تحرّك مالاً — ليس قبل أن تكتمل حدود المواصفة وتضيف أنت تأكيداً بشرياً صريحاً في المسار.
ما موقف المعيار اليوم، وماذا تفعل الآن؟
الوضع الحالي: مسودة مجموعة مجتمعية في W3C، ليست معياراً معتمداً ولا على المسار الرسمي للمعايير. الدعم موجود في قنوات Chrome التجريبية خلف راية تفعيل، وأدوات الأتمتة بدأت تدعمه، والحديث عن وصول مستقر يدور حول الربع الأخير من 2026.
بناءً على ذلك، التصرّف المعقول هذا الشهر ليس التبنّي ولا التجاهل:
- جرّبه في بيئة تجريبية لا في الإنتاج. أداة واحدة للقراءة فقط تكفي لتفهم النموذج الذهني كله.
- افصل منطق عملك عن طبقة الواجهة أولاً. الأدوات التي ستعلنها لاحقاً ستكون مجرّد غلاف رفيع فوق دوال موجودة. هذا الفصل مفيد لك اليوم بمعزل عن المعيار تماماً.
- اكتب اليوم سياسة واضحة للوكلاء في موقعك. ما تسمح به وما تمنعه ومن أي نطاقات — القرار سيُطلب منك قريباً، والأفضل أن يُتخذ بهدوء لا تحت ضغط.
- راقب البديل الأبسط: واجهتك البرمجية العامة. إن كان لديك API موثّق جيداً، فجزء كبير من قيمة WebMCP متاح لك أصلاً بطريق آخر.
- لا تعِد هيكلة موقعك حول مسودة. المواصفة تغيّرت مرّتين خلال ستة أشهر، وقد تتغيّر مجدداً قبل الاستقرار.
أسئلة شائعة
هل يعني هذا نهاية تحسين محركات البحث كما نعرفه؟ لا، لكنه يضيف طبقة موازية. تحسين المحركات يجعل صفحتك مفهومة للقارئ الآلي؛ WebMCP يجعل موقعك قابلاً للتشغيل من قِبله. الأول يتعلّق بأن تُعثر عليك، والثاني بأن يُنجَز شيء عندك. الموقع الذي يُقرأ ولا يُستعمل سيبقى موجوداً، لكن حصّته من التفاعل الآلي ستنتقل لغيره.
هل أحتاج إضافة متصفح أو خادماً إضافياً لتشغيله؟ لا. هذه نقطة قوّته: الصفحة نفسها هي الخادم، وكل شيء يعمل في جانب العميل داخل جلسة المستخدم. لا خادم جديد، ولا تدفّق مصادقة منفصل، ولا بنية تحتية إضافية تصونها.
ماذا لو تجاهلته تماماً هذا العام؟ لن يحدث شيء هذا العام على الأرجح، وهو خيار دفاعي مقبول تماماً في 2026. المخاطرة ليست في تأخّر شهور، بل في أن تكتشف بعد سنة أن منافسك صار الوجهة الافتراضية للوكلاء في مجالك بينما موقعك يتطلّب تخميناً بصرياً مكلفاً.
الخلاصة
WebMCP ليس ميزة تضيفها هذا الأسبوع — هو تغيير في من يملك تعريف التفاعل مع موقعك. اليوم الوكيل يخمّن ويسيء الفهم أحياناً وأنت خارج المعادلة؛ وغداً قد تعلن أنت الحدود بدقّة، مقابل أن تعترف بأن موقعك صار سطحاً تشغيلياً لبرنامج آخر لا لمستخدم بشري فقط.
القرار الصائب الآن ليس أن تسبق المعيار، بل ألّا تُفاجأ به: افهم النموذج، جرّبه على أداة قراءة واحدة، أبقِ كل ما لا يمكن التراجع عنه خارج المتناول، وانتظر أن تكتمل أقسام الأمان قبل أن تسلّمه أي شيء يهمّك فعلاً.
