«نبودِ توصیفات دقیق»؛ نقطه‌ضعف سرورهای اتوماسیون گوگل و مایکروسافت

تصور کنید یک عامل هوش مصنوعی می‌خواهد یک پنجره پاپ‌آپ در وب‌سایت را ببندد. اگر توصیف ابزار browser_handle_dialog صراحتاً بیان نکند که ابتدا باید یک دیالوگ باز باشد، عامل ممکن است ابزار را زودتر از موعد فراخوانی کند و در یک حلقه بی‌پایان از خطاها بیفتد. این دقیقاً همان شکافی است که در «دست‌دادن» یا همان ارتباط بین سرور و مدل رخ می‌دهد و باعث شکست عملیات می‌شود.

طبق گزارش منتشر شده از ابزار Forecall، سرورهای Chrome DevTools MCP متعلق به گوگل و Playwright MCP متعلق به مایکروسافت، در ارائه راهنمای کافی برای عامل‌های هوش مصنوعی شکست خورده‌اند. این دو سرور به‌ترتیب امتیازهای ۴۵.۱ و ۴۱.۹ از ۱۰۰ را کسب کردند. Forecall یک لینتر (Linter) یا همان ابزار بررسی خطاهای کد است که توصیفات ابزارهای پروتکل زمینهٔ مدل (MCP) را بر اساس میزان کاربردی بودن برای مدل‌های زبانی بزرگ (LLM) — که شبیه کتابخانه‌داری هستند که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — ارزیابی می‌کند.

بسیاری از عامل‌ها برای تصمیم‌گیری درباره اینکه کدام تابع را فراخوانی کنند، صرفاً به نام ابزار، توصیف و طرح ورودی (Schema) تکیه می‌کنند. یک عامل ابتدا لیست ابزارهایی که سرور MCP برمی‌گرداند (نتیجه دستور tools/list) را می‌خواند و سپس تصمیم می‌گیرد کدام ابزار را با چه آرگومان‌هایی فراخوانی کند. وقتی توصیف یک ابزار فقط نام آن را تکرار می‌کند، عامل باید درباره مقدار بازگشتی یا شرایط خاص اجرای ابزار حدس بزند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، هرگونه ابهام در لایه‌ی ارتباطی می‌تواند منجر به رفتارهای پیش‌بینی‌ناپذیر مدل شود. در همین راستا، برخی حفره‌های امنیتی در متادیتای ابزارها می‌توانند به عنوان راه نفوذ به استدلال عامل‌های هوشمند مورد استفاده قرار گیرند.

کالبدشکافی امتیازات

در ۷ اکتبر ۲۰۲۶، سازنده Forecall فرآیند بررسی را روی نسخه ۱.۱۰.۱ سرور کروم (شامل ۳۰ ابزار) و نسخه ۰.۸۳ سرور پلی‌رایت (شامل ۲۵ ابزار) اجرا کرد. نتایج JSON به‌صورت محلی ذخیره شدند و در طول فرآیند امتیازدهی، هیچ ابزاری عملاً فراخوانی نشد. این لینتر توصیفات را بر اساس ۶ معیار کلیدی و قاعده‌مند ارزیابی می‌کند:

• هدف (۲۰ امتیاز): ابزار چه کاری انجام می‌دهد (فراتر از تکرار ساده نام ابزار).
• زمان استفاده (۲۰ امتیاز): چه زمانی باید از آن استفاده کرد و چگونه بین ابزارهای مشابه انتخاب کرد.
• آرگومان‌ها (۲۵ امتیاز): توصیف هر آرگومان، ذکر نوع داده (Type) و مشخص بودن اجباری یا اختیاری بودن آن.
• مقدار بازگشتی (۱۵ امتیاز): چه چیزی در خروجی برمی‌گردد (چه در طرح خروجی و چه در متن توصیف).
• محدودیت‌ها و اثرات جانبی (۱۰ امتیاز): پیش‌نیازهای اجرا و پیامدهای احتمالی پس از فراخوانی.
• مثال‌ها (۱۰ امتیاز): ارائه یک نمونه واقعی از نحوه فراخوانی ابزار.

این امتیازدهی کاملاً مبتنی بر قوانین است و فقط متن توصیفات و طرح‌ها را می‌خواند. یک ارزیابی مجدد در ۱۰ اکتبر با استفاده از نسخه ۲ قوانین، دقیقاً همان اعداد قبلی را تولید کرد.

نقاط ضعف غول‌های فناوری

هر دو سرور در بخش‌های «زمان استفاده» و «مقدار بازگشتی» عملکرد ضعیفی داشتند. به نقل از داده‌های Forecall، در سرور کروم ۲۴ ابزار از ۳۰ مورد، زمان استفاده را توضیح نداده بودند و ۲۷ ابزار مقدار بازگشتی را حذف کرده بودند. در سرور پلی‌رایت نیز ۲۳ ابزار از ۲۵ مورد در بخش زمان استفاده و ۲۱ ابزار در بخش خروجی مردود شدند.

ابزارهای کم‌امتیاز معمولاً توصیفاتی تک‌جمله‌ای داشتند که فقط نام تابع را تکرار می‌کرد. در سرور پلی‌رایت، ۱۴ ابزار از ۲۵ مورد به دلیل تکرار صرف نام ابزار علامت‌گذاری شدند. از جمله پایین‌ترین امتیازها می‌توان به موارد زیر اشاره کرد:

• در Chrome DevTools MCP (امتیاز ۳۱): ابزار drag («یک المان را روی المان دیگر بکشید»)، ابزار hover («روی المان ارائه شده نگه دارید») و ابزار upload_file.
• در Playwright MCP (امتیاز ۳۳): ابزار browser_handle_dialog («مدیریت یک دیالوگ»)، ابزار browser_navigate («رفتن به یک URL») و ابزار browser_type.

در مقابل، ابزارهای با امتیاز بالا، منطق تصمیم‌گیری واضحی ارائه دادند. ابزار fill_form در کروم با امتیاز ۷۲، به دلیل ارائه دستورالعمل صریح به عامل («همیشه هنگام تعامل با فرم‌ها، این ابزار را به جای چندین فراخوانی مجزای fill یا click ترجیح دهید») برای کاهش تعداد مراحل و افزایش پایداری، امتیاز بالایی گرفت. این ابزار حتی یک مثال عینی ارائه می‌دهد: «نام کاربری، رمز عبور و تیک Remember Me را در یک فراخوانی پر کنید». بهترین ابزار پلی‌رایت نیز browser_find با امتیاز ۶۶ بود که توضیح می‌دهد چه چیزی را جستجو می‌کند، چه چیزی برمی‌گرداند و چرا ارزان‌تر از گرفتن یک اسنپ‌شات کامل است.

پارادوکس جزئیات: وقتی توضیح زیاد، دقت را می‌کاهد

برای بررسی اینکه آیا امتیاز بالاتر منجر به عملکرد بهتر می‌شود، توصیف ابزار drag بازنویسی شد تا فقط بر اساس حقایق موجود در طرح (Schema) باشد. در این بازنویسی سه مورد اضافه شد: زمان استفاده (و تفاوتش با upload_file)، کارهایی که باید قبل از فراخوانی انجام شود و مقدار بازگشتی.

توصیف بازنویسی شده:
«یک المان را بکشید و روی المان دیگری در صفحه رها کنید. از این ابزار برای رابط‌های کاربری drag-and-drop مانند لیست‌های قابل مرتب‌سازی، تابلوهای کانبان و اسلایدرها استفاده کنید؛ برای ارسال فایل‌ها از کامپیوتر، به‌جای این ابزار از upload_file استفاده کنید. ابتدا یک اسنپ‌شات بگیرید و شناسه‌های (UID) هر دو المان را به عنوان from_uid و to_uid ارسال کنید. اگر includeSnapshot برابر true باشد، اسنپ‌شاتی از صفحه پس از رها کردن المان برمی‌گرداند.»

این تغییر امتیاز ابزار را از ۳۱ به ۷۴ رساند. بخش «زمان استفاده» به تنهایی ۲۰ امتیاز کامل را به دست آورد. جالب است که کلمه «رها کردن» (drop) باعث شد لینتر یک مورد جدید پیدا کند: ابزار ممکن است مخرب (destructive) باشد اما فاقد destructiveHint است. اگرچه لینتر اشتباه می‌کرد (چون drag مخرب نیست)، اما تنظیم destructiveHint: false در حاشیه‌نویسی‌ها، این مورد را بدون تغییر در امتیاز حل کرد.

اما در آزمایش روی مدل‌های پیشرو در ۸ تکلیف تک‌مرحله‌ای (شامل کارت‌های کانبان، منوهای hover و تولتیپ‌ها)، نتیجه غیرمنتظره بود. با توصیفات اصلی و کوتاه، هیچ مدلی ابزار اشتباه را انتخاب نکرد:

• Claude Code (مدل‌های Fable 5.1, Sonnet 5.5, Haiku 4.5): ۲۴ مورد از ۲۴ مورد درست.
• Codex CLI (مدل gpt-6-astra): ۱۱ مورد از ۱۱ مورد درست.
• فراخوانی‌های API (مدل‌های Opus 5.5, Sonnet 5.5, gpt-6-astra, gpt-6.1-sol): ۳۲ مورد از ۳۲ مورد درست.

در واقع، بازنویسی مفصل باعث شد دو مدل عملکرد بدتری داشته باشند:

• مدل gpt-5.6-luna در ۲ مورد از ۴ اجرا برای ناحیه آواتاری که «تصویر رها شده را می‌پذیرد»، به‌جای upload_file ابزار drag را فراخوانی کرد؛ احتمالاً به این دلیل که بیش از حد روی عبارت «رابط‌های کاربری drag-and-drop» تمرکز کرده بود.
• مدل gpt-6-astra در ۴ مورد از ۱۰ اجرا برای تکالیف «افزودن عکس» با متن جدید upload_file نتوانست ابزار درست را شناسایی کند (در حالی که با متن اصلی، ۰ مورد خطا داشت).

پایداری در بلندمدت

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

یک ارزیابی گسترده‌تر روی تمام ۳۰ ابزار Chrome DevTools MCP (با ۸ درخواست برای هر ابزار) نشان داد که Claude Sonnet 5.5 و GPT-6.1 Sol همچنان دقت بالایی دارند و در ۹۹٪ و ۹۸٪ موارد ابزار درست را انتخاب کردند. وقتی در یک درخواست شماره صفحه وجود نداشت، آن‌ها در ۷۷ تا ۸۷ درصد موارد به‌درستی ابتدا list_pages را فراخوانی کردند.

این موضوع نشان می‌دهد که مدل‌های پیشرو به‌طور فزاینده‌ای قادرند قصد کاربر را فقط از روی طرح (Schema) استنتاج کنند و توصیفات بیش از حد طولانی ممکن است به یک نقطه ضعف تبدیل شوند که مدل را به سمت ابزار اشتباه «بکشد». این چالش در طراحی لایه‌های ارتباطی، یادآور پیامدهای ترکیب طرح‌واره و هندلرهای اجرا است که می‌تواند منجر به ایجاد حفره‌های امنیتی خطرناک شود.

گام بعدی شما

برای توسعه‌دهندگانی که سرورهای MCP خود را می‌سازند، درس اصلی این است که از لینتینگ به عنوان نقشه‌ای برای یافتن شکاف‌ها استفاده کنند، اما با متن نهایی مانند یک ابرپارامتر (Hyperparameter) رفتار کنند. شما می‌توانید سرور خود را با این دستورات بررسی کنید:

npx forecall dump -o tools.json -- <command that starts your server>
npx forecall lint tools.json

همچنین می‌توانید عبارت --fail-under 60 را اضافه کنید تا اگر میانگین امتیاز کاهش یافت، فرآیند CI با خطا مواجه شود. برای تجربه مبتنی بر مرورگر، می‌توانید JSON یا URL سرور عمومی خود را در forecall.dev وارد کنید. نتایج کامل سرورهای تست شده در آدرس‌های forecall.dev/en/servers/chrome-devtools و forecall.dev/en/servers/playwright در دسترس است.

یک نکته مهم: امتیازها فقط از خواندن متن به دست می‌آیند. ابزاری مانند browser_close از روی نامش کاملاً واضح است اما امتیاز پایینی می‌گیرد. از امتیاز برای یافتن شکاف‌ها استفاده کنید، سپس هر بازنویسی را با مدل‌های واقعی تست کنید. با ابزارهای کم‌امتیاز شروع کنید، حقایق ضروری مانند مقادیر بازگشتی را اضافه کنید و متن را پیش از انتشار با مدل‌های خاصی که کاربران شما به کار می‌برند، تأیید کنید. برای مدیریت دقیق‌تر این دسترسی‌ها، می‌توان از روش‌هایی مانند تأیید مبتنی بر محدوده (Scope-based Grants) استفاده کرد تا دستورات AI در چارچوبی امن اجرا شوند.

به‌روزرسانی: نویسنده پیشنهادهای بازنویسی را در Issueهای microsoft/playwright-mcp#1788 و ChromeDevTools/chrome-devtools-mcp#3026 ارسال کرد. نگهدارنده Playwright این مورد را بست و درخواست کرد به‌جای امتیاز، یک مسیر خطای قابل تکرار (reproducible trajectory) در برابر یک مدل پیشرو ارائه شود. در مورد شماره ۳۰۲۶، نویسنده پس از آزمایشات فوق، این ادعا را که توصیفات کوتاه باعث سردرگمی مدل‌ها می‌شوند، پس گرفت.

من نویسنده Forecall هستم. این لینتر متن‌باز است: github.com/forecall/forecall-cli.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.