درون تغییرات معماری MCP v2 برای سازگاری با زیرساخت‌های بدون سرور

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

پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) — که شبیه به یک مترجم استاندارد برای فهم متقابل مدل‌های زبانی و ابزارهای خارجی عمل می‌کند — در نسخه ۲ معماری خود را به‌طور کلی تغییر داد. در حالی که نسخه اصلی MCP بر یک هسته دارای وضعیت (stateful) متکی بود، نسخه ۲ در حال حذف کامل این معماری است. با حذف فرآیند دست‌دادن (handshake) و شناسه‌های جلسه (session IDs) که پیش از این کلاینت‌ها را به نمونه‌های خاصی از سرور می‌چسباند، این پروتکل اکنون مقیاس‌پذیری افقی گسترده را امکان‌پذیر می‌کند.

این چرخش معماری دقیقاً زمانی رخ می‌دهد که توسعه‌دهندگان از مرحله ساخت پروتوتایپ‌های اولیه به سمت زیرساخت‌های هوش مصنوعی در سطح تولید (production-grade) حرکت می‌کنند. اکثر پیاده‌سازی‌های نسخه ۱ به یک اتصال پایدار وابسته بودند که در محیط‌های بدون سرور (serverless) ایجاد گلوگاه می‌کرد. اگر می‌خواستید یک سرور v1 را مقیاس کنید، به «جلسات چسبنده» (sticky sessions) نیاز داشتید تا اطمینان حاصل کنید کلاینت همیشه به همان پردازشی بازمی‌گردد که وضعیت جلسه (session state) او را در حافظه داشت. این رویکرد به ما اجازه می‌دهد تا ابزارهای پیشرفته‌تری بسازیم، مشابه آنچه اپل در پیش‌نمایش ۲۴۷ سافاری برای اتوماسیون عیب‌یابی وب پیاده‌سازی کرده است.

طبق یک راهنمای فنی که در ۱۷ جولای ۲۰۲۶ در وب‌سایت dev.to منتشر شد، مشخصات نسخه ۲ (بازبینی پروتکل ۲۰۲۶-۰۷-۲۸) در تاریخ ۲۸ جولای ۲۰۲۶ نهایی می‌شود. نسخه کاندید (release candidate) برای این ورژن در ۲۱ می ۲۰۲۶ قفل شد و یک پنجره اعتبارسنجی ده هفته‌ای را آغاز کرد؛ دوره‌ای که در آن نگهدارندگان SDKها، پروتکل را در برابر بارهای کاری واقعی آزمایش می‌کنند تا پیش از انتشار نهایی مشخصات، تمام نقاط ضعف برطرف شود. این یک وصله (patch) جزئی نیست؛ بلکه یک بازنویسی بنیادین در نحوه ارتباط کلاینت‌ها و سرورهاست تا تضمین شود هر درخواست می‌تواند توسط هر نمونه سرور در دسترس، پاسخ داده شود.

گذار به وضعیت بدون وضعیت (Statelessness)

بزرگ‌ترین تغییر در نسخه ۲ این است که پروتکل به‌طور کامل «بدون وضعیت» یا Stateless می‌شود. در نسخه ۱، هر جلسه با یک دست‌دادن initialize / initialized آغاز می‌شد و سرور یک Mcp-Session-Id صادر می‌کرد که کلاینت باید آن را در هر درخواست بعدی ارسال می‌کرد. این مکانیسم به‌طور مؤثر کلاینت را به یک نمونه خاص از سرور متصل نگه می‌داشت.

در نسخه ۲، پروتکل این دست‌دادن و هدر Mcp-Session-Id را حذف می‌کند. در عوض، اطلاعات کلاینت اکنون در فیلدهای _meta در هر درخواست مجزا منتقل می‌شود؛ این یعنی هر درخواست به‌طور کامل خودکفا (self-contained) است و به اطلاعات درخواست‌های قبلی نیاز ندارد.

برای کمک به زیرساخت‌های شبکه جهت مسیریابی این درخواست‌ها بدون نیاز به تجزیه و تحلیل (parsing) کل بدنه پیام، پروتکل دو هدر عملیاتی جدید به نام‌های Mcp-Method و Mcp-Name معرفی کرده است. علاوه بر این، متادیتای مربوط به کشینگ — به‌ویژه ttlMs (زمان ماندگاری به میلی‌ثانیه) و cacheScope (محدوده کش) — اکنون مستقیماً در ساختار پروتکل جای‌گذاری شده است.

حذف‌های عمده و جایگزین‌ها

از آنجایی که نسخه ۲ فرضِ وجود یک اتصال طولانی‌مدت را حذف می‌کند، سه زیرسیستم کلیدی در حال بازنشستگی (deprecation) هستند. طبق سیاست‌های جدید چرخه عمر، «بازنشسته شده» به معنای حذف فوری نیست. هر زیرسیستم در یک دوره گذار یک‌ساله (grace period) فعال می‌ماند تا سرورهای فعلی نسخه ۱ همچنان کار کنند، اما تمام کدهای جدید باید از جایگزین‌ها استفاده کنند.

۱. نمونه‌برداری (Sampling)

• چیستی: نمونه‌برداری به سرور اجازه می‌داد تا از مدل زبانی (LLM) کلاینت بخواهد در میانه‌ی اجرای یک عملیات، متنی تولید کند (از طریق createMessage در SDK تایپ‌اسکریپت). این قابلیت، «سرورهای عامل‌محور» (agentic servers) را فعال می‌کرد که می‌توانستند با قرض گرفتن مدل کلاینت، استدلال داخلی انجام دهند.
• دلیل حذف: نمونه‌برداری نیازمند این است که سرور در حالی که فعالانه در حال مدیریت یک درخواست نیست، به سمت کلاینت درخواست بفرستد. این کار تنها در اتصالات پایدار و دارای وضعیت امکان‌پذیر است — دقیقاً همان فرضی که نسخه ۲ آن را حذف می‌کند. در دنیای بدون وضعیت، سروری که در حال پردازش یک درخواست است، ممکن است همان سروری نباشد که اتصال اولیه با کلاینت را برقرار کرده است.
• جایگزین: توسعه‌دهندگان باید به سمت ادغام مستقیم با APIهای ارائه‌دهندگان LLM (مانند Anthropic یا OpenAI) حرکت کنند. با فراخوانی مستقیم ارائه‌دهنده از داخل سرور، سرور بر مدل، کلیدهای دسترسی و هزینه‌ها کنترل کامل دارد. برای مواردی که ورودی کلاینت در میانه‌ی یک وظیفه واقعاً ضروری است، از الگوی InputRequiredResult استفاده می‌شود. در این الگو، سرور نتیجه‌ای برمی‌گرداند با این مضمون که «من به این ورودی نیاز دارم» و کلاینت درخواست را مجدداً با ارسال پاسخ تکرار می‌کند. چون هر رفت‌وبرگشت یک درخواست تازه است، هر نمونه سرور می‌تواند آن را مدیریت کند.

۲. ریشه‌ها (Roots)

• چیستی: ریشه‌ها شناسه‌های URI بودند که توسط کلاینت ارائه می‌شدند تا محدوده عملیاتی سرور را تعیین کنند (مثلاً file:///home/user/my-project برای اینکه به یک سرور تحلیل کد گفته شود کدام دایرکتوری را اسکن کند). سرورها از طریق listRoots() به این اطلاعات دسترسی داشتند.
• دلیل حذف: ریشه‌ها در واقع وضعیت‌های وابسته به جلسه (session-scoped state) بودند که از کلاینت ارسال شده و تا پایان عمر یک اتصال نگه داشته می‌شدند.
• جایگزین: این اطلاعات اکنون باید به‌صورت صریح در هر درخواست ارسال شوند. این کار از سه طریق امکان‌پذیر است:
  • پارامترهای ابزار: پذیرش دایرکتوری کاری یا محدوده به عنوان یک ورودی مستقیم در ابزار.
  • URIهای منابع: کدگذاری محدوده مستقیماً در منبعی که درخواست می‌شود.
  • پیکربندی سرور: تعیین مرزها در زمان استقرار برای محدوده‌های استاتیک.

۳. پایش (Logging)

• چیستی: پیام‌های لاگ ساختاریافته که از سرور به کلاینت از طریق پروتکل MCP ارسال می‌شد و توسط کلاینت از طریق logging/setLevel فیلتر می‌شد.
• دلیل حذف: لاگ‌گیری در سطح پروتکل، قابلیت مشاهده (observability) را به یک اتصال زنده گره می‌زد که برای استقرارهای بدون وضعیت و چند-نمونه‌ای (multi-instance) غیرعملی است و همچنین ابزارهای موجود در صنعت را تکرار می‌کرد.
• جایگزین:
  • stderr: برای انتقال‌های stdio، سرورها باید لاگ‌ها را در خروجی خطای استاندارد بنویسند تا میزبان (host) آن‌ها را ثبت کند (این مورد در نسخه ۱ هم توصیه شده بود زیرا stdout برای پروتکل رزرو شده است).
  • OpenTelemetry (OTel): برای مشاهده‌پذیری در سطح تولید، سرورها باید ردهای (traces) و متریک‌های خود را به یک خط‌لوله OTel ارسال کنند، به جای اینکه آن‌ها را از طریق MCP منتقل کنند.

تأثیر بر SDKها

این تغییرات را در SDKهای TypeScript، Python، Go و C# بازتاب می‌دهد. در حالی که SDKهای نسخه ۲ هنوز در حال تثبیت هستند، سه الگوی ثابت در تمام زبان‌ها ظاهر شده است:

اول، لایه‌های انتقال (transports) در حال تغییر شکل هستند. حذف جلسات یک تغییر در سطح لایه انتقال است. انتظار می‌رود انتقال‌های HTTP تغییر نام دهند یا بر اساس زمان اجرا (runtime) تقسیم شوند. انتقال قدیمی SSE — که طراحی دو-نقطه ای بر پایه یک جریان پایدار بود — احتمالاً ناپدید خواهد شد، زیرا یک جریان طولانی‌مدت با مدل بدون وضعیت همخوانی ندارد و در عوض، یک انتقال یکپارچه درخواست/پاسخ (request/response) جایگزین آن می‌شود.

دوم، مدیریت خطاها دقیق‌تر (granular) می‌شود. نسخه ۲ یک خط کشنده بین «خطاهای پروتکل» (جایی که خود درخواست بدشکل بوده و طرف مقابل باید خطا را ببیند) و «خطاهای محلی SDK» (مانند قطع شدن اتصال HTTP) می‌کشد. توسعه‌دهندگانی که انواع خطاها را بازرسی می‌کنند، باید انتظار داشته باشند که این تفکیک در APIها ظاهر شود.

سوم، کانتکست درخواست‌ها «آگاه به لایه انتقال» (transport-aware) می‌شود. از آنجایی که یک سرور stdio فاقد درخواست HTTP است، شیء کانتکست در هر درخواست اکنون فیلدهای سطح پروتکل را از فیلدهای خاص لایه انتقال (مانند اطلاعات احراز هویت مخصوص HTTP) جدا می‌کند. هندلرهای درخواست اکنون باید این فیلدهای اختیاری را به صورت تدافعی (defensively) بخوانند.

معرفی افزونه‌ها (Extensions)

نسخه ۲ تنها حذف‌کننده نبود، بلکه «افزونه‌ها» را به عنوان اجزای درجه اول پروتکل رسمیت بخشید. افزونه‌ها اکنون از شناسه‌های DNS معکوس (reverse-DNS) و نسخه‌بندی مستقل استفاده می‌کنند. این امر اجازه می‌دهد ویژگی‌ها به عنوان افزونه‌های نسخه‌دار تکامل یابند بدون اینکه نیاز به بازبینی کل مشخصات پروتکل باشد.

دو افزونه رسمی همراه با نسخه ۲ عرضه می‌شوند:

۱. MCP Apps: این افزونه‌ها رابط‌های کاربری رندر شده توسط سرور را فراهم می‌کنند و به سرور اجازه می‌دهند به جای بازگرداندن صرفاً داده‌های ساختاریافته و متن، یک رابط غنی را به کاربر ارائه دهد. این رویکرد با چارچوب‌های اصلی رابط کاربر در پشتیبانی از mcp-elements هم‌سو است تا تجربه بصری بهتری ایجاد شود.
۲. Tasks: این افزونه یک الگوی استاندارد برای عملیات‌های طولانی‌مدت معرفی می‌کند. سرور می‌تواند کاری را آغاز کند که عمرش بیشتر از یک درخواست تک باشد و وضعیت آن را گزارش دهد. از آنجایی که تسک‌ها در تمام نمونه‌های سرور قابل شناسایی هستند، به طور طبیعی با هسته بدون وضعیت جفت می‌شوند.

زمان‌بندی مهاجرت

تا اوایل جولای ۲۰۲۶، SDKهای نسخه ۲ در وضعیت بتا هستند. SDKهای تایپ‌اسکریپت و پایتون در وضعیت بتا قرار دارند، در حالی که نسخه‌های Go و C# در مراحل پیش-انتشار (pre-release) یا پیش‌نمایش هستند. تیم MCP صراحتاً اعلام کرده است: «برای هر بار کاری حیاتی، نسخه‌های Stable SDK همچنان نسخه‌های توصیه شده هستند» و «APIهای عمومی ممکن است بین نسخه‌های بتا و انتشار نهایی تغییر کنند».

ارتقای SDK به طور خودکار سرور را به رفتار نسخه ۲ منتقل نمی‌کند؛ این یک فرآیند اختیاری (opt-in) است. به دلیل احتمال تغییر در APIهای عمومی، به توسعه‌دهندگان توصیه می‌شود در طول دوران آزمایش، نسخه‌ها را دقیقاً پین (pin) کنند تا از تغییرات ناگهانی ناشی از بازه نسخه‌های شناور (floating version ranges) جلوگیری کنند.

برنامه مهاجرت توصیه شده برای اکثر تیم‌ها:

• اکنون: تغییرات مشخصات را مطالعه کنید و سرورها را برای شناسایی هرگونه استفاده از sampling، roots و logging بازبینی نمایید. هرگونه وابستگی به وضعیت جلسه (session state) را شناسایی کنید.
• پس از انتشار نسخه Stable (بعد از ۲۸ جولای): ابتدا یک سرور غیر-حیاتی را ارتقا دهید تا با تغییرات نام importها و زیرسیستم‌های بازنشسته شده سازگار شوید.
• در طول سال اول (Grace Year): تمامی سرورهای باقی‌مانده را پیش از حذف کامل زیرسیستم‌های قدیمی منتقل کنید.

این تغییر، MCP را از یک «گفتگو» بین کلاینت و یک سرور خاص، به مجموعه‌ای از «تراکنش‌های مستقل» تبدیل می‌کند. برای تیم‌های زیرساخت، این امر پیچیدگی‌های مربوط به Sticky Sessions و Session Affinity را حذف کرده و اجازه می‌دهد سرورها در محیط‌های واقعاً زودگذر (ephemeral)، مقیاس‌پذیر خودکار (autoscaled) یا بدون سرور (serverless) مستقر شوند.

گام بعدی شما

• کدهای فعلی خود را برای شناسایی هرگونه وابستگی به sampling یا roots بازبینی کنید.
• پس از ۲۸ جولای، یک سرور غیر-حیاتی را به نسخه ۲ ارتقا دهید تا با تغییرات نام imports سازگار شوید.
• استراتژی انتقال لاگ‌ها را از پروتکل MCP به خط‌لوله OpenTelemetry تغییر دهید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.