WebMCP: الدليل العربي الكامل لربط موقعك بأدوات الذكاء الاصطناعي
الساعة الحادية عشرة ليلاً. عميل يفتح متجر عطور على هاتفه ويكتب لمساعده الذكي: «اطلب لي العود نفسه الذي اشتريته الشهر الماضي». المساعد الذكي يفتح الصفحة، يلتقط صورة لها، يخمّن مكان زر البحث، يكتب، يخطئ في الفلتر، يعيد المحاولة، ويضيف الحجم الخطأ إلى السلة. ثلاث دقائق، وطلب خاطئ.
منذ 21 أغسطس 2026 صار المشهد نفسه مختلفاً على أي متجر Shopify: المساعد الذكي لا يخمّن. المتجر نفسه يقول له «هذه أداة البحث، وهذه أداة السلة، وهذه مدخلاتها»، والمساعد الذكي يستدعيها مباشرة. ما غيّر المشهد اسمه WebMCP.
هذا المقال يشرح لك ما هو بالضبط، ولماذا انتقل من فكرة إلى تشغيل افتراضي على ملايين المتاجر خلال ستة أشهر، وكيف تجهّز موقعك أو متجرك له من اليوم. بلا تهويل، وبلا ترجمة حرفية لمقالات إنجليزية.
دانيال سلوم
استشاري سيو وتحسين محركات الإجابة للمتاجر والمواقع العربية
قرأت المواصفة الرسمية على W3C وتوثيق Chrome وإعلانات Shopify و Cloudflare قبل أن أكتب حرفاً. كل معلومة تقنية هنا لها مصدر في آخر المقال، وكل رأي مكتوب على أنه رأي.
WebMCP اختصار Web Model Context Protocol: معيار ويب مقترح من مهندسي Google و Microsoft تحت مظلة W3C، يتيح لصفحة الويب أن تسجّل «أدوات» باسم ووصف ومخطط مدخلات عبر واجهة document.modelContext، حتى يستدعيها مساعدات الذكاء الاصطناعي (AI Agents) داخل المتصفح مباشرة بدل تصوير الشاشة والتخمين. يعمل حالياً في مرحلة تجريبية (Origin Trial) على Chrome و Edge، ومفعّل تلقائياً على متاجر Shopify، ومتاح بزر واحد لأي موقع خلف Cloudflare.
ما هو WebMCP بالضبط
لسنوات كان الموقع مصمماً لعين الإنسان ويده: أزرار وقوائم وألوان. عندما دخلت مساعدات الذكاء الاصطناعي على الخط اضطرت إلى تقليد الإنسان: تصوّر الصفحة، تقرأ شجرة الصفحة (DOM)، وتضغط كأنها مستخدم. هذا الأسلوب يسمّونه actuation (التحريك البصري)، وهو بطيء ومكلف ويتكسر مع أي تعديل في التصميم.
WebMCP يقلب المعادلة. بدل أن يخمّن المساعد الذكي ما تستطيع الصفحة فعله، الصفحة تعلن له: هذه أدواتي، وهذا وصف كل أداة، وهذه المدخلات التي تحتاجها. المساعد الذكي يقرأ القائمة، يرسل المعاملات المطلوبة، ويستلم نتيجة منظمة.
المعيار مطوّر من مهندسين في فريق Chrome لدى Google وفريق Edge لدى Microsoft، ويُحتضن داخل مجموعة Web Machine Learning Community Group في W3C. أُعلن رسمياً في 10 فبراير 2026 كمعاينة مبكرة في Chrome 146 Canary خلف خيار تجريبي، وفي يونيو دخل مرحلة تجريبية عامة يستطيع أي موقع الانضمام إليها.
الفكرة الجوهرية التي يجب أن تثبت في ذهنك: الأداة تعيش داخل صفحتك، وتنفّذ كود الواجهة الموجود لديك أصلاً. لا خادم جديد ولا نسخة ثانية من منطق التطبيق. المساعد الذكي والمستخدم يعملان على الشاشة نفسها، والمستخدم يرى كل خطوة ويستطيع إيقافها.
الفرق بينه وبين MCP: أين تعيش الأداة؟
إذا تابعت موضوع كيف يقتبس ChatGPT من المواقع فأنت تعرف MCP: بروتوكول يربط نماذج الذكاء الاصطناعي بخدمات خارجية عبر خادم خلفي. الشركة تبني خادم MCP، وتسجّله لدى المنصة، والمنصة تخاطب الخادم مباشرة.
هذا ممتاز للعمليات الخلفية. لكنه يواجه ثلاث مشكلات عندما يكون التطبيق واجهة ويب تفاعلية، والمواصفة نفسها تسمّيها بالاسم:
- تجاوز الواجهة: التفاعل يحدث بين المساعد الذكي والخادم، والصفحة التي فتحها المستخدم لا ترى شيئاً.
- تكرار الحالة والصلاحيات: عليك إعادة بناء جلسة المستخدم وسياقه وتسجيل دخوله على خادم منفصل.
- عبء المطوّر: لكي تكشف قدرات موجودة أصلاً في JavaScript الواجهة، تحتاج إلى كتابة خادم كامل.
WebMCP يحل المشكلات الثلاث بخطوة واحدة: الأداة تُعرَّف في سكربت الصفحة، وتنفَّذ بالجلسة نفسها والصلاحيات نفسها والكود نفسه. ولهذا بنت Cloudflare جسراً يحوّل خادم MCP الموجود لديك أصلاً إلى أدوات WebMCP داخل الصفحة. ليس بديلاً، بل امتداداً.
| البند | MCP | WebMCP |
|---|---|---|
| مكان التنفيذ | خادم خلفي تديره أنت | داخل تبويب المتصفح، في صفحتك |
| الجلسة والصلاحيات | تُعاد بناؤها على الخادم | جلسة المستخدم الحالية كما هي |
| من يستدعي الأداة | منصة الذكاء الاصطناعي من السحابة | مساعد ذكي داخل المتصفح أو إضافة أو إطار |
| ما يحتاجه المطوّر | خادم وبنية تحتية وصيانة | دالة JavaScript أو نموذج HTML موجود |
| رؤية المستخدم | لا يرى ما يحدث | يرى كل خطوة ويؤكد الحساس منها |
| الأنسب لـ | عمليات خلفية وتكاملات بين أنظمة | مهام على واجهة يستخدمها إنسان |
ماذا يعني لك: عميلك الذي يشتري عبر مساعد ذكي لا يحتاج إلى التصفح، بل إلى أدوات: بحث في الكتالوج، إضافة إلى السلة، تتبع طلب، سؤال عن سياسة الإرجاع. المتجر الذي يعلنها بوضوح يكمل عملية البيع، والذي لا يعلنها يترك المساعد الذكي يتعثر أو ينتقل إلى منافس.
ماذا يعني لك: أهم أداتين لديك هما «اشرح لي الخدمات» و«احجز موعداً أو استشارة». إذا كان نموذج التواصل لديك يحمل خصائص وصفية، يملؤه المساعد الذكي بالبيانات التي أعطاه إياها المستخدم بلا تخمين للحقول.
ماذا يعني لك: لا تحتاج إلى إعادة بناء شيء. تغلّف الدوال الموجودة لديك بتعريف أداة يحمل اسماً ووصفاً ومخطط JSON، أو تضيف ثلاث خصائص إلى نماذج HTML. وتضيف طبقة تأكيد للعمليات الحساسة.
كيف يعمل تقنياً
كل أداة في WebMCP لها أربعة أجزاء: name اسم فريد، وdescription وصف بلغة طبيعية يقرؤه النموذج، وinputSchema مخطط JSON Schema للمدخلات، وexecute الدالة التي تنفذ العمل وترجع النتيجة.
الواجهة البرمجية اسمها document.modelContext. وإذا رأيت في مقالات قديمة navigator.modelContext فهو الاسم الأول نفسه: تغيّر مع Chrome 150 وبقي الاسم القديم بديلاً مؤقتاً. المواصفة الحالية تستخدم الجديد.
الطريقة الأولى: أداة برمجية
// تسجيل أداة بحث في كتالوج المتجر
const controller = new AbortController();
await document.modelContext.registerTool({
name: "search_products",
description: "يبحث في منتجات المتجر بالاسم أو النوع ويرجع أفضل 5 نتائج",
inputSchema: {
type: "object",
properties: {
query: { type: "string", description: "كلمة البحث مثل: عود كمبودي" },
maxPrice: { type: "number", description: "أعلى سعر مقبول" }
},
required: ["query"]
},
async execute({ query, maxPrice }) {
// دالة البحث نفسها التي تستخدمها الواجهة أصلاً
const items = await searchCatalog(query, maxPrice);
renderResults(items); // المستخدم يرى النتائج على الشاشة
return { content: [{ type: "text", text: JSON.stringify(items) }] };
}
}, { signal: controller.signal });
// لإلغاء التسجيل لاحقاً: controller.abort()
لاحظ السطرين المهمين: execute تستدعي دالة البحث الموجودة لديك، وترسم النتائج على الشاشة. هذا جوهر المعيار: المساعد الذكي لا يتجاوز واجهتك، بل يشغّلها.
الطريقة الثانية: نموذج HTML وصفي (Declarative)
أغلب المواقع فيها نماذج جاهزة: بحث، تواصل، حجز. المعيار يجعل المتصفح يحوّل النموذج إلى أداة تلقائياً بثلاث خصائص فقط:
<form action="/search"
toolname="search_products"
tooldescription="ابحث في المنتجات بالاسم مع حد أعلى للسعر"
toolautosubmit>
<input name="q" required
toolparamdescription="اسم المنتج أو نوعه">
<input name="max" type="number"
toolparamdescription="أعلى سعر مقبول">
<button>بحث</button>
</form>
toolname وtooldescription يقابلان الاسم والوصف في الطريقة البرمجية. وtoolautosubmit خاصية منطقية: إذا وُجدت يرسل المساعد الذكي النموذج مباشرة بعد التعبئة، وإذا غابت يملأ الحقول ويترك الضغط للمستخدم. هذا التفصيل الصغير هو صمام الأمان في النماذج الحساسة.
دورة حياة الاستدعاء
-
التسجيل
الصفحة تسجّل أداة أو أكثر عبر
registerTool()أو عبر خصائص النموذج. -
الاكتشاف
المساعد الذكي المتصل بالصفحة يسأل المتصفح عن قائمة الأدوات النشطة ومخططاتها، مثلاً عبر
getTools(). -
الاستدعاء
المساعد الذكي يرسل معاملات مطابقة للمخطط، والمتصفح يتوسط ويتحقق من المصدر والصلاحيات.
-
التنفيذ
دالة
executeتعمل في سياق صفحتك، بجلسة المستخدم نفسها، وتستطيع إيقافها بإشارة إلغاء. -
الرد
النتيجة ترجع إلى المساعد الذكي بصيغة منظمة، ويستطيع أن يكمل التعاون مع المستخدم على الشاشة نفسها.
مرجع سريع لباقي الواجهة (للمطورين)
getTools() ترجع الأدوات المسجلة مع الاسم والوصف والمخطط والنطاق. افتراضياً ترجع أدوات المستندات من النطاق نفسه (same-origin) فقط، وإذا أردت أدوات إطار مضمّن من نطاق آخر تحدد fromOrigins صراحة.
executeTool() تنفّذ أداة مكتشفة، والمتصفح يتأكد أن exposedTo لدى صاحب الأداة وfromOrigins لدى المستدعي متفقان.
حدث toolchange يُطلق على document.modelContext عندما تُضاف أداة أو تُحذف، حتى يحدّث المساعد الذكي قائمته بلا استطلاع.
الإذن اسمه tools في Permissions Policy: مفعّل في النافذة الرئيسية والإطارات المضمّنة من النطاق نفسه، ويُمنح لإطار مضمّن (iframe) من نطاق آخر عبر allow="tools"، ويُمنع كلياً عبر ترويسة HTTP اسمها Permissions-Policy: tools=(). محاولة التسجيل مع الإذن الممنوع ترجع خطأ NotAllowedError.
للنماذج الوصفية توجد فئة CSS زائفة (pseudo-class) اسمها :tool-form-active تطابق النموذج وقت تشغيل أداته، حتى تعرض للمستخدم أن المساعد الذكي يعمل عليه الآن.
تعريفات TypeScript متاحة في حزمة webmcp-types على npm.
جرّب المحاكي: كيف يبدو استدعاء أداة فعلياً
اضغط الزر وشاهد التسلسل الذي يحدث خلال ثوانٍ بين المساعد الذكي وصفحة متجر تدعم WebMCP. كل شيء هنا CSS خالص بلا أي سكربت، وهو تمثيل مبسّط للدورة التي فوق وليس تسجيلاً حرفياً من DevTools.
الفرق مع الطريقة القديمة ليس في السرعة فقط. الفرق أن كل خطوة كانت قابلة للتكرار: الاستدعاء نفسه، النتيجة نفسها، بغض النظر عن لون الزر أو مكانه في التصميم.
ما الذي تغيّر في أغسطس 2026
لو كُتب هذا المقال في يوليو لكان عن «معيار واعد قيد التجربة». ما حدث في أغسطس نقله إلى «طبقة مشغّلة على جزء كبير من التجارة الإلكترونية». وهذا ترتيب الأحداث كما وثّقته المصادر:
Shopify: مفعّل على كل متجر، بلا طلب من التاجر
في 5 أغسطس أعلنت Shopify إضافة WebMCP إلى كل واجهات المتاجر المبنية على Liquid (أي عملياً كل قالب Shopify قياسي) وإلى متاجر Hydrogen في معاينة المطورين. الأدوات المسجلة تلقائياً: البحث في الكتالوج، إدارة السلة، بدء الدفع، والاستعلام عن السياسات. لا شيء يثبّته التاجر. والتفعيل الفعلي بحسب المتابعات المستقلة بدأ في 21 أغسطس.
القيد المهم الذي لا يُذكر في العناوين: هذا يعمل حالياً في المتصفحات المبنية على Chromium ضمن المرحلة التجريبية، ولمتسوق يأتي ومعه مساعد ذكي. أي أن الأثر اليوم محدود، لكن البنية صارت جاهزة قبل الطلب.
Cloudflare: أي موقع بزر واحد
بعدها بيوم، في 6 أغسطس، أطلقت Cloudflare معاينة مطورين تتيح لأي موقع خلف شبكتها تفعيل WebMCP من لوحة التحكم بلا تعديل في الكود ولا تغيير على الخادم الأصلي. الآلية: سكربت وسيط (bridge) يُحقن في HTML عند حافة الشبكة، يبحث عن واجهة WebMCP في المتصفح، وإذا لم يجدها يصمت وتعمل الصفحة كما هي.
حزمتا الأدوات الأوليتان: واحدة تكشف بيانات Content Credentials للمحتوى، والثانية تحوّل خادم MCP الموجود لديك (افتراضياً على المسار /mcp من النطاق نفسه) إلى أدوات داخل الصفحة تنفَّذ بجلسة الزائر. وجاء الإطلاق ضمن أسبوع Cloudflare للمساعدات الذكية الذي شمل كذلك رموز PACT للوصول الخاص بالتعاون مع Mozilla و Google و Microsoft و Shopify، وصيغة Markdown للمساعدات الذكية.
ثلاث إشارات أصغر، وأثرها أكبر
- ChatGPT Desktop صار مدرجاً في صفحة حالة الدعم الرسمية كبيئة تدعم WebMCP، و Brave أضاف دعماً تجريبياً في مساعد Leo.
- Edge 150 بدأ مرحلته التجريبية، فصار المعيار على المتصفحين الأكثر انتشاراً في بيئات الشركات.
- هاكاثون WebMCP Challenge الذي تنظّمه OpenAI بمشاركة Chrome و Cloudflare و Shopify و Vercel و Render و Netlify من 25 أغسطس إلى 3 سبتمبر 2026. عندما تجتمع هذه الأسماء على معيار واحد، فلم يعد تجربة فريق.
دعم المتصفحات الآن
هذا الفحص يعتمد على الفئة الزائفة :tool-form-active المعرّفة في مواصفة النماذج الوصفية، وهو فحص CSS خالص. غياب الدعم هنا طبيعي في أغلب المتصفحات اليوم، وقد يظهر سلبياً حتى في إصدارات تشغّل المرحلة التجريبية إذا لم تُطبّق هذه الفئة بعد.
الفئة الزائفة :tool-form-active معرّفة لديك. هذا يعني أن متصفحك يطبّق جزءاً على الأقل من مواصفة النماذج الوصفية.
الخلاصة العملية: لا تفترض وجود WebMCP لدى أي زائر. المعيار مصمم على مبدأ التحسين التدريجي (Progressive Enhancement): تفحص وجود document.modelContext قبل التسجيل، وإذا غاب تعمل الصفحة كما هي. ولهذا بالضبط ما زال Schema Markup والبنية الدلالية النظيفة هما الأساس الذي يقرؤه كل مساعد ذكي، بوجود WebMCP أو من دونه.
ماذا يعني هذا للمواقع والمتاجر العربية
هنا يجب أن أكون واضحاً بدل أن أكون متحمساً. حتى تاريخ كتابة هذا المقال لم أجد إعلاناً من أي منصة متاجر عربية، مثل سلة أو زد أو غيرهما، عن دعم WebMCP. المتاجر العربية على Shopify حصلت عليه تلقائياً، ومتاجر ووكومرس تستطيع إضافته بنفسها، ومنصات السوق الإقليمية ما زالت خارج الصورة رسمياً. إذا تغيّر هذا سأحدّث المقال.
لكن المسألة أعمق من «من يدعم». ما يحدث الآن هو انتقال جزء من رحلة الشراء من التصفح إلى التفويض: العميل لا يفتح عشرة متاجر، بل يقول لمساعده الذكي ما يريد والمساعد الذكي يقارن وينفّذ. في هذه الرحلة، المتجر الذي يعلن أدواته بوضوح يكمل الصفقة، والمتجر الذي يعتمد على «انظر إلى الصفحة وخمّن» يخسرها بصمت، من دون أن يعرف أنه كان في المنافسة أصلاً.
وهذا المنطق نفسه الذي شرحته في الظهور في إجابات جوجل الذكية: المساعد الذكي يفضّل المصدر الذي يستطيع قراءته والتنفيذ عليه بلا احتكاك. WebMCP هو نسخة «التنفيذ» من الفكرة نفسها.
أريد أن أعرف إن كان موقعي جاهزاً للمساعدات الذكية
أفحص لك موقعك أو متجرك من زاوية المساعدات الذكية ومحركات الإجابة: ما الذي يستطيع المساعد الذكي قراءته وتنفيذه اليوم، وما الأدوات الثلاث التي تستحق تسجيلها أولاً.
كيف تجهّز موقعك اليوم: خطة من خمس خطوات
-
حدّد ثلاث مهام يطلبها عملاؤك فعلاً
ليس «كل الوظائف». ثلاث فقط: بحث في المنتجات، تتبع طلب، حجز موعد أو طلب عرض سعر. استخرجها من رسائل واتساب والدعم التي تصلك، لأنها هي التي سيطلبها المساعد الذكي نيابة عن العميل.
-
ابدأ بالنماذج الوصفية
أسرع مكسب: أضف
toolnameوtooldescriptionإلى نموذج البحث ونموذج التواصل، وtoolparamdescriptionإلى كل حقل. من دونtoolautosubmitفي أي نموذج يرسل بيانات حساسة. -
غلّف منطق JavaScript الموجود بأدوات برمجية
افحص وجود
document.modelContextأولاً، وسجّل أدواتك بوصف دقيق ومخطط صارم. الوصف يقرؤه نموذج لغوي، فاكتبه كأنك تشرح لموظف جديد ماذا تفعل الأداة ومتى تُستخدم. -
صمّم الأمان قبل الأدوات لا بعدها
عامل مدخلات المساعد الذكي كمدخلات غير موثوقة مثل أي نموذج عام. لا تكشف عمليات إدارية أبداً. اطلب تأكيداً بشرياً على الشاشة لأي دفع أو حذف أو إرسال. وقيّد الإذن عبر ترويسة
Permissions-Policyحسب حاجتك. -
اختبر بأدوات Chrome قبل أن تعلن
فعّل الخيار التجريبي
chrome://flags/#enable-webmcp-testingوأعد التشغيل، وافتح تبويب WebMCP في DevTools لترى أدواتك المسجلة، وثبّت إضافة Model Context Tool Inspector لتستدعيها يدوياً وتجرّبها بلغة طبيعية. وللأتمتة توجد واجهة اختبارnavigator.modelContextTesting.
مثال واقعي: موقع خدمات على ووردبريس
هذا مقتطف حقيقي يصلح لأي موقع استشارات أو خدمات، ويُضاف عبر إضافة مقتطفات الكود في قسم head من الصفحة. يسجّل أداتين: واحدة تشرح الخدمات، وثانية تجهّز طلب فحص من دون أن ترسل شيئاً تلقائياً:
if ("modelContext" in document) {
document.modelContext.registerTool({
name: "list_services",
description: "يعرض خدمات السيو ومحركات الإجابة المتاحة مع رابط كل خدمة",
inputSchema: { type: "object", properties: {} },
async execute() {
const links = [...document.querySelectorAll("nav a[href*='/']")]
.map(a => ({ title: a.textContent.trim(), url: a.href }));
return { content: [{ type: "text", text: JSON.stringify(links) }] };
}
});
document.modelContext.registerTool({
name: "prepare_audit_request",
description: "يجهّز رسالة طلب فحص سيو بموقع العميل ويعرضها للمستخدم ليؤكد الإرسال بنفسه",
inputSchema: {
type: "object",
properties: { site: { type: "string", description: "رابط موقع العميل" } },
required: ["site"]
},
async execute({ site }) {
const msg = "أريد فحص سيو لموقعي: " + site;
// نعرض الرسالة على الشاشة، والمستخدم هو الذي يضغط إرسال
showConfirmBox(msg);
return { content: [{ type: "text", text: "prepared, waiting for user confirmation" }] };
}
});
}
لاحظ أن الأداة الثانية لا ترسل شيئاً. تجهّز وتعرض وتنتظر. هذا هو الفرق بين أداة تخدم العميل وأداة تفتح باباً للإزعاج الآلي.
فحص سريع: من أين تبدأ في موقعك؟
الحدود والمخاطر بصراحة
لا أريدك أن تخرج من المقال وتعيد بناء موقعك حول معيار عمره ستة أشهر. هذه الحدود كما هي:
- ما زال تجريبياً: واجهة برمجية غيّرت اسمها مرة خلال نصف سنة تستطيع أن تتغير مرة ثانية. اكتب كودك مع فحص وجود الواجهة وخطة تراجع.
- لا يصل إلى كل الزوار: Chromium فقط اليوم، ولزوار يستخدمون مساعداً ذكياً. أغلب زوارك ما زالوا بشراً يقرؤون صفحاتك.
- لا يرفع ترتيبك في جوجل: WebMCP طبقة تنفيذ للمساعدات الذكية داخل المتصفح، وليس إشارة ترتيب. إذا أردت ظهوراً في نتائج البحث وإجابات الذكاء الاصطناعي، فالطريق ما زال المحتوى والبنية وتحسين محركات الإجابة.
- الأمان مسؤوليتك: المواصفة نفسها تفتح أسئلة عن التأكيد البشري والتدفق والتعرض للمساعد الذكي المدمج في المتصفح. أي أداة تكشفها هي باب جديد لموقعك، وحقن التعليمات (Prompt Injection) عبر محتوى الصفحة خطر حقيقي.
- مصمم ليبقى الإنسان مشرفاً (Human in the loop): المواصفة تستبعد صراحة المساعدات الذكية المستقلة كلياً والتصفح بلا واجهة. إذا كانت حالتك أتمتة خلفية، فـ MCP التقليدي هو مكانك.
الأسئلة الشائعة
هل WebMCP يغني عن MCP؟
لا. MCP يربط منصات الذكاء الاصطناعي بخوادمك من الخارج، و WebMCP يربط المساعد الذكي بصفحتك من الداخل بجلسة المستخدم. Cloudflare بنت جسراً يحوّل خادم MCP الموجود إلى أدوات WebMCP، وهذا يبيّن أنهما طبقتان مكمّلتان.
هل أحتاج إلى إعادة بناء موقعي؟
لا. تضيف ثلاث خصائص إلى نماذج HTML الموجودة، أو تغلّف دوال JavaScript الحالية بتعريف أداة. الواجهة البشرية تبقى كما هي، والمعيار يُضاف كتحسين تدريجي (Progressive Enhancement) يصمت في المتصفحات التي لا تدعمه.
هل يعمل على المنصات العربية مثل سلة وزد؟
حتى 2026-08-27 لا يوجد إعلان رسمي من سلة أو زد أو غيرهما من منصات المتاجر العربية عن دعمه. المتاجر على Shopify تحصل عليه تلقائياً، ومتاجر ووكومرس تستطيع إضافته بنفسها.
هل يؤثر على ترتيبي في جوجل؟
ليس إشارة ترتيب. هو طبقة تجعل المساعدات الذكية داخل المتصفح تنفّذ مهام على موقعك بدقة. الظهور في البحث وإجابات الذكاء الاصطناعي يبقى مرتبطاً بالمحتوى والبنية الدلالية والسكيما وتحسين محركات الإجابة.
هل هو آمن؟ ما الذي يمنع المساعد الذكي من الشراء من دون إذني؟
الأمان بيد المطوّر: النماذج بلا خاصية الإرسال التلقائي تُملأ ولا تُرسل إلا بضغطة المستخدم، والعمليات الحساسة تُصمم لتنتظر تأكيداً على الشاشة، والإذن يُقيّد بسياسة الصلاحيات. المواصفة ما زالت تناقش آلية تأكيد موحدة، فحتى تكتمل يبقى التأكيد مسؤولية الصفحة.
ما الفرق بين document.modelContext و navigator.modelContext؟
هما الواجهة نفسها. الاسم الأول ظهر في المعاينة المبكرة، ومع Chrome 150 انتقلت الواجهة إلى document.modelContext مع إبقاء الاسم القديم بديلاً مؤقتاً. المواصفة والأمثلة الحديثة تستخدم الجديد.
كيف أختبر أن أدواتي مسجلة بشكل صحيح؟
فعّل الخيار التجريبي chrome://flags/#enable-webmcp-testing وأعد تشغيل Chrome، ثم افتح تبويب WebMCP في DevTools لترى الأدوات ومخططاتها وتنفّذها يدوياً، وثبّت إضافة Model Context Tool Inspector لتجرّبها بلغة طبيعية.
هل يحل WebMCP محل ملف llms.txt؟
هما شيئان مختلفان: llms.txt ملف وصفي ثابت لا تستخدمه أنظمة الذكاء الاصطناعي الكبرى حتى الآن، و WebMCP واجهة تنفيذ حية داخل المتصفح. فريق بحث Google أبدى تفضيله للنهج الثاني لأن له أهدافاً وإجراءات واضحة.
مقالات تكمل الصورة
الخلاصة التي أريدك أن تخرج بها: WebMCP لا يطلب منك أن تصدّق وعداً، بل يطلب منك ثلاث أدوات مكتوبة بعناية وفحص وجود قبل التسجيل. من يبدأ الآن بهذه البساطة يكون جاهزاً يوم يصير المساعد الذكي هو العميل الأول على موقعه. وإذا أردت أن تعرف من أين تبدأ في موقعك تحديداً، تواصل معي.
المصادر
- المواصفة والشرح الرسمي لـ WebMCP، مجموعة Web Machine Learning في W3C: github.com/webmachinelearning/webmcp وwebmachinelearning.github.io/webmcp
- صفحة حالة الدعم الرسمية عبر المتصفحات: implementation-status.md
- توثيق Chrome للمطورين وإعلان المرحلة التجريبية (Origin Trial): developer.chrome.com/docs/ai/webmcp وai-webmcp-origin-trial
- مدونة Cloudflare: Give any website a WebMCP interface وBuilding an open Agentic Internet
- تغطية InfoQ لمعاينة Cloudflare: infoq.com
- تغطية VentureBeat لإعلان فبراير 2026: venturebeat.com
- أول تغطية عربية للإعلان، صحيفة سبق: sabq.org
- تعريفات TypeScript: webmcp-types على npm