تصور کنید ابزاری می‌سازید که برای شما عالی کار می‌کند، اما برای هر کاربر جدیدی که آن را نصب می‌کند، در همان ثانیه اول کرش می‌کند. این کابوس فعلی بسیاری از توسعه‌دهندگان پروتکل زمینه مدل (Model Context Protocol یا MCP) است.
طبق تحلیل فنی منتشر شده در ۱۰ اوت ۲۰۲۶، حدود ۴۳٪ از سرورهای مبتنی بر پایتون در PyPI در یک سیستم تازه نصب شده، اصلاً اجرا نمی‌شوند. نکته عجیب این است که دلیل این شکست، باگ‌های پیچیده نیست، بلکه نبود یک کاراکتر ساده در تعریف وابستگی‌ها (Dependencies) است.
پروتکل زمینه مدل (MCP) به مدل‌های هوش مصنوعی اجازه می‌دهد تا به ابزارها و منابع داده خارجی متصل شوند. توسعه‌دهندگان برای ساخت این سرورها از MCP Python SDK استفاده می‌کنند. اما انتشار نسخه ۲.۰ این SDK، با حذف چندین API حیاتی، تغییراتی ایجاد کرد که با نسخه‌های قدیمی سازگار نبود (Breaking Changes).
همان‌طور که در بحث‌های گذشته ما درباره‌ی مدیریت وابستگی‌ها در پروژه‌های متن‌باز اشاره کردیم، عدم تعیین دقیق نسخه، منجر به ناپایداری سیستم می‌شود. به گزارش وب‌سایت dev.to، ریشه مشکل در استفاده از «پین‌های بدون سقف» است؛ مثلاً عبارتی مثل mcp>=1.0.0. وقتی کاربر جدیدی نصب را انجام می‌دهد، ابزار pip آخرین نسخه (یعنی ۲.x) را نصب می‌کند، در حالی که کد سرور برای نسخه ۱.x نوشته شده و بلافاصله پس از Import کرش می‌کند.
باگ نامرئی
این وضعیت تله‌ای برای توسعه‌دهندگان است. چون در سیستم محلی آن‌ها نسخه ۱.x از قبل کش (Cache) شده است، دستور pip install هرگز باعث ارتقای نسخه نمی‌شود. در نتیجه، سرور برای سازنده به‌درستی کار می‌کند، اما برای هر کاربر جدیدی خراب است. باگی که برای تنها کسی که می‌تواند آن را درست کند، نامرئی است.
متدولوژی بازرسی
پژوهشگر برای تضمین بازتولیدپذیری، از یک نمونه تصادفی با بذر (Seed) ۲۰۲۶۰۸۰۶ استفاده کرد:
- نمونه اولیه: ۳۰۰ بسته با نام «mcp» از میان تقریباً ۱۸,۰۰۰ بسته موجود در PyPI انتخاب شدند.
- فیلتر کردن: ۲۱۲ مورد به‌عنوان سرورهای واقعی MCP شناسایی شدند و مواردی که کلاینت، مستندات یا فورک (Fork) بودند، حذف شدند.
- میزان مواجهه: ۱۸۳ مورد از این بسته‌ها (۸۶.۳٪) SDK را بدون سقف نسخه تعریف کرده بودند. این عدد نشان‌دهنده «مواجهه» با ریسک است و لزوماً به معنای خراب بودن نیست.
- تأییدیه: ۳۰ مورد از این بسته‌های در معرض ریسک، در محیط‌های مجازی (Virtual Environments) کاملاً تازه نصب شدند تا شکست واقعی آن‌ها تست شود. این مرحله ضروری بود زیرا وجود SDK در کش سیستم، باگ را پنهان می‌کند.
برای تست این موارد، پژوهشگر نقاط ورود کنسول (Console Entry Points) هر بسته را یافت و آن‌ها را در حالی که ورودی استاندارد (stdin) بسته بود، اجرا کرد. موفقیت به معنای شروع برنامه بدون نمایش Traceback تعریف شد؛ در حالی که شکست به معنای نمایش فوری Traceback یا خروج بی‌صدا در هنگام رسیدن به EOF بود.
از ۲۸ بسته‌ای که با موفقیت نصب شدند (دو بسته اصلاً نصب نشدند)، ۱۴ مورد در هنگام اجرا شکست خوردند. این یعنی نرخ شکست حدود ۴۳٪ است (با فاصله اطمینان ۹۵٪ بین ۲۶ تا ۶۱ درصد). این بازه گسترده به‌دلیل کوچک بودن حجم نمونه نصب شده (n=30) است.
نقاط شکست رایج
کرش‌ها معمولاً در قالب سه خطای مشخص ظاهر می‌شوند:
ModuleNotFoundError: No module named 'mcp.server.fastmcp'ImportError: cannot import name 'McpError'AttributeError: 'Server' object has no attribute 'list_tools'
هر سه خطا نشان می‌دهند کدی که برای SDK نسخه ۱.x نوشته شده، سعی دارد روی نسخه ۲.x اجرا شود.
پارادوکس محبوبیت
به‌طور شگفت‌انگیزی، سرورهای شناخته‌شده متعلق به شرکت‌های بزرگ، عملکرد بدتری نسبت به پروژه‌های کوچک آخر هفته داشتند. در تست جداگانه‌ای روی ۲۳ سرور معروف، ۱۸ مورد از ۲۱ بسته‌ای که نصب شدند، کرش کردند؛ یعنی نرخ شکست ۸۶٪ در مقابل ۵۰٪ برای بسته‌هایی که به‌صورت تصادفی انتخاب شده بودند. این چالش‌های فنی در کنار مشکلات کاربردپذیری در سرورهای محبوب MCP، نشان می‌دهد که حتی پروژه‌های بزرگ نیز در استقرار صحیح با دشواری‌های جدی روبرو هستند.
این موضوع نشان می‌دهد محبوبیت با «قدمت» رابطه مستقیم دارد. بسته‌های قدیمی‌تر و پرکاربردتر در ابتدای مسیر با نسخه ۱.x نوشته شده‌اند و از زمان تغییرات نسخه ۲.۰، هرگز از صفر در یک محیط جدید نصب نشده‌اند تا توسعه‌دهنده متوجه مشکل شود. در واقع، محبوبیت از بسته محافظت نمی‌کند، بلکه احتمال اینکه بسته پیش از به‌روزرسانی SDK 2.0 نوشته شده باشد را افزایش می‌دهد.
متادیتا در برابر واقعیت
این موضوع یک شکست بحرانی در مدیریت وابستگی‌ها را برجسته می‌کند. پژوهشگر دریافت که روش‌های اکتشافی متادیتا (یعنی صرفاً چک کردن نبود سقف نسخه)، نرخ شکست را با نسبت ۴ به ۱ بیش از حد پیش‌بینی می‌کنند.
در تستی روی چهار مخزن متعلق به سازمان‌ها که بر اساس متادیتا «خراب» علامت‌گذاری شده بودند، تنها یکی واقعاً در محیط مجازی تازه شکست خورد. دو مورد با وجود نبود سقف نسخه، به‌درستی اجرا شدند و یکی به دلیلی کاملاً غیرمرتبط شکست خورد. به همین دلیل است که ابزار بازرسی به‌جای خواندن متادیتا، اقدام به نصب واقعی می‌کند.
راهکار و تأیید
برای رفع این مشکل، توسعه‌دهندگان باید پین‌های خود را از mcp>=1.0.0 به mcp>=1.0.0,<2 تغییر دهند. محدود کردن نسخه به زیر ۲.۰، در تمام سرورهای تست‌شده باعث بازگشت قابلیت اجرا شد.
توسعه‌دهندگان می‌توانند در حدود ۴ ثانیه با استفاده از یک محیط مجازی کاملاً جدید، بسته خود را تست کنند:python -m venv /tmp/checkme/tmp/checkme/bin/pip install your-package-name/tmp/checkme/bin/your-entry-point
محدودیت‌ها و داده‌ها
تست‌ها روی سیستم‌عامل ویندوز با پایتون ۳.۱۳ انجام شده و ممکن است نتایج در پلتفرم‌های دیگر متفاوت باشد. همچنین، معیار «شروع بدون Traceback» یک استاندارد حداقلی است و لزوماً صحت عملکرد کامل سرور را تضمین نمی‌کند. بسته‌هایی که تحت فرآیند افشای هماهنگ (Coordinated Disclosure) بودند، از این تحلیل حذف شدند. تمام ابزارها، از جمله نمونه‌گیر و نتایج خام JSON، در آدرس https://github.com/junaidshahid-dev/mcp-probe در دسترس است.
گام بعدی شما
- اگر توسعه‌دهنده MCP هستید، فوراً وابستگی‌های خود را در
pyproject.tomlیاsetup.pyبررسی کرده و سقف نسخه<2را اضافه کنید. - برای هر به‌روزرسانی حیاتی، یک محیط مجازی (venv) کاملاً جدید بسازید و نصب را از صفر تست کنید.
- از ابزار
mcp-probeبرای بررسی سلامت بسته‌های خود استفاده کنید.
اما این مشکل تنها بخشی از چالش‌های استقرار است؛ برای درک بهتر نحوه مدیریت نسخه‌ها در مقیاس صنعتی، تحلیل ما درباره استراتژی‌های Pinning را بخوانید. همچنین برای مدیریت امن‌تر دسترسی‌ها در محیط‌های عملیاتی، می‌توانید راهکار mcp-fabric-toolmesh برای نظارت بر عامل‌ها را بررسی کنید.
گفتگو