استاندارد MCP نسخه 2026-07-28 نشست‌های پروتکل را حذف کرده و به‌جای آن دو هدر HTTP اجباری معرفی نموده است. این تغییر، نه تنها ساده‌سازی مقیاس‌پذیری را ممکن می‌سازد، بلکه نحوهٔ مسیردهی، نرخ‌دهی و کنترل ترافیک عامل‌ها را نیز دگرگون می‌کند.

تغییرات کلیدی در نسخهٔ جدید MCP

نسخه‌های قبلی MCP مبتنی بر دست‌دهی (initialize / initialized) و پیگیری نشست‌ها با هدر Mcp-Session-Id بودند؛ وضعیتی که بار بالانسینگ و اوتواسکیلینگ را پیچیده می‌کرد زیرا هر مشتری به نمونه‌ای که نشست را نگه داشته بود «پین» می‌شد. در نسخهٔ جدید، آن تبادل حذف شده و هر درخواست به‌طور مستقل شامل نسخهٔ پروتکل، هویت کلاینت و قابلیت‌های مورد نیاز است. نتیجه: الگوی صریح و بدون‌حالت که اجازه می‌دهد هر درخواست روی هر نمونه فرود بیاید.

متادیتا در هدرها: چه تغییر کرده است

پیام‌های MCP روی HTTP به‌صورت JSON-RPC منتقل می‌شوند. قبلاً نوع عملیات و نام ابزار عمدتاً در بدنهٔ JSON ذخیره می‌شد؛ حالا دو هدر اجباری اضافه شده‌اند:

  • Mcp-Method
  • Mcp-Name

مثال: فراخوانِ یک ابزار با هدرهای Mcp-Method: tools/call و Mcp-Name: search ارسال می‌شود؛ بدنهٔ JSON-RPC تنها شامل پارامترها خواهد بود. با این ساختار، دروازه‌ها، محدودکننده‌های نرخ و WAFها می‌توانند بدون باز کردن بدنه تصمیم‌گیری کنند—رفتاری که امروز در APIهای REST رایج است (REST).

پیامدها برای زیرساخت و حاکمیت

با انتقال بخشی از متادیتا به لایهٔ ترنسپورت، ابزارهای کنترل و نظارت موجود برای APIها—مثل گیت‌ویها، رول‌آوت‌های تدریجی و لودبالانسرها—قادر خواهند بود بدون پیاده‌سازی لایه‌های اضافی روی پروتکل MCP کار کنند. برخی پیاده‌کنندگان این تحول را «بازگشت به مدل API» می‌نامند، زیرا MCP اکنون از زیرساخت‌های成熟 API بهره‌مند می‌شود.

نمایی از کنسول مدیریتی دروازه API و نمایش ترافیک عامل‌ها

مسیردهی و سیاست‌گذاری بدون پارس بدنه

با خواندن مقدارهای Mcp-Method و Mcp-Name، گیت‌وی می‌تواند ترافیک را بر اساس ابزار یا متد روت کند، نرخ آن را محدود کند یا درخواست‌ها را مسدود سازد. برخی پیاده‌سازی‌ها پیشنهاد می‌کنند آرگومان‌های کلیدی ابزار در هدرها کپی شوند تا روتینگ‌های دقیق‌تری امکان‌پذیر شود. این رویه اعمال سیاست‌ها را ساده‌تر و کارآمدتر می‌کند.

تأثیر بر تعامل‌های چندمرحله‌ای و احراز هویت

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

قواعد احراز هویت نیز سخت‌تر شده‌اند: ثبت‌نام داینامیک کلاینت تا پس از تابستان 2027 منسوخ اعلام شده و به‌تدریج حذف خواهد شد. شناسهٔ صادرکننده مطابق RFC 9207 پذیرفته شده و کلاینت‌ها باید URI کاننیکل سرور را به‌عنوان resource طبق RFC 8707 ارسال کنند تا توکن‌ها فقط به آن audience تعلق گیرند.

واکنش جامعهٔ توسعه‌دهندگان

بحث‌ها در انجمن‌ها و پلتفرم‌هایی مانند Hacker News دو قطبی شده است. یک جناح می‌گوید پروتکل نباید حالت‌دار طراحی می‌شد و تغییر فعلی MCP را بازگشتی منطقی به مدل API می‌داند که از زیرساخت‌های موجود بهره می‌برد. جناح دیگر نگران از دست رفتن ارزش استاندارسازی است؛ MCP قرارداد مشترکی بین ارائه‌دهندگان AI ایجاد کرد که انگیزهٔ پیاده‌سازی واقعی را فراهم آورد.

پرسش‌های کلیدی برای مهندسان و معماران

  • آیا تیم شما آماده است گیت‌وی، WAF و rate limiter را برای خواندن Mcp-Method و Mcp-Name پیکربندی کند؟
  • قرار دادن متادیتا در هدرها از منظر امنیتی چه ریسک‌هایی ایجاد می‌کند و چگونه می‌توان اطلاعات حساس را محافظت یا رمزنگاری کرد؟
  • چگونه تعامل‌های نیازمند تأیید انسانی (elicitation) را در معماری‌های بدون‌حالت مدل‌سازی کنیم تا تجربهٔ کاربری قابل قبولی فراهم شود؟

پیشنهادهای عملی

برای تیم‌هایی که قصد پیاده‌سازی یا مهاجرت به MCP جدید را دارند، اولویت‌های عملی عبارتند از:

  • گیت‌وی و محدودکننده‌های نرخ را بازبینی و پیکربندی کنید تا Mcp-Method و Mcp-Name را بخوانند و سیاست‌های مبتنی بر ابزار را اعمال کنند.
  • قواعد ورود هدرها را مستندسازی، فیلتر و در صورت لزوم رمزنگاری کنید تا از افشای اطلاعات حساس جلوگیری شود.
  • جریان‌های چند‌گشتی را طراحی کنید تا تأیید انسانی، انتظارها و بازپخش درخواست‌ها به‌خوبی مدیریت شوند و UX مناسبی ارائه شود.
  • سازگاری با RFCهای مرتبط احراز هویت را در اولویت قرار دهید و برنامهٔ حذف ثبت‌نام داینامیک را مد نظر داشته باشید.

چشم‌انداز

جهت‌گیری MCP به سمت بدون‌حالت نشان‌دهندهٔ همگرایی اکوسیستم روی ابزارها و الگوهای مرسوم API است. این همگرایی مزایایی در بهره‌مندی از زیرساخت‌های成熟 فراهم می‌آورد، اما هم‌زمان سؤالات جدیدی دربارهٔ حاکمیت، امنیت و طراحی جریان‌های کاری انسانی مطرح می‌کند. احتمالاً مسیر پیش‌رو ترکیبی خواهد بود: استفاده از زیرساخت‌های استاندارد API همراه با حفظ ویژگی‌های تخصصی MCP برای کار با مدل‌ها و ابزارها.

منابع و مراجع