۹۰ درصد سرورهای MCP برای به‌روزرسانی ژوئیه ۲۰۲۶ آماده نیستند

تصور کنید یک توسعه‌دهنده هستید که سال‌ها روی زیرساخت‌های اتصال مدل‌های زبانی کار کرده است و حالا متوجه می‌شود تقریباً تمام سرورهایش قرار است از کار بیفتند. این کابوس برای ۹۰.۸ درصد از سرورهای ثبت‌شده در پروتکل زمینه مدل (MCP) در راه است.

طبق گزارشی که در ۱۲ ژوئیه ۲۰۲۶ منتشر شد، تنها یک سرور از ۴۳۵۶ سرور قابل دسترس در فهرست رسمی، توانسته است تمام بررسی‌های آمادگی برای به‌روزرسانی ۲۸ ژوئیه ۲۰۲۶ را پاس کند. این داده‌ها از طریق mcp-spec-check استخراج شده است؛ یک ابزار کاوش تک‌طرفه (Black-box probing) که طراحی شده تا بررسی کند آیا نقاط انتهایی (Endpoints) راهکارمند برای انتقال به یک هسته بدون وضعیت (Stateless Core) را دارند یا خیر. این اسکن در مجموع، تمامی ۷۸۵۰ سرور موجود در رجیستری رسمی را پوشش داده است. اگرچه ابزار تنها یک حکم تک‌خطی (بله، خیر یا نامعلوم) صادر می‌کند، اما نتایج شکست‌ها تکان‌دهنده است؛ تنها سرورهایی که هر سه بررسی الزامی را با موفقیت پشت سر بگذارند، پاسخ «بله» دریافت می‌کنند.

اکوسیستم MCP اکنون با بزرگ‌ترین بازنگری خود از زمان عرضه مواجه است. برای درک مقیاس این تغییر، انتقال از حالت «با وضعیت» (Stateful) به «بدون وضعیت» (Stateless) را این‌گونه تصور کنید: شبیه این است که به‌جای یک تماس تلفنی طولانی که در آن هر دو طرف در جریان بحث هستند و خط باز می‌ماند، مجموعه‌ای از کارت‌پستال بفرستید که هر کدام از این پیام‌ها باید به طور کامل شامل این اطلاعات باشند که فرستنده کیست و پیام دقیقاً به کجا باید برسد. این اساس تغییر از نشست‌های Stateful به یک هسته Stateless است. این تحول معماری در واقع تلاشی برای رفع گلوگاه‌های عملیاتی است، مشابه آنچه در تسهیل مقیاس‌پذیری عامل‌های هوش مصنوعی از طریق معماری بدون وضعیت مشاهده شد.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی استانداردسازی ابزارهای هوش مصنوعی اشاره کردیم، سازگاری بین مدل‌ها و ابزارها همواره نقطه ضعف این بازار بوده است. به‌روزرسانی ۲۸ ژوئیه ۲۰۲۶ دقیقاً همین نقطه را هدف قرار داده است. این انتشار، یک چرخش معماری عظیم است. در این نسخه، دست‌دهی (Handshake) اولیه initialize و شناسه نشست (Mcp-Session-Id) به‌طور کامل حذف شده‌اند. به‌جای آن‌ها، پروتکل اکنون به هدرهای مسیریابی Mcp-Method و Mcp-Name نیاز دارد. این تغییرات به درگاه‌ها (Gateways) اجازه می‌دهد تا درخواست‌ها را با بهره‌وری بیشتری مسیریابی کنند. علاوه بر این، این به‌روزرسانی مکانیسم استخراج SSE را با درخواست‌های چند-سفری (Multi Round-Trip Requests یا MRTR) جایگزین می‌کند.

بر اساس مستندات mcp-spec-check، برای دریافت پاسخ «بله» (آماده)، یک سرور باید سه شرط غیرقابل مذاکره را پاس کند:

• discover: نقطه انتهایی server/discover باید به‌طور کامل جایگزین دست‌دهی قدیمی initialize شود.
• routing-headers: هدرهای Mcp-Method و Mcp-Name باید در تک‌تک درخواست‌ها برای مسیریابی در سطح Gateway حضور داشته باشند.
• session-independence: نشست‌های سطح پروتکل حذف شده‌اند. سرورهایی که به نشست‌ها (Pinned to sessions) وابسته هستند، نمی‌توانند در هسته بدون وضعیت پشت لود-بالنسرها (Load Balancers) فعالیت کنند.

علاوه بر این الزامات اصلی، انتشار نسخه ۲۸ ژوئیه ۲۰۲۶ چندین تغییر در سطح «هشدار» (Warning) را معرفی می‌کند. این موارد اختیاری یا آینده‌نگرانه هستند و به تنهایی باعث صدور حکم «آماده نیست» نمی‌شوند:

• کدهای خطا: کد resource-not-found از ۳۲۰۰۲- به ۳۲۶۰۲- تغییر شماره داده است.
• کشینگ (Caching): متادیتای جدید ttlMs و cacheScope به نتایج فهرست (List) و خواندن (Read) اضافه شده است.
• MRTR: به دلیل جایگزینی SSE با درخواست‌های چند-سفری، نتایج اکنون حاوی یک فیلد resultType هستند.
• احراز هویت (Auth): متادیتای منابع محافظت‌شده OAuth (مطابق RFC 9728) اکنون در مسیر /.well-known/oauth-protected-resource قابل کشف است.
• ویژگی‌های منسوخ شده: به سرورهایی که همچنان به قابلیت‌های Logging منسوخ شده یا resources/subscribe حذف شده وابسته هستند، هشدار داده می‌شود.

توسعه‌دهنده این ابزار برای تضمین صحت نتایج و جلوگیری از خطا در تشخیص، صحت کاوشگر را در یک خط لوله یکپارچه‌سازی مداوم (CI) مقابل دو سرور مرجع سنجیده است. این مرجع‌ها شامل یک سرور واقعی با مشخصات قدیمی (SDK v1 رسمی) و یک سرور RC (نسخه بتای SDK ژوئیه ۲۰۲۶) هستند. در هر بار بیلد (Build)، ابزار باید از طریق دستور npm run verify:refs دقیقاً احکام مورد انتظار را برای تمام هشت بررسی روی هر دو سرور تولید کند؛ در غیر این صورت، بیلد شکست می‌خورد. همچنین یک پنل «حقیقت شناخته‌شده» (Known-truth panel) سرورهای فعال تثبیت‌شده را بررسی می‌کند؛ برای مثال سرور MCP گیت‌هاب که دارای دیوارهای احراز هویت است، اما با موفقیت تست RFC 9728 را پاس می‌کند.

توسعه‌دهندگان می‌توانند با دستورات زیر سرورهای خود را تست کنند:

• npx mcp-spec-check <url>: گزارش قابل خواندن برای انسان به همراه یک نمره (Letter Grade) ارائه می‌دهد.
• npx mcp-spec-check <url> --json: خروجی ماشین-خوان برای استفاده در اسکریپت‌ها تولید می‌کند.
• npx mcp-spec-check <url> --verbose: دلیل دقیق (The Why) رد شدن یا پذیرش هر بررسی را توضیح می‌دهد.
• npx mcp-spec-check <url> --timeout 30000: زمان انتظار کاوشگر را تغییر می‌دهد (پیش‌فرض ۱۵۰۰۰ میلی‌ثانیه است).

برای سرورهای دارای احراز هویت، کاربران می‌توانند اعتبارنامه‌ها را از طریق --bearer <token> یا --header "X-Api-Key: k" ارسال کنند. بدون این‌ها، ابزار همچنان می‌تواند آمادگی را از طریق کاوش سطح منشأ (Origin-level) مطابق RFC 9728 سیگنال دهد، اما سایر بررسی‌ها به عنوان «skipped» علامت‌گذاری شده و کد خروجی ۲ بازگردانده می‌شود.

این تصویر کلی، شکاف عمیقی را بین تکامل پروتکل و پیاده‌سازی واقعی نشان می‌دهد. اگرچه متن رسمی مشخصات در ۲۸ ژوئیه به‌طور ناگهانی «کلید خاموشی» را نمی‌زند و ویژگی‌های منسوخ شده تا ۱۲ ماه باقی می‌مانند، اما واقعیت این است که SDKها و کلاینت‌ها از همین حالا در حال مهاجرت هستند. سرورهایی که هسته بدون وضعیت را نادیده بگیرند، با پنجره‌ای رو به بسته شدن در پشتیبانی مواجه خواهند شد زیرا اکوسیستم رو به جلو حرکت می‌کند.

برای توسعه‌دهندگان، این بدان معنای است که رجیستری «رسمی» فعلی تا حد زیادی یک نقشه قدیمی (Legacy) است. داده‌های کامل، شامل مخرج کسرها و نمای حساسیت‌های تجمیعی شده، در فایل‌های docs/scan-2026-07.md و scan-2026-07.aggregates.json در دسترس است. این حقیقت که تعداد بسیار کمی از سرورها استانداردهای جدید را برآورده می‌کنند، نشان می‌دهد که مهاجرت تازه آغاز شده است. ریسک فعلی، یک قطعی آنی نیست، بلکه یک لغزش آرام به سمت «منسوخ شدن» است، چرا که کلاینت‌ها دیگر از معماری‌های وابسته به نشست (Session-pinned) پشتیبانی نخواهند کرد.

برای توسعه‌دهندگان، این بدان معناست که رجیستری «رسمی» فعلی تا حد زیادی یک نقشه قدیمی (Legacy) است. داده‌های کامل، شامل مخرج کسرها و نمای حساسیت‌های تجمیعی شده، در فایل‌های docs/scan-2026-07.md و scan-2026-07.aggregates.json در دسترس است. این حقیقت که تعداد بسیار کمی از سرورها استانداردهای جدید را برآورده می‌کنند، نشان می‌دهد که مهاجرت تازه آغاز شده است. ریسک فعلی، یک قطعی آنی نیست، بلکه یک لغزش آرام به سمت «منسوخ شدن» است، چرا که کلاینت‌ها دیگر از معماری‌های وابسته به نشست (Session-pinned) پشتیبانی نخواهند کرد.

گام بعدی شما

• اگر سرور MCP دارید، فوراً با npx mcp-spec-check وضعیت آمادگی خود را بررسی کنید.
• اولویت را روی پیاده‌سازی نقطه انتهایی discover و حذف وابستگی به Session ID بگذارید.
• مستندات RFC 9728 را برای مدیریت منابع محافظت‌شده مطالعه کنید.

اما چالش اصلی، مدیریت حافظه در مدل‌های بدون وضعیت است — در تحلیل ما درباره استراتژی‌های جدید کشینگ در مدل‌های زبانی به این موضوع بپردازیم.