اگر یک عامل هوش مصنوعی در اجرای دستور شما شکست می‌خورد، احتمالاً مشکل از کدنویسی نیست، بلکه از «توضیحات» ابزار است. وقتی نام یا شرح یک تابع مبهم باشد، مدل یا ابزار اشتباه را انتخاب می‌کند و یا به‌کل از اجرای آن چشم‌پوشی می‌کند.
مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — برای تصمیم‌گیری به متون متکی است. در اکوسیستم پروتکل زمینهٔ مدل (MCP)، توصیفات ابزار صرفاً مستندات نیستند، بلکه رابط کاربری (Interface) واقعی هستند که مدل برای انتخاب مسیر استفاده می‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی «مالیات MCP» و افزایش هزینه‌های توکن اشاره کردیم، اکنون تمرکز از کمیت به کیفیت این تعاریف تغییر کرده است.
به گزارش وب‌سایت dev.to، در ۱۲ اکتبر ۲۰۲۶ یک روش عملی برای بازرسی این ناهماهنگی‌ها منتشر شد. این راهکار یک اسکریپت Node.js بدون وابستگی است که هر سرور MCP را اجرا کرده، دست‌دادن (Handshake) را انجام می‌دهد و تمام متادیتای ابزارها را برای بررسی انسانی استخراج می‌کند.
چک‌لیست بازرسی برای توسعه‌دهندگان
بر اساس مستندات این ابزار، توسعه‌دهندگان باید چهار نقطه شکست کلیدی را شناسایی کنند:
- توصیفات خالی: هر ابزاری که برچسب «بدون توصیف» دارد، مدل را مجبور به حدس زدن هدف ابزار می‌کند.
- نام‌های تکراری (Tautological): توصیفاتی مثل «get_user: دریافت کاربر» هیچ کاربردی ندارند. باید دقیقاً ذکر شود چه داده‌ای بازگردانده می‌شود و چه زمانی باید از این ابزار به‌جای ابزارهای مشابه استفاده کرد.
- پارامترهای تعریف‌نشده: هر ویژگی در طرح ورودی (inputSchema) باید دارای توصیف، واحد اندازه‌گیری و یک مثال عینی باشد.
- منطق هم‌پوشان: اگر دو ابزار مشابه به نظر می‌رسند، توصیفات باید صراحتاً بگویند: «از این ابزار برای X استفاده کنید، نه برای Y».
این تغییر دیدگاه، تعریف ابزار را به یک «خروجی محصول» تبدیل می‌کند. نویسنده این متد، ابزار MCP Tool Docs Generator را نیز منتشر کرده است؛ یک ابزار خط فرمان (CLI) که خروجی‌های بازرسی را به فایل‌های ساختاریافته‌ی TOOLS.md و tools.json تبدیل می‌کند تا در README پروژه‌ها قرار گیرند.
برای توسعه‌دهنده، این یعنی جایگزینی «تست حسی» (Vibe Check) با بازرسی سخت‌گیرانهٔ طرح‌ها. اگر یک عامل نتواند بین دو ابزار در یک متن ساده تفاوت قائل شود، قطعاً در محیط عملیاتی شکست خواهد خورد.
گام بعدی شما
- اسکریپت بازرسی را روی سرورهای محلی خود اجرا کنید تا «نقاط کور» توصیفات را بیابید.
- برای هر پارامتر ورودی، یک مثال واقعی (Concrete Example) در توصیفات اضافه کنید.
- توصیفات ابزارهای مشابه را بازنویسی کنید تا مرز استفاده از هر کدام شفاف شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو