اگر در حال حاضر سرورهای MCP خود را روی خوشه‌های پیچیده کوبرنتیز مدیریت می‌کنید، هزینه‌های زیرساختی شما قرار است به‌شدت کاهش یابد. پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) در به‌روزرسانی ۲۸ ژوئیه ۲۰۲۶، رسماً به معماری بدون وضعیت (Stateless) انتقال یافت. این تغییر بنیادین، مسئولیت حفظ وضعیت (State) را از لایه شبکه به‌طور کامل به پنجرهٔ زمینه (Context Window) مدل منتقل می‌کند.
این به‌روزرسانی در حالی منتشر می‌شود که MCP به مقیاسی عظیم رسیده است؛ به‌طوری که SDKهای تایپ‌اسکریپت و پایتون این پروتکل هر کدام از مرز یک میلیارد دانلود کل عبور کرده‌اند. طبق تحلیل فنی منتشر شده در dev.to، این پروتکل اکنون ماهانه نزدیک به نیم میلیارد دانلود را مدیریت می‌کند. چنین حجم ترافیکی، طراحی‌ای را ایجاب می‌کرد که از استقرار توزیع‌شده و گسترده پشتیبانی کند. به همین دلیل، هر چهار SDK سطح اول (Tier 1) در همان روز انتشار، پشتیبانی از این معماری جدید را ارائه کردند. این تحول در راستای تغییرات ساختاری گسترده‌ای است که منجر به حذف کامل جلسات و فرآیندهای دست‌دهی شد تا مقیاس‌پذیری سیستم‌ها افزایش یابد.
برای دستیابی به این هدف، پروتکل چندین قابلیت کلیدی در مدیریت نشست‌ها را حذف کرده است. بر اساس مستندات جدید، فرآیند دست‌دادن (Handshake) اولیه/تکمیل‌شده (initialize/initialized)، هدر Mcp-Session-Id و قابلیت ازسرگیری جریان‌های SSE به‌طور کامل حذف شده‌اند. اکنون نسخه‌های پروتکل و قابلیت‌های کلاینت به‌جای آنکه یک بار در هر نشست تثبیت شوند، در هر درخواست به‌صورت مجزا از طریق فیلد _meta ارسال می‌شوند (به‌طور مشخص از طریق io.modelcontextprotocol/protocolVersion و io.modelcontextprotocol/clientCapabilities).
تغییرات فنی و حذف‌ها
- حذف‌شده‌ها: دستورات
pingوlogging/setLevelو همچنینnotifications/roots/list_changedحذف شدند. هدرLast-Event-IDو شناسه‌های رویداد SSE نیز دیگر وجود ندارند. - منسوخ‌شده‌ها: قابلیت‌های Roots, Sampling و Logging اکنون وارد یک بازهٔ زمانی ۱۲ ماهه برای حذف کامل (Deprecation window) شده‌اند.
- مسیریابی جدید: هدرهای
Mcp-MethodوMcp-Nameبه گیت‌وی‌ها اجازه می‌دهند ترافیک را بدون نیاز به تجزیهٔ بدنه JSON و تنها بر اساس مقادیر هدر، مسیریابی و اندازه‌گیری (Meter) کنند. - کشینگ: اضافه شدن فیلدهای
ttlMsوcacheScopeدر نتایج لیست و خواندن (list and read results)، برای نخستین بار امکان استفاده از کشینگ استاندارد HTTP را فراهم کرد. - تغییرات نقاط انتهایی: نقاط انتهایی List دیگر بسته به هر اتصال تغییر نمی‌کنند و سطوح لاگ اکنون در هر درخواست از طریق
_metaتنظیم می‌شوند.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی بهینه‌سازی استنتاج در مدل‌های عامل‌محور اشاره کردیم، کاهش وابستگی به زیرساخت‌های Stateful همواره یک اولویت بوده است. این چرخش معماری اجازه می‌دهد هر نمونه از سرور که پشت یک Load Balancer با روش Round-robin قرار دارد، بتواند به هر درخواستی پاسخ دهد. در نتیجه، سرورهای MCP اکنون می‌توانند به‌عنوان توابع بدون سرور (Serverless Functions)، روی پلتفرم‌های رایانش لبه (Edge Computing) یا در خوشه‌های کوبرنتیز با قابلیت مقیاس‌پذیری خودکار (Autoscaling) بدون نیاز به پیکربندی‌های پیچیده Session Affinity مستقر شوند. در کنار این بهینه‌سازی‌های زیرساختی، ابزارهایی مانند mcpscore برای سنجش دقیق کیفیت سرورها معرفی شده‌اند تا توسعه‌دهندگان بتوانند استانداردهای پیاده‌سازی را ارزیابی کنند.
جابه‌جایی وضعیت: از شبکه به توکن
باید توجه داشت که وضعیت (State) حذف نشده، بلکه جابه‌جا شده است. مشخصات فنی صراحتاً بیان می‌کند: سرورهایی که به وضعیت بین‌فراخوانی (Cross-call state) نیاز دارند، باید از «دستگیره‌های تولیدشده توسط سرور» (Server-minted handles) استفاده کنند که به‌عنوان آرگومان‌های معمولی ابزار ارسال می‌شوند. در این مدل، سرور یک دستگیره تولید کرده و آن را در نتیجهٔ ابزار برمی‌گرداند و مدل باید این شناسه‌های مبهم (Opaque identifiers) را در فراخوانی‌های بعدی به‌طور دقیق به سرور بازگرداند.
این تغییر، یک موازنهٔ جدید در قابلیت اطمینان ایجاد می‌کند. وضعیت اتصال اکنون به وضعیت پنجرهٔ زمینه تبدیل شده است؛ به این معنا که در هر نوبت توکن مصرف می‌کند و با داده‌های دیگر در پنجره رقابت می‌کند. اگر مدل زبانی یک دستگیره را تغییر دهد، مخدوش کند یا حذف کند، وضعیت به‌طور کامل از دست می‌رود. این یک سناریوی شکست متفاوت نسبت به گم شدن یک Session ID در هدر HTTP است.
علاوه بر این، حذف قابلیت ازسرگیری (Resumability) باعث می‌شود جریان‌های پاسخِ قطع‌شده، منجر به از دست رفتن درخواست‌های در حال اجرا (In-flight requests) شوند. در حالی که یک فراخوانی ابزار ۴۰ میلی‌ثانیه‌ای قابل چشم‌پوشی است، اما یک بازیابی (Retrieval) سی‌ثانیه‌ای روی یک لینک موبایل ناپایدار، اکنون باید از صفر تکرار شود. برای مدیریت عملیات طولانی‌مدت، افزونهٔ بازطراحی‌شده‌ی وظایف (io.modelcontextprotocol/tasks) از هستهٔ اصلی پروتکل خارج شده تا از طریق tasks/get و مکانیزم Polling مدیریت شود، هرچند این قابلیت اکنون یک افزونه است و نه یک ویژگی تضمین‌شده در کلاینت.
لایه پروتکل Pilot
در سطحی پایین‌تر، پروتکل Pilot (که در حال حاضر در پیش‌نویس IETF با کد draft-teodor-pilot-protocol-01 قرار دارد) تلاش می‌کند این مشکلات را در لایه ۵ مدل OSI حل کند. در حالی که A2A تعریف می‌کند عامل‌ها چه بگویند، Pilot تعریف می‌کند چگونه به یکدیگر برسند؛ شبیه به همان نقشی که TCP/IP در زیر لایه HTTP ایفا می‌کند.
پروتکل Pilot هویت را یک‌بار از طریق کلیدهای X25519 ECDH و AES-256-GCM که از طریق HKDF مشتق شده‌اند، برقرار می‌کند. یک فریم PILA، امضای Ed25519 را روی رشتهٔ ASCII auth، شناسه گره فرستنده و کلید عمومی X25519 متصل می‌کند. شناسه گره (Node ID) به‌عنوان داده‌های احراز هویت اضافی GCM عمل کرده و هر بسته را به‌طور رمزنگاری‌شده به فرستنده‌اش متصل می‌کند. این ساختار باعث می‌شود یک کلاینت بدون وضعیت، نیازی نباشد در هر درخواست clientInfo را در _meta اعلام کند.
Pilot همچنین قابلیت اطمینان را از طریق یک پنجرهٔ لغزان (Sliding Window) مدیریت می‌کند که توسط حداقلِ «پنجره احتقان» (Congestion Window) و «پنجره اعلام‌شده توسط همتا» (Peer-advertised window) محدود می‌شود. این پروتکل از SACK (تأیید انتخابی) استفاده می‌کند که تا چهار بلوک را در هر ACK حمل می‌کند، پس از سه ACK تکراری عملیات Fast Retransmit را انجام می‌دهد و RTO را طبق RFC 6298 بین ۲۰۰ میلی‌ثانیه تا ۱۰ ثانیه محدود می‌کند. این مکانیسم‌ها مانع از آن می‌شود که لایه اپلیکیشن هرگز متوجه لرزش‌های جریان داده شود.
آدرس‌دهی از طریق یک آدرس مجازی ۴۸ بیتی (شامل ۱۶ بیت شناسه شبکه و ۳۲ بیت شناسه گره) پایدار می‌ماند. این امر به یک عامل اجازه می‌دهد با استفاده از کشف STUN، حفره‌زنی (Hole Punching) و جایگزینی رله (Relay fallback) برای NATهای متقارن، بین شبکه‌های مختلف جابه‌جا شود. در میان تقریباً ۲۵۰,۰۰۰ عاملی که در حال حاضر متصل هستند، این لایه پیچیدگی‌های شبکه را به‌طور نامرئی مدیریت می‌کند.
برای توسعه‌دهندگان، این بدان معناست که MCP اکنون یک «شهروند خوش‌رفتار HTTP» است که برای واقعیت‌های نقاط انتهایی ابری بهینه شده است. اما این بهره‌وری در لایه استقرار، با افزایش فشار روی پنجرهٔ زمینه مدل تأمین شده است.
با تبدیل شدن مسیرهای عامل‌ها از چند ثانیه به چند ساعت، انباشت دستگیره‌ها در پنجرهٔ زمینه ممکن است به گلوگاه اصلی تبدیل شود. صنعت در حال حاضر پیچیدگی شبکه را با پیچیدگی توکن معاوضه می‌کند؛ شرطی که تنها در صورتی به‌نفع ماست که پنجره‌های زمینه گسترده‌تر شوند و مدل‌ها در ردیابی وضعیت دقیق‌تر عمل کنند.
گام بعدی شما
- اگر از MCP استفاده می‌کنید، معماری سرورهای خود را از حالت Stateful به Serverless منتقل کنید تا هزینه‌های عملیاتی را کاهش دهید.
- در طراحی ابزارها، برای مدیریت وضعیت‌های طولانی، به‌جای تکیه بر نشست، از مکانیزم Handle-passing استفاده کنید.
- برای عملیات‌های زمان‌بر، پیاده‌سازی افزونه
io.modelcontextprotocol/tasksرا در اولویت قرار دهید.
اما تأثیر این تغییر بر مدل‌های استدلالی که پنجره‌های زمینهٔ کوچک‌تری دارند، بحث‌برانگیزتر است — به تحلیل ما درباره‌ی مدل‌های استدلالی و مدیریت حافظه مراجعه کنید.
گفتگو