مشخصات جدید MCP مورخ ۲۰۲۶-۰۷-۲۸ تمامی الزامات مربوط به وضعیت نشست (session-state) را حذف میکند و اجازه میدهد هر درخواست تمام دادههای مورد نیاز خود را همراه داشته باشد. گذار به یک پروتکل بدون وضعیت (stateless)، به این معناست که توسعهدهندگان میتوانند برای هر فراخوانی یک نمونه (instance) واحد ایجاد کنند، آن را روی گرههای بدون سرور (serverless) یا لبه (edge) اجرا کنند و زیرساختهای قدیمی مسیریابی چسبنده (sticky-routing) و ذخیرهسازی مشترک را که همیشه باعث دردسر در استقرار میشدند، کنار بگذارند.
از مصافحه (Handshake) تا فراخوانیهای خودکفا
تاکنون، پروتکل بافت مدل (MCP) یک مصافحه (handshake) را تحمیل میکرد که منجر به صدور یک شناسه نشست (session ID) میشد. سرورها باید آن شناسه را در طول عمر اتصال نگه میداشتند، که در عمل به معنای زنده نگه داشتن فرآیندها، تکثیر وضعیت در یک کلاستر Redis، یا پیکربندی متعادلکنندههای بار (load balancers) برای مسیریابی «چسبنده» بود. نتیجه، یک پشته (stack) پیچیده و سنگین از نظر منابع بود که مانع از مقیاسپذیری میشد و رشد افقی را پرهزینه میکرد.
مشخصات جدید، هر درخواست را خودکفا میکند. هر بار داده (payload) شامل نسخه پروتکل و هویت فراخواننده است، بنابراین سرور میتواند با درخواست به عنوان یک تراکنش یکباره برخورد کند. دیگر نیازی به ذخیرهساز نشست، فرآیند طولانیمدت یا قوانین مسیریابی خاص نیست.
چرا بدون وضعیت بودن (Stateless) برای استقرار مهم است
- آماده برای محیطهای serverless و edge – هر درخواست تمام موارد مورد نیاز خود را همراه دارد، بنابراین یک تابع میتواند بدون نیاز به وضعیت پیشگرم (warm-up state)، شروع به کار کند، پاسخ دهد و بسته شود. ارائهدهندگانی که به ازای هر فراخوانی هزینه دریافت میکنند، برای بارهای کاری MCP قابل استفاده میشوند.
- سادهسازی متعادلسازی بار – متعادلکنندههای استاندارد L4/L7 میتوانند ترافیک را به طور یکنواخت توزیع کنند؛ نیازی به محدود کردن یک کلاینت به یک بکاِند خاص نیست.
- کاهش سربار عملیاتی – تیمها میتوانند کلاسترهای Redis یا کدهای سفارشی تکثیر نشست را کنار بگذارند که باعث کاهش هزینهها و کاهش سطح شکست (failure surface) میشود.
برای سازمانهایی که در حال حاضر MCP را پشت یک متعادلکننده بار اجرا میکنند، این تغییر نیاز به قوانین «چسبنده» را که اغلب باعث توزیع ناعادلانه ترافیک میشود، از بین میبرد. این صرفهجویی بهویژه برای سرویسهای با توان عملیاتی بالا که روزانه میلیونها فراخوانی دارند، بسیار چشمگیر است.
ارتقای عملکرد و امنیت
این مشخصات بهبودهای ملموسی را اضافه میکند که پروتکل را فراتر از حالت بدون وضعیت بودن، ایمنتر و کارآمدتر میکند:
- حافظه پنهان (Caching) مبتنی بر TTL – لیست ابزارها و پرامپتها اکنون شامل فیلد زمان انقضا (time-to-live) هستند که به کلاینتها اجازه میدهد نتایج را به صورت محلی ذخیره کنند و از رفتوبرگشتهای بیمورد جلوگیری کنند.
- مسیریابی مبتنی بر هدر (Header) – هدرهای HTTP جدید، اطلاعات مسیریابی را در مراحل اولیه آشکار میکنند، بنابراین گیتویها میتوانند ترافیک را بدون تجزیه (parsing) کل بدنه JSON هدایت کنند و چند میلیثانیه از تأخیر (latency) بکاهند.
- مقاومسازی OAuth/OIDC – توکنهای هویت تحت بررسیهای سختگیرانهتر OAuth و OpenID Connect قرار میگیرند که احتمال قرارگیری در معرض حملات بازپخش (replay) و سرقت توکن را کاهش میدهد.
- چارچوب رسمی افزونهها – وظایف (Tasks) و اپلیکیشنها اکنون به یک مدل افزونه تعریفشده تعلق دارند که عرضه ویژگیهای آینده را برای نگهدارندگان SDK روانتر میکند.
تأثیر بر توسعهدهندگان
اکوسیستم SDK از هماکنون این تغییر را منعکس کرده است: کتابخانههای TypeScript، Python، Go و C# فرمت جدید درخواست را صادر میکنند. مجموع دانلودهای این SDKها به نیم میلیارد در ماه نزدیک شده است که چهار برابر بیشتر از ابتدای سال است و نشان میدهد که MCP تا چه حد در حال پذیرش گسترده است.
توسعهدهندگان باید هر کدی را که فرض میکرد یک نشست مداوم وجود دارد، اصلاح کنند. معمولاً این به معنای انتقال دادههای مربوط به نشست به بار داده (payload) درخواست یا به یک ذخیرهساز خارجی است که در هر فراخوانی با آن مشورت میشود. بازه مهاجرت دوازده ماه است که به تیمها زمان میدهد تا کدها را بازسازی (refactor)، آزمایش و الگوی جدید را پیادهسازی کنند.
نکته مقابل: پیچیدگی مهاجرت
بدون وضعیت بودن (Statelessness) یک وعده غذای رایگان نیست. برنامههایی که قبلاً برای مواردی مانند تاریخچه مکالمه تدریجی به وضعیت سمت سرور متکی بودند، اکنون باید آن وضعیت را در سمت کلاینت یا از طریق یک لایه پایداری (persistence layer) جداگانه مدیریت کنند.
آنچه باید زیر نظر داشت
- معیارهای پذیرش – میزان استفاده از نسخههای جدید SDK را نظارت کنید؛ کند شدن روند میتواند نشاندهنده دشواری در مهاجرت باشد.
- پشتیبانی از پلتفرمهای Edge – با اعلام زمانهای اجرای (runtimes) سازگار با MCP توسط ارائهدهندگان بیشتر، مزیت هزینه واقعی مدلهای serverless روشنتر خواهد شد.
- گزارشهای حوادث امنیتی – جریان مقاومشدهی OAuth/OIDC باید حملات هویتی را کاهش دهد، اما هرگونه رخنه، امنیت حفاظهای جدید را به چالش خواهد کشید.
نتیجهگیری: با بدون وضعیت کردن MCP، این مشخصات پروتکل را با الگوهای مدرن ابری-بومی (cloud-native) همسو میکند، بار عملیاتی مدیریت نشست را کاهش میدهد و در عین حال در را به روی مدلهای استقرار ارزانتر و انعطافپذیرتر (elastic) باز میکند. هزینه این کار، دوره کوتاهی از بازسازی کد (refactoring) و بزرگتر شدن حجم درخواستها است، اما پاداش بلندمدت، پروتکلی است که به همان راحتی زیرساختی که روی آن اجرا میشود، مقیاسپذیر باشد.