تصور کنید یک عامل هوش مصنوعی را مدیریت می‌کنید که باید بین دو ابزار «خواندن فایل» و «خواندن متن فایل» یکی را انتخاب کند؛ اگر مدل این دو را یکی بداند، کل گردش کار شما با خطای Runtime متوقف می‌شود. این دقیقاً همان نقطه‌ای است که معیارهای ریاضی متداول برای سنجش شباهت، پاسخگو نیستند.
طبق گزارشی در dev.to، شباهت کسینوسی (Cosine Similarity) — که شبیه پیدا کردن دو نفر است که کلمات مشابهی به کار می‌برند اما لزوماً هدف یکسانی ندارند — برای جلوگیری از سردرگمی عامل‌ها در سرورهای پروتکل زمینه مدل (Model Context Protocol یا MCP) غیرقابل‌اعتماد است. در پوشش پیشین ما از امنیت مدل‌های بازمتن، دیدیم که دقت در تعریف ابزارها چقدر بر پایداری سیستم اثر می‌گذارد. در واقع، زمانی که یک سرور چندین ابزار با قابلیت‌های هم‌پوشان ارائه می‌دهد، عامل‌ها اغلب آرگومان‌های نامعتبر می‌سازند یا تابع اشتباهی را انتخاب می‌کنند. این چالش در مدیریت ابزارهای MCP، یادآور محدودیت‌های مشابهی است که در تحلیل شکست جست‌وجوی برداری در عامل‌های کدنویس بررسی کردیم، جایی که تکیه صرف بر بردارهای معنایی منجر به نادیده گرفتن ساختار دقیق کد می‌شد.
به نقل از این تحلیل، در ۲۹ ژوئیه ۲۰۲۶ یک آزمون تجربی روی سرور رسمی @modelcontextprotocol/server-filesystem انجام شد. نتایج نشان داد که بردارسازی استاندارد TF-IDF در آستانه ۰.۸۵، حتی یک جفت ابزار مشابه را هم شناسایی نکرد. دلیل این شکست ساده است: برای الگوریتم شباهت، دو ابزاری که کلمات «مسیر» (path) و «دسترسی» (permissions) را دارند، تقریباً یکسان هستند؛ حتی اگر یکی برای «خواندن» و دیگری برای «نوشتن» باشد. الگوریتم فعل کلیدی را یک جزئیات کوچک می‌بیند، در حالی که این تنها تفاوت حیاتی است. برای کاهش چنین خطاهایی در سطح اندپوینت‌ها، رویکرد استعلام پویا در برابر فهرست‌های ایستا راهکاری موثر برای حذف ابهامات در شناسایی ابزارها ارائه داده است.
برای حل این مشکل، رویکردی «ساختار-محور» با استفاده از ابزاری به نام mcplock پیشنهاد شده است. این مکانیزم در سه مرحله عمل می‌کند:
- جایگزینی طرح‌واره (Schema Substitutability): ابتدا بررسی می‌شود که آیا آرگومان‌های یک ابزار می‌تواند نیازهای ابزار دیگر را برآورده کند یا خیر. اگر طرح‌واره‌ها جایگزین‌ناپذیر باشند، ابزارها بلافاصله از لیست حذف می‌شوند.
- امتیاز نزدیکی (Affinity Scoring): جفت‌های باقی‌مانده بر اساس فاصله ویرایشی نام‌ها و پیشوندهای مشترک امتیاز می‌گیرند.
- وتوی فعل (Verb Veto): اگر توصیفات حاوی افعال متضاد (مثل ایجاد در برابر حذف) باشند، ابزارها فوراً رد می‌شوند.
بر اساس مستندات این پروژه، در سرور فایل‌سیستم که دارای ۱۴ ابزار و ۹۱ جفت متمایز است، لایه ساختاری توانست ۶۳ جفت را پیش از شروع امتیازدهی حذف کند. در نهایت، چهار جفت پرخطر (از جمله read_file و read_text_file) با امتیازاتی بین ۰.۴۲ و ۰.۴۸ شناسایی شدند؛ در حالی که جفت‌های غیرمشابه امتیازی زیر ۰.۳۲ گرفتند.
این تغییر متدولوژی، معیار بازرسی ابزارها را از «شباهت زبانی» به «سازگاری ساختاری» تغییر می‌دهد. با نادیده گرفتن واژگان تخصصی دامنه و تمرکز بر هم‌پوشانی طرح‌واره، توسعه‌دهندگان می‌توانند شکاف‌های مستنداتی را که منجر به شکست عامل در زمان اجرا می‌شود، پیدا کنند. البته نویسنده اشاره می‌کند که این روش فعلاً یک بررسی heuristic (تجربی) است و نه یک اثبات رسمی، بنابراین ممکن است ابهامات مربوط به محدوده (Scope) — مثل تفاوت خواندن یک فایل با خواندن تمام فایل‌های یک پوشه — را تشخیص ندهد. این تمرکز بر دقت اجرایی مشابه رویکردی است که در حالت /plan در Claude Code برای کاهش خطاهای بازسازی کد به کار گرفته شد.
گام بعدی شما
- ابزار mcplock را به عنوان یک lint check در خط فرمان (CLI) خود پیاده‌سازی کنید.
- از حالت diff مبتنی بر هش برای شناسایی تغییرات تعریف ابزارها پس از به‌روزرسانی سرور استفاده کنید.
- توصیفات ابزارهای MCP خود را با افعال متضاد و صریح بازنویسی کنید تا نرخ خطای عامل کاهش یابد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو