مشخصات MCP نسخه 2026-07-28 چه تغییراتی ایجاد کرد؟
مرور کامل مهم‌ترین تغییرات MCP 2026-07-28: هسته Stateless، حذف Handshake، MRTR، Header Routing، Cache، Authorization، Tasks، Extensions و مسیر مهاجرت.
نسخه 2026-07-28 یکی از بزرگ‌ترین تغییرات MCP از زمان معرفی Remote MCP است. هسته پروتکل از مدل Sessionمحور به Request/Response بدون Session تبدیل شده و چند قابلیت برای مقیاس‌پذیری، امنیت و Extensionها اضافه شده است.
این نسخه Final است و SDKهای Tier 1 برای TypeScript، Python، Go و C# هم‌زمان با آن به‌روزرسانی شدند. مهاجرت می‌تواند Breaking باشد؛ مخصوصاً برای پیاده‌سازی‌هایی که به initialize، Session ID یا Stream دائمی وابسته‌اند.
۱. هسته Stateless
در نسخه جدید هر Request اطلاعات لازم مانند نسخه پروتکل، هویت و Capabilityهای Client را در خود حمل می‌کند. Load Balancer می‌تواند Requestها را بدون Sticky Session بین Instanceها توزیع کند.
۲. حذف Handshake اجباری
تبادل initialize/initialized و هدر Mcp-Session-Id برای نسخه جدید بازنشسته شده‌اند. اگر Client بخواهد قابلیت‌های Server را از قبل بداند، می‌تواند server/discover را صدا بزند، اما Discovery اجباری نیست.
POST /mcp
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "search",
"arguments": {"q": "MCP"}
}
}۳. Multi Round-Trip Requests
MRTR جایگزین الگوی Server-initiated Request روی Stream باز می‌شود. اگر Tool وسط اجرا به تأیید یا پارامتر دیگری نیاز داشته باشد، نتیجه input_required برمی‌گرداند و Client Request اصلی را با پاسخ‌های لازم تکرار می‌کند.
۴. Header-based Routing
در Streamable HTTP، هدرهای Mcp-Method و Mcp-Name برای Route، Metering و Policy اضافه شده‌اند. Gateway یا WAF می‌تواند بدون Parse کامل Body تصمیم بگیرد.
۵. Cacheable List Results
نتایج tools/list، prompts/list، resources/list و resources/read می‌توانند ttlMs و cacheScope داشته باشند. Client می‌تواند Catalog را Cache کند و از Fetch تکراری جلوگیری کند.
۶. سخت‌گیری Authorization
- اعتبارسنجی Issuer بر اساس RFC 9207
- بستن Credential به Issuer صادرکننده
- حرکت از Dynamic Client Registration به Client ID Metadata Documents
- اصلاح application_type برای Clientهای Desktop و CLI
- کاهش ریسک Authorization Server Mix-up
DCR برای سازگاری عقب نگه داشته شده، اما به نفع CIMD Deprecated است و در نسخه آینده حذف می‌شود.
۷. Extensions Framework
قابلیت‌هایی که سرعت تکامل متفاوت دارند از Core جدا می‌شوند. MCP Apps، Tasks و Enterprise Managed Authorization نمونه Extensionهایی هستند که می‌توانند مستقل نسخه‌گذاری شوند.
۸. Tasks
Taskها از Core آزمایشی خارج و به Extension رسمی io.modelcontextprotocol/tasks منتقل شده‌اند. Server می‌تواند برای کار طولانی Task Handle برگرداند و Client با tasks/get وضعیت را Poll کند.
عملیات طولانی در MCP چگونه مدیریت می‌شوند؟
۹. Deprecation Policy
نسخه جدید سیاست رسمی Deprecation با حداقل مسیر دوازده‌ماهه دارد. Roots، Sampling، Logging و Legacy HTTP+SSE Deprecated شده‌اند، اما فوراً حذف نمی‌شوند.
۱۰. State صریح به‌جای Session پنهان
اگر Workflow به State نیاز دارد، Server می‌تواند Handle صریح بسازد و مدل آن را در Tool Call بعدی برگرداند. این روش از Session مخفی در Transport شفاف‌تر است.
اثر تغییرات روی Gateway
- Route بر اساس Header ساده‌تر می‌شود.
- مقیاس افقی بدون Sticky Session ممکن می‌شود.
- Authorization می‌تواند پیش از Parse Body اعمال شود.
- Cache Tool Catalog قابل کنترل‌تر است.
- نسخه و Capability هر Request باید اعتبارسنجی شود.
- State مربوط به Task یا Business Workflow باید صریح مدیریت شود.
راهنمای مهاجرت
- نسخه‌های SDK و Clientهای مورد پشتیبانی را فهرست کنید.
- وابستگی به initialize و Session ID را پیدا کنید.
- Route و WAF را برای Headerهای جدید آماده کنید.
- Discovery و Capability per-request را پیاده کنید.
- Cache و TTL را با Policy سازمان هماهنگ کنید.
- OAuth Issuer و Credential Binding را تست کنید.
- Extensionها را جدا از Core فعال کنید.
- با Client قدیمی و جدید تست سازگاری انجام دهید.
آیا باید فوراً مهاجرت کرد؟
اگر Server فعلی پایدار است، مهاجرت باید برنامه‌ریزی‌شده باشد. بسیاری از SDKها امکان پشتیبانی هم‌زمان از نسخه Legacy و 2026-07-28 را فراهم می‌کنند. تصمیم باید بر اساس Clientهای واقعی و هزینه Breaking Change باشد.
منابع رسمی
جمع‌بندی
نسخه 2026-07-28 تلاش می‌کند MCP را شبیه یک Workload استاندارد وب کند: Stateless، قابل Route، قابل Cache و قابل مقیاس.
برای تیم‌هایی که Gateway یا Remote Server سازمانی دارند، این تغییرات فرصت ساده‌سازی زیرساخت را ایجاد می‌کنند؛ اما مهاجرت به تست دقیق Authorization، State و سازگاری Client نیاز دارد.
