نسخه جدید MCP (۲۰۲۶-۰۷-۲۸): چه عوض شد و چه چیزی می‌شکند

نسخه جدید MCP در ۲۸ ژوئیه ۲۰۲۶ با نام ۲۰۲۶-۰۷-۲۸ منتشر شد و بزرگ‌ترین تغییرش این است که پروتکل «بدون حالت» شده: دست‌دهی اولیه و شناسه نشست حذف شده‌اند. برای کاربر عادی کاری لازم نیست. برای کسی که سرور MCP می‌نویسد یا میزبانی می‌کند، کدی که به نشست تکیه کرده باید مهاجرت کند. اطلاعات این صفحه تا ۱۹ اکتبر ۲۰۲۶ با منابع رسمی تطبیق داده شده است.

اگر هنوز با خود MCP آشنا نیستید، اول MCP چیست را بخوانید. سابقه نسخه‌های قبلی هم در تاریخچه نسخه‌های مشخصات MCP آمده است.

چه چیزی عوض شد

نگهدارندگان پروژه در اعلام نسخه کاندیدا آن را بزرگ‌ترین بازنگری پروتکل از زمان معرفی‌اش نامیده‌اند. اعلام رسمی انتشار را دیوید سوریا پارا و دن دلیمارسکی نوشته‌اند. نسخه کاندیدا در ۲۱ مه ۲۰۲۶ آمده بود و حدود ده هفته فرصت داد تا SDKها و سرورها آن را امتحان کنند.

مهم‌ترین تغییر، هسته بدون حالت است و بقیه روی آن سوار شده‌اند.

هسته بدون حالت

پیش از این، کلاینت اول initialize می‌فرستاد، سرور جواب می‌داد، کلاینت initialized را تأیید می‌کرد و از آن به بعد هدر Mcp-Session-Id همه چیز را به هم وصل می‌کرد. در نسخه جدید این رفت‌وبرگشت حذف شده است (SEP-2575 و SEP-2567).

حالا هر درخواست، نسخه پروتکل و قابلیت‌های کلاینت را در _meta با خودش می‌آورد، و کلاینت‌ها معمولاً نام و نسخه خودشان را هم زیر کلید io.modelcontextprotocol/clientInfo می‌فرستند. سرور می‌تواند هر درخواست را جدا بپذیرد یا با خطای UnsupportedProtocolVersionError رد کند. کلاینتی که بخواهد، یک بار قابلیت‌های سرور را با server/discover می‌پرسد. طبق صفحه نسخه‌بندی، پیاده‌سازی این متد برای سرور الزامی است و برای کلاینت اختیاری.

نتیجه عملی ساده است: هر درخواست می‌تواند به هر نمونه از سرور برسد. موازنه‌گر بار با روش نوبتی (round-robin) کافی است و ذخیره‌گاه مشترک برای نشست‌ها لازم نیست. میزبانی روی سرویس‌های ابری ارزان یا بدون سرور هم راحت‌تر می‌شود.

مهاجرت از نشست: حالت را کجا نگه دارید

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

این روش یک خطر تازه دارد. صفحه بهترین روش‌های امنیتی آن را «ربودن شناسه حالت» نامیده است: مهاجم شناسه را پیدا یا حدس می‌زند و به نام کاربر دیگری از آن استفاده می‌کند. مقابله‌اش این است:

• داشتن شناسه هرگز به معنای احرازهویت نیست؛ هر درخواست باید جداگانه اعتبارسنجی شود.
• شناسه را با مولد تصادفی امن بسازید، نه شمارنده ساده، و در صورت امکان انقضا بگذارید.
• شناسه را در سرور به کاربر تأییدشده گره بزنید، مثلاً با کلید <user_id>:<handle> که شناسه کاربر از توکن معتبر می‌آید نه از ورودی کلاینت.

درباره ابعاد دیگر امنیت در این اکوسیستم، امنیت و اعتماد در MCP را ببینید.

درخواست‌های چندمرحله‌ای به جای جریان باز

ابزارهایی که وسط کار از کاربر سؤال می‌کردند (elicitation) یا از مدل کمک می‌خواستند (sampling) یا فهرست پوشه‌ها را می‌گرفتند (roots)، به جریانی نیاز داشتند که باز بماند. در SEP-2322 همه این‌ها به الگوی «درخواست چندمرحله‌ای» تبدیل شده است. سرور نتیجه‌ای با resultType: "input_required" برمی‌گرداند و فهرست چیزهایی را که لازم دارد می‌گوید. کلاینت همان فراخوانی را دوباره می‌فرستد و پاسخ‌ها را در inputResponses می‌گذارد. هیچ اتصال بازی لازم نیست.

هدرها، کش و فهرست‌ها

برای دروازه‌ها و محدودکننده‌های نرخ، دو تغییر مهم است:

• درخواست‌های Streamable HTTP باید هدر Mcp-Method را داشته باشند، و فراخوانی ابزار و خواندن منبع و گرفتن پرامپت هدر Mcp-Name را هم لازم دارند (SEP-2243). با این هدرها دروازه یا WAF بدون خواندن بدنه JSON مسیر و محدودیت را تعیین می‌کند.
• پاسخ tools/list، prompts/list، resources/list و resources/read فیلدهای ttlMs و cacheScope دارند (SEP-2549) و ترتیب فهرست‌ها قطعی است. کلاینت می‌داند چه مدت فهرست را نگه دارد.

افزونه‌ها، وظایف و اعلان‌ها

قابلیت وظایف (Tasks) از هسته آزمایشی بیرون آمد و افزونه‌ای به نام io.modelcontextprotocol/tasks شد (SEP-2663). کار بلندمدت حالا با tasks/get و tasks/update پرسش‌محور است. اعلان تغییرها هم از نقطه GET قدیمی به جریان subscriptions/listen رفته است که کلاینت برای هر نوع اعلان جداگانه عضو می‌شود. چارچوب افزونه‌ها از Tasks، MCP Apps و Enterprise Managed Authorization نام می‌برد.

احرازهویت محکم‌تر

• سرور احرازهویت iss را طبق RFC 9207 در پاسخ برمی‌گرداند (فعلاً «توصیه می‌شود»، نه الزامی) و کلاینت باید پیش از فرستادن کد به نقطه توکن آن را بسنجد (SEP-2468). این کار جلوی حمله «اختلاط» را می‌گیرد.
• کلاینت‌ها هنگام ثبت پویا application_type را می‌فرستند تا نشانی بازگشت localhost برای برنامه‌های دسکتاپ و خط فرمان رد نشود (SEP-837).
• اعتبارنامه کلاینت به سرور صادرکننده‌اش گره خورده و روی سرور دیگری قابل استفاده نیست (SEP-2352).
• ثبت پویای کلاینت (DCR) رسماً منسوخ شده و جایش را Client ID Metadata Documents گرفته است. هنوز برای سازگاری کار می‌کند، اما اعلام رسمی می‌گوید در نسخه‌ای آینده حذف می‌شود.

منسوخ‌ها و پنجره دوازده‌ماهه

سه قابلیت Roots و Sampling و Logging (SEP-2577) و انتقال قدیمی HTTP+SSE منسوخ شده‌اند. سیاست تازه می‌گوید بین منسوخ شدن و حذف دست‌کم دوازده ماه باشد. این یعنی فعلاً همه کار می‌کنند، اما پیاده‌سازی تازه نباید روی آن‌ها بنا شود.

نوین و قدیمی: چه کسی با که کار می‌کند

صفحه نسخه‌بندی نسخه‌های ۲۰۲۶-۰۷-۲۸ به بعد را «نوین» و نسخه‌های ۲۰۲۵-۱۱-۲۵ و قدیمی‌تر را «قدیمی» می‌نامد. پیاده‌سازی که هر دو را بفهمد «دوره‌ای» است. جدول سازگاری ساده است:

• نوین با نوین، قدیمی با قدیمی و دوره‌ای با هر دو: کار می‌کنند.
• کلاینت نوین با سرور قدیمی: وصل نمی‌شود.
• کلاینت قدیمی با سرور نوین: وصل نمی‌شود و راه برگشت ندارد.

سرور دوره‌ای هر دو دوره را روی یک نشانی سرویس می‌دهد: درخواستی که _meta نوین دارد بی‌حالت جواب می‌گیرد و initialize به معنای رفتار قدیمی است.

SDKها و چه کسی باید نگران باشد

طبق اعلام رسمی، SDKهای رده یک، یعنی TypeScript، Python، Go و C#، از روز انتشار نسخه ۲۰۲۶-۰۷-۲۸ را پشتیبانی می‌کنند. SDK زبان Rust هنوز بتاست و در رده یک نیست. مهاجرت بیشتر آنجا سخت می‌شود که کد شما به شناسه نشست یا به سؤال و جواب وسط فراخوانی تکیه کرده باشد. اول نسخه SDK را بالا ببرید، بعد یادداشت‌های مهاجرت همان SDK را بخوانید و فقط جاهایی را عوض کنید که به نشست دست می‌زنند.

برای کسانی که از سرویس‌های ایرانی استفاده می‌کنند

اگر فقط سرور اضافه می‌کنید و از روتر MCP یا راه‌اندازی سریع استفاده می‌کنید، لازم نیست کاری بکنید. برای آشنایی با فرق MCP و فراخوانی تابع هم MCP یا function calling را ببینید.

یک نکته درباره خود پروژه. بررسی مخزن نشان می‌دهد روتر از قبل برای هر درخواست یک سرور و انتقال تازه می‌سازد و حالت نشست ندارد، یعنی با روح نسخه جدید هم‌خوان است. اما اینکه روتر یا سرورهای ما رسماً ۲۰۲۶-۰۷-۲۸ را پشتیبانی می‌کنند، هنوز راستی‌آزمایی نشده و ادعایش نمی‌کنیم. اگر سرور خودتان را می‌سازید، سازنده و راهنما نقطه شروع خوبی هستند.