تصور کنید ابزاری می‌سازید که قرار است دستیار هوشمند شما باشد، اما این دستیار هر بار در استفاده از ابزار شما گیج می‌شود چون دستورالعمل‌ها مبهم هستند. این دقیقاً همان بحرانی است که اکنون در اکوسیستم پروتکل زمینهٔ مدل (MCP) رخ داده است.
یک بررسی گسترده روی ۳۶ سرور محبوب MCP که در ۲۱ ژوئیه ۲۰۲۶ انجام شد، شکافی حیاتی را آشکار کرد: یک‌سوم این سرورها در واقع عامل‌هایی را که قرار بود تقویت کنند، ناامید می‌کنند. طبق گزارش منتشر شده، حتی اگر یک سرور از نظر فنی با استانداردها منطبق باشد، اگر مدل نتواند بفهمد «چگونه» از ابزار استفاده کند، آن ابزار عملاً بی‌فایده است. این موضوع یادآور چالش‌های پذیرش سرورهای MCP در مقیاس واقعی است که نشان می‌دهد سادگی فنی به تنهایی برای موفقیت این پروتکل کافی نیست.
همان‌طور که در تحلیل قبلی ما درباره‌ی چرخش راهبردی به سمت استانداردهای باز در MCP اشاره کردیم، اکنون متوجه می‌شویم که در دنیای عامل‌محور (Agentic)، مستندات دیگر برای برنامه‌نویسان انسان نیست؛ بلکه دستورالعمل‌هایی است که مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — برای تصمیم‌گیری می‌خواند.
برای سنجش این وضعیت، مهندسی به نام تنگ لی ابزاری به نام mcpgrade توسعه داد. این ابزار شبیه به Lighthouse در وب عمل می‌کند و سرورهای MCP را بدون نیاز به کلید API تحلیل می‌کند. تمرکز این ابزار روی یک نقطه کور است: نه شکل JSON-RPC یا توافق قابلیت‌ها، بلکه شفافیت نام‌گذاری و توصیفات برای مدل.
پارادوکس تطابق فنی
بر اساس مستندات tengli.dev، سرورها می‌توانند ۱۰۰٪ با استانداردها منطبق باشند اما همچنان غیرقابل‌استفاده بمانند. مشکل به‌ندرت در لایه پروتکل است و تقریباً همیشه در بخش‌هایی است که هیچ «لینتری» (Linter) یا ابزار بررسی املایی برای آن‌ها وجود ندارد. کاربردپذیری برای عامل‌ها بیشتر یک مسئلهٔ نویسندگی است تا یک مسئلهٔ مهندسی.
این تضاد در مقایسه سرورهای قدیمی و جدید به‌وضوح دیده می‌شود. برخی پیاده‌سازی‌های مرجع قدیمی که دیگر به‌روزرسانی نمی‌شوند، اما هنوز نصب هستند، عملکرد بهتری نسبت به سرورهای تجاری مدرن دارند؛ چون در آن زمان توصیفات ابزارها و پارامترها به‌صورت دستی و دقیق نوشته می‌شد.
- عملکرد عالی (رتبه A): ۱۵ سرور از ۳۶ مورد نمرات بالایی گرفتند. این لیست شامل exa، perplexity-ask، tavily، airbnb، figma-developer-mcp، elastic، @shopify/dev-mcp، @apify/actors-mcp-server و shrimp-task-manager است. همچنین سرورهای آرشیوی مثل brave-search، google-maps، slack و gitlab رتبه A گرفتند.
- عملکرد ضعیف (رتبه D/F): ۱۱ سرور، از جمله محصولات تجاری رسمی، با مشکل مواجه بودند. سرور رسمی MongoDB با ۶۶ خطا، Notion با ۶۲ خطا و Airtable با ۶۹ خطا ثبت شد. سرور todoist-mcp-server ۱۱۰ خطا داشت و نسخه آرشیوی GitHub ۴۴ خطا ثبت کرد.
- پایین‌ترین سطح: سرور firecrawl-mcp با امتیاز ۵۷ و ۱۳۴ خطا در ته جدول قرار گرفت. دو سرور Stripe و Supabase به‌دلیل عدم امکان اسکن با اعتبارنامه‌های جعلی، از رتبه‌بندی خارج شدند.
اپیدمی پارامترهای بدون مستندات
عامل اصلی شکست، فقدان سیستماتیک توصیفات پارامترها است. به‌ویژه قانون D004 (پارامتر بدون توصیف) بیشترین تکرار را در گزارش‌ها داشت. این یعنی مدل نام پارامتر و نوع آن را می‌بیند، اما هیچ ایده‌ای ندارد که چگونه از آن استفاده کند.
برای مثال، ۱۳۲ مورد از ۱۳۴ خطای firecrawl مربوط به پارامترهای بدون توصیف مثل url و formats بود. Todoist نیز ۱۱۰ خطای مشابه داشت. به نقل از تنگ لی، ریشه این مشکل در تولید خودکار طرح‌واره‌ها (Schema Generation) است. بسیاری از توسعه‌دهندگان از zod یا تعاریف OpenAPI استفاده می‌کنند اما فراموش می‌کنند متدهای .describe() را اضافه کنند. در نتیجه، سیستم می‌داند متغیر یک «رشته» (String) است، اما مدل نمی‌داند فرمت یا محدودیت‌های آن رشته چیست.
از بررسی ایستا به پاسخ‌های اشتباه
برای اثبات اهمیت این امتیازات، لی قابلیت --eval را اضافه کرد تا سناریوهای واقعی را تست کند. نتایج این ارزیابی زنده نگران‌کننده است:
۱. سقوط در انتخاب ابزار: در حالی که سرورهای مستند ۱۰۰٪ دقت داشتند، دقت firecrawl به ۸۴٪ رسید. مدل به‌دلیل نام‌های مشابه، ابزارهای extract و scrape را با هم اشتباه می‌گرفت.
۲. بحران پذیرش: خطرناک‌ترین حالت زمانی است که مدل نباید ابزاری را اجرا کند اما این کار را می‌کند. در کاتالوگ‌های کوچک و تمیز، مدل‌ها ۱۰۰٪ درخواست‌های خارج از دامنه را رد کردند. اما در کاتالوگ ۲۶ ابزاری و مبهم firecrawl، نرخ رد درخواست به ۵۰٪ رسید؛ یعنی نیمی از اوقات مدل ابزاری را «پیدا کرد» و اجرا کرد، در حالی که باید هیچ کاری انجام نمی‌داد.
معماری یک سرور «خوب»
بر اساس داده‌های برترین‌ها، یک چک‌لیست برای قابلیت اطمینان عامل‌ها پیشنهاد می‌شود:
- توصیف ابزار: هر توصیف باید به سه سوال پاسخ دهد: چه می‌کند، چه زمانی استفاده شود و چه چیزی برمی‌گرداند.
- شفافیت پارامتر: هر پارامتر باید توصیفی شامل فرمت و حداقل یک مثال داشته باشد.
- تایپینگ سخت: مقادیر ثابت باید در
enumباشند، نه در توصیفات متنی. - اعلام صریح: فیلد
requiredباید صراحتاً تعریف شود، حتی اگر خالی باشد. - نظم در نام‌گذاری: استفاده از سبک
verb_objectو پرهیز از نام‌های دوقلو. - بازخورد خطا: خطاها باید دقیقاً نام پارامتر نامعتبر را ذکر کنند تا مدل بتواند در همان لحظه خود را اصلاح کند.
این سطح از نظم نادر است. داده‌ها نشان می‌دهند که هرچه تعداد ابزارها بیشتر شود، تلاش لازم برای مستندسازی به‌صورت خطی افزایش می‌یابد. برای توسعه‌دهندگانی که عامل می‌سازند، این یعنی «قرارداد» بین سرور و عامل بسیار شکننده است. در همین راستا، ابزارهایی مانند mcpward برای تثبیت قراردادهای سرور توسعه یافته‌اند تا از تغییر رفتار ناگهانی عامل‌ها جلوگیری کنند. صرفِ زمان برای نوشتن توصیفات دقیق در طرح‌واره، بیشترین تأثیر را بر پایداری سیستم دارد.
توسعه‌دهندگان اکنون می‌توانند سرورهای خود را با دستورات mcpgrade تست کنند: برای محیط محلی npx mcpgrade --stdio "node ./my-server.js" و برای HTTP npx mcpgrade https://my-server.example/mcp. این ابزار شامل ۲۴ قانون است که برای هر کدام راهکار اصلاحی ارائه می‌دهد.
گام بعدی شما
- اگر سرور MCP توسعه می‌دهید، فوراً ابزار mcpgrade را روی پروژه خود اجرا کنید تا نقاط کور توصیفات را بیابید.
- در طرح‌واره‌های خود، تمام پارامترهای ورودی را با متد
.describe()مجهز به مثال‌های واقعی کنید. - نام ابزارها را از حالت کلی خارج کرده و به فرمت «فعل_مفعول» (مثلاً
get_user_details) تغییر دهید.
اما این نقص در لایه نرم‌افزاری است؛ چالش‌های سخت‌افزاری و تأخیر در استنتاج این پروتکل‌ها در مقیاس بالا، موضوع تحلیل بعدی ماست.
گفتگو