WebMCP چیست؟ آماده‌سازی سایت برای عامل‌های هوش مصنوعی

مستندات Chrome که در ۷ اکتبر ۲۰۲۶ به‌روزرسانی شده‌اند، WebMCP را مسیری برای تعامل ساختارمند سایت و عامل معرفی می‌کنند. پیش‌نویس گروه جامعه وب نیز در ۲۷ اکتبر منتشر شده است. این دو نشانه، دلیل انتخاب موضوع در تحریریه سوشو هستند؛ نه ادعای رتبه اول جست‌وجو یا تضمین افزایش فروش.

برای یک کسب‌وکار، پرسش مفید این است: اگر کاربر از یک دستیار بخواهد خدمت مناسب را پیدا کند، چه کاری باید روی سایت قابل انجام باشد؟ پاسخ می‌تواند از یک جست‌وجوی ساده شروع شود. لازم نیست برای دنبال کردن این روند، کل سایت یا هویت بصری آن را عوض کنید.

در توضیح Chrome، سایت می‌تواند هدف یک قابلیت و ورودی‌های آن را روشن معرفی کند؛ مثلاً جست‌وجوی خدمت به‌جای زنجیره‌ای از کلیک‌های تفسیری. مسیرهای JavaScript و فرم HTML در این طرح مطرح‌اند. این قابلیت را باید ارتقای تدریجی تجربه بدانیم؛ فرم و دکمه برای بازدیدکننده انسانی همچنان لازم‌اند.

مثال فرضی ما یک سایت رزرو فضای کار است: کاربر می‌گوید «اتاق شش‌نفره برای سه‌شنبه می‌خواهم». ابزار جست‌وجو فقط گزینه‌های موجود را برمی‌گرداند. انتخاب نهایی، مشاهده شرایط و تأیید رزرو در تجربه‌ای روشن انجام می‌شود. این مثال پیشنهاد اجرایی سوشو است، نه گزارشی از یک پروژه انجام‌شده.

پیش‌نویس WebMCP درباره ابزارهایی است که برنامه وب در محیط صفحه ارائه می‌کند. این سند صریحاً استاندارد نهایی W3C نیست. بنابراین نباید یک اتصال آزمایشی مرورگر را به‌عنوان جایگزین قطعی API سرور یا قابلیتی همگانی در همه مرورگرها معرفی کرد.

تحلیل ما این است که «قابل استفاده بودن برای عامل» و «قابل پیدا شدن در جست‌وجو» دو هدف جدا هستند. برای سایت شما، متن روشن، لینک داخلی، HTML قابل خواندن و اطلاعات درست خدمت همچنان کار مستقل خود را دارند. ثبت یک ابزار به‌تنهایی دلیل کافی برای ادعای رشد رتبه یا ارجاع در پاسخ‌های AI نیست.

پیشنهاد سوشو این است که قبل از انتخاب کتابخانه، یک سناریو و معیار پذیرش بنویسید. مثلاً «عامل باید با نوع خدمت و شهر، سه گزینه مرتبط نشان دهد». سپس همان کار را یک بار با رابط معمولی و یک بار با مسیر ساختارمند بررسی کنید. هدف، دیدن خطاها و نقاط ابهام است؛ نه نمایش تعداد زیادی ابزار.

برای تیم کوچک، خروجی پایلوت می‌تواند یک گزارش کوتاه باشد: کدام درخواست‌ها درست انجام شدند، کجا ورودی ناقص بود و آیا کاربر توانست نتیجه را اصلاح کند؟ اگر مسئله اصلی سایت هنوز محتوای مبهم یا فرم خراب است، ابتدا همان مانع را برطرف کنید.

پیش‌نویس جامعه، موضوع‌هایی مانند تزریق دستور، نشت داده و ناهماهنگی با قصد کاربر را در بخش امنیت بررسی می‌کند. برداشت اجرایی ما این است که نام خوب ابزار کافی نیست: داده ورودی باید در سمت سرور اعتبارسنجی شود و دسترسی هر اقدام به حساب همان کاربر وابسته بماند.

در مثال رزرو، نمایش قیمت با ثبت نهایی رزرو یک عمل نیست. خلاصه انتخاب، هزینه و شرایط باید قبل از اقدام نهایی دیده شوند. برای شروع آزمایشی، داده ساختگی و حساب آزمایش استفاده کنید تا تیم بتواند رفتار اشتباه و لغو عملیات را بدون اثر واقعی بررسی کند.

مستندات فعلی Playwright برای WebMCP امکان فهرست کردن و فراخوانی ابزارها را توضیح می‌دهند و فعال‌سازی آزمایشی مرورگر را لازم می‌دانند. نام و خروجی ابزار هم داده قابل اعتماد ذاتی نیستند. این قابلیت تست را با آزمون معمول رابط انسانی ترکیب کنید؛ نام نسخه ابزار و مرورگر را در گزارش ثبت کنید.

اگر پایلوت مسئله واقعی را حل کرد، دامنه را یک قدم گسترش دهید. اگر فقط یک دموی جذاب شد، همان‌جا نگهش دارید. برای انتخاب مسیر اجرایی در سایت شما، ابتدا فهرست کارهای قابل انجام، سطح دسترسی و مسیر تأیید کاربر را آماده کنید؛ این اطلاعات پایه یک برآورد فنی قابل بررسی است.