يرى وكيل المتصفح زرًا ويقدّر موضعه. قد ينجح ذلك. لكن تطبيق الويب يستطيع أيضًا أن يعبّر عن معناه بصورة أوضح: هذا الإجراء يبحث عن المواعيد المتاحة، ويتوقع تاريخًا، ويعيد قائمة. وهذا التحوّل تحديدًا من موضع النقر إلى أداة موصوفة هو ما يجعل WebMCP مثيرًا للاهتمام.
وفقًا للحالة الموثّقة، فإن WebMCP مقترح تجريبي. ويتناول المقال التوضيحي الحالي التسجيل الأمري عبر JavaScript و document.modelContext. أما أدوات النماذج التصريحية المستندة إلى HTML فتُستكشف بشكل منفصل، وليست حاليًا جزءًا من هذه المواصفة. لذلك فإن صفحة النظرة العامة الخاصة بـ Chrome المؤرخة في 18 مايو 2026 ليست سببًا لادعاء ميزة متصفح عامة جديدة في أكتوبر.
تبدأ الأداة بإجراء محدود
يحمل مثالنا الخاص اسم «العثور على المواعيد المتاحة». وتنتهي مهمته عند تقديم المعلومات. فهو لا ينشئ حجزًا. وينبغي أن يوضّح الوصف نفسه ذلك مسبقًا، حتى لا يحوّل الوكيلُ نتيجةَ بحث إلى موعد مؤكَّد.
يتضمن الإدخال تاريخًا وخدمةً معروضة. وتذكر النتيجة المرجع نفسه مع الفترات الزمنية المتاحة. أما قيمة معزولة مثل «10:30» فستكون أضعف: إذ قد تعود إلى يوم آخر أو خدمة أخرى. وتكون النتيجة المنظَّمة مفيدة بشكل خاص عندما يمكن تفسير مدخلاتها دون لبس.
{
"tool": "find_slots",
"input": {
"date": "2030-04-12",
"service": "intro"
},
"effect": "read_only"
}هذا مخططنا التعليمي، وليس تسجيلًا لـ WebMCP جاهزًا للنسخ. التاريخ المستقبلي والخدمة مختلَقان. وهو يبيّن العقد الذي يتعيّن على أي تنفيذ فعلي تحديده. أما بالنسبة إلى صيغة API الملموسة، فالمرجع المعتمد هو الوثائق التجريبية الحالية.
الأخطاء تحتاج أيضًا إلى معنى مفهوم
التاريخ غير الصالح، وعدم توفر مواعيد، وخدمة يتعذّر الوصول إليها لأسباب تقنية، هي ثلاث نتائج مختلفة. وإذا أفضت جميعها ببساطة إلى قائمة فارغة، فسيضطر الوكيل إلى تخمين السبب. لذلك ينبغي أن تحمل استجابة الأداة حالةً مفهومة والمعلومات اللازمة للقرار التالي.
وينطبق الأمر نفسه على المعلومات الجزئية. هل اكتمل البحث، أم أن بعض البيانات لا تزال ناقصة؟ هل تعود الاستجابة إلى أحدث طلب؟ هل غيّر الشخص التاريخ في هذه الأثناء؟ هذه الأسئلة قائمة بغضّ النظر عمّا إذا كانت الواجهة تُخاطَب عبر لقطة شاشة أو من خلال أداة.
الوصف ليس إذنًا
يحدّد مخطط الإدخال الصحيح الشكل الذي ينبغي أن يتخذه الطلب. لكنه لا يقرّر ما إذا كان يُسمح للجهة المستدعية بقراءة هذه المعلومات. ولا يزال على التطبيق أن يفرض قواعده الخاصة. فاسم الأداة الجذّاب ليس تسجيل دخول ولا تحكّمًا في الوصول.
ويحتاج الانتقال إلى الحجز أيضًا إلى معنى خاص به. فعبارتا «ابحث عن الأوقات المتاحة» و«احجز لي هذا الوقت» لهما عواقب مختلفة. ولا ينبغي أن تندمجا بصمت في وظيفة واحدة. وسيتعيّن على أي حجز فعلي أن يأخذ في الحسبان العنصر المؤكَّد والتعليمة المقصودة.
لذلك، لتمرين تصميمي أول غير مؤذٍ، تكفي بيانات نموذجية ثابتة. صِف ثلاث حالات للاستجابة، واستنتج الإجراء التالي المعقول في كل حالة. يتيح لك ذلك اختبار مدى وضوح العقد دون تزييف حجز حقيقي أو بيئة تشغيل قائمة لـ WebMCP.
WebMCP ليس تلقائيًا خادم MCP بعيدًا قائمًا
تظهر كلمة MCP في سياقات تقنية متنوعة. والإجراء الموصوف على جانب المتصفح ليس، لهذا السبب وحده، من نوع الاتصال نفسه الذي يمثّله خادم أدوات بعيد يمكن الوصول إليه عبر HTTP. وفي أي اتصال محدد، فإن ما يُعتدّ به هو العميل، وطريقة النقل، وتسجيل الدخول، والأدوات المعروضة فعليًا.
لذلك فإن وجود وصول بعيد قائم إلى MCP لا يثبت أن موقعًا إلكترونيًا يدعم WebMCP. وبالمثل، فإن مقترح متصفح تجريبيًا لا يضمن أن كل وكيل يستطيع استخدامه بالفعل. وهذا التمييز عملي: فهو يمنع تشابه الأسماء من أن يقود إلى خطة تكامل خاطئة.
يبقى السؤال القابل للتعميم واضحًا. هل يستطيع التطبيق أن يعبّر عن أيّ إجراء، وبأيّ مدخلات، يؤدي إلى أيّ نتيجة وأيّ أثر؟ وكلما كانت هذه الإجابة أدق، قلّ ما يتعيّن على الوكيل تخمينه من موضعٍ على الشاشة. فعقود الأدوات الجيدة تجعل هامش التصرّف أسهل فهمًا؛ ومع ذلك تظل قواعد التطبيق مسؤوليته هو.
المصادر والحالة
البحث والتوثيق حتى 25 أكتوبر 2026. WebMCP · المقال التوضيحي لـ WebMCP.
