WebMCP: تحويل محول الملفات إلى أداة يمكن لوكلاء الذكاء الاصطناعي استدعاؤها — WebConverter

ملاحظة المحرر (2026-05). أوقف Chrome 150 استخدام navigator.modelContext لصالح document.modelContext (بحسب طلب السحب رقم 184 لمواصفة WebMCP). تستخدم الأمثلة في هذه المقالة نمط الكشف عن الميزة المتوافق مع المستقبل الذي يوصي به فريق Chrome:

const modelContext = document.modelContext || navigator.modelContext;
if (modelContext) {
  // Register tools...
}

يستخدم تكامل WebConverter نفسه هذا النمط الاحتياطي بالضبط، لذا يستمر في العمل على المتصفحات التي لا تزال تستخدم المعرف القديم.

وحّد بروتوكول سياق النموذج (MCP) طريقة استدعاء وكلاء الذكاء الاصطناعي للأدوات. ويأخذ WebMCP هذه الفكرة إلى الويب المفتوح: بدلاً من عملية خادم منفصلة، يكشف الموقع نفسه أدوات عبر واجهة متصفح — document.modelContext — يمكن لوكيل داخل المتصفح اكتشافها واستدعاؤها. لقد أطلقنا للتو تكامل WebMCP لـ WebConverter، محوّلين كل تحويل يستطيع الموقع إنجازه إلى أداة قابلة لاستدعاء الوكلاء ولا تزال تعمل محلياً 100% في متصفحك.

ما هو WebMCP؟

WebMCP هو مسودة معيار ويب من مجموعة مجتمع تعلم الآلة على الويب في W3C، صممها مهندسون من Google وMicrosoft. يعرّف نقطة دخول جديدة واحدة على كائن navigator في المتصفح: document.modelContext. تستدعي الصفحة registerTool() لنشر أداة مسماة — مع وصف ومخطط JSON Schema لمدخلاتها — وتوفّر دالة execute() يستدعيها المتصفح (أو وكيل يعمل من خلاله) عند استدعاء الأداة.

الفرق الجوهري عن MCP الكلاسيكي: لا يوجد نقل منفصل، ولا خادم localhost، ولا رمز مميز للإدارة. الأداة هي شيفرة JavaScript الخاصة بالصفحة نفسها. ولمحول يضع الخصوصية أولاً يكون ذلك حاسماً — يحصل الوكيل على الصلاحية، لكن ملفك لا يغادر التبويب أبداً.

لماذا يهم "محول ملفات MCP"

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

الأدوات التي كشفناها

يسجّل WebConverter أداتين عبر document.modelContext: list_supported_formats، التي تُرجع صيغ الإدخال القابلة للقراءة وصيغ الإخراج القابلة للكتابة حتى يتمكن الوكيل من التخطيط لتحويل صالح؛ وconvert_image، التي تأخذ ملف base64 إضافة إلى صيغة مستهدفة وتُرجع الملف المحوَّل بصيغة base64 وعنوان data: URL. ولأن الأدوات تغلّف مسار Worker الموجود، فإن أي شيء يستطيع محول الصور فعله يستطيع الوكيل الآن فعله أيضاً.

كيف بنيناه

التكامل عبارة عن شيفرة صغيرة واحدة مؤجلة تُحمَّل على مستوى الموقع كاملاً. تعرّف واصفات الأدوات، وتسجّلها مع واجهة المعيار عندما يكون document.modelContext موجوداً، وتكشف أيضاً سجلاً برمجياً صغيراً يعكس نفس التعريفات — وصلة أتمتة موثّقة بحيث تكون الأدوات قابلة للاختبار وقابلة للاستخدام حتى على المتصفحات التي لم تُطلق الواجهة الأصلية بعد. كل ذلك مغلّف بحيث لا يمكن لـ Worker مفقود أو WASM محظور أن يطرح خطأً في الصفحة المضيفة، ولا يضيف سوى بضعة كيلوبايت — بدون أي WebAssembly جديد.

ملاحظة عن الثقة والأمان

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

جرّبه

افتح صفحة WebMCP لعرض حي يشغّل أداة convert_image، ومرجع كامل لمخططات الأدوات. إذا كنت تبني وكيلاً، فهذا ما تبدو عليه أداة تحويل ملفات صادقة وخاصة وبدون تكلفة — وهي مجرد صفحة ويب.