MCP חסר-המצב: ה-RC של 2026-07-28 שמשנה הכול

ב-21 במאי 2026 מהנדס פלטפורמה שמריץ צי של שרתי MCP מאחורי load balancer ב-Kubernetes פתח את ה-blog של Model Context Protocol וראה שה-RC ננעל. עד אותו רגע הוא נאלץ להכריח sticky sessions בכל gateway, כי כל לקוח היה מקושר ל-instance שבו בוצע ה-initialize handshake שלו והחזיק Mcp-Session-Id. ה-RC החדש מבטל בדיוק את כאב הראש הזה — אבל גם דורש ממנו לכתוב מחדש איך השרתים שלו מחזיקים מצב. זה לא tweak; זה מתואר כרוויזיה הגדולה ביותר של MCP מאז ההשקה.

הליבה: MCP הופך ל-stateless

הצוות שלך מריץ אוטוסקיילינג: בקשה אחת נוחתת על pod שמת חמש שניות אחר כך, והלקוח מאבד את ה-session. עד היום ב-MCP זה היה בעיה אמיתית, כי הפרוטוקול עצמו החזיק מצב. ב-RC, לפי לשון המפרט, 'ה-initialize/initialized handshake מוסר' ו-'ה-Mcp-Session-Id header וה-session ברמת הפרוטוקול שהגיע איתו מוסרים גם הם'. במקום handshake, ה-protocol version, ה-client info וה-capabilities נוסעים עכשיו ב-_meta על כל בקשה. התוצאה המעשית: 'כל בקשת MCP יכולה לנחות על כל instance של שרת' — בלי sticky routing.

מה עושים עם מצב שכן צריך להישמר? המפרט מפנה לדפוס שכל מי שכתב HTTP API מכיר: 'שרתים שצריכים לשאת מצב בין קריאות יכולים לעשות מה ש-HTTP APIs תמיד עשו — להנפיק handle מפורש מתוך כלי, ולתת למודל להחזיר אותו כארגומנט רגיל בקריאות הבאות'. במקום stream של SSE מתמשך, ריבוי-round-trip עובד כך: השרת מחזיר InputRequiredResult עם requestState, והלקוח מנסה שוב עם inputResponses וה-requestState המוחזר. 'כל instance של שרת יכול להמשיך את ה-retry הזה כי כל מה שהוא צריך נמצא ב-payload'.

<b>השורה התחתונה: אם בניתם state בתוך ה-session של MCP, צריך להעביר אותו ל-handles מפורשים — זו לא מיגרציה backward-compatible.</b>

Headers חדשים: ניתוב בלי לפתוח את ה-body

ה-DevOps שמתחזק את ה-API gateway רוצה לנתב tools/call ל-pool אחד ו-resources/read לאחר — בלי לפרסר JSON-RPC בכל hop. ה-RC מאפשר את זה ישירות: ה-Streamable HTTP transport דורש עכשיו שני headers חדשים, Mcp-Method ו-Mcp-Name, כך שגייטוויי יכול לנתב 'בלי לבדוק את גוף הבקשה'. בשילוב עם הסרת ה-session, זה הופך load balancing של MCP לבעיה סטנדרטית של HTTP — בדיוק היעד שמפת הדרכים סימנה תחת scalability של transport.

POST /mcp HTTP/1.1
Host: tools.example.com
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search_invoices

{ "jsonrpc": "2.0", "id": 7, "method": "tools/call",
  "params": { "name": "search_invoices",
    "_meta": { "io.modelcontextprotocol/clientInfo": { "name": "acme-client", "version": "1.0.0" } } } }

MCP Apps: UI מרונדר-שרת ב-iframe מבודד

מפתח שבונה כלי לאישור הוצאות רצה שהמשתמש יראה טבלה אינטראקטיבית, לא בלוק טקסט גולמי. כאן נכנסים MCP Apps: ממשקי משתמש מרונדרי-שרת המוצגים ב-iframes מבודדים. המפתח חשוב לאבטחה — 'כלים מצהירים על ה-UI templates שלהם מראש, כך שה-hosts יכולים לעשות prefetch, cache ו-security review לפני שמשהו רץ'. ולגבי auditing: פעולות ה-UI מנותבות דרך אותו נתיב JSON-RPC כמו קריאות כלים, כך שכל לחיצה נשארת ב-audit trail אחיד ולא בערוץ צד.

<b>MCP Apps לוקח את ה-agent UI מ-hack צדדי לאזרח מהשורה הראשונה של הפרוטוקול — עם prefetch ו-security review מובנים.</b>

Tasks: מ-experimental להרחבה רשמית לעבודה ארוכת-טווח

סוכן (agent) שמריץ build של 40 דקות לא יכול להחזיק חיבור פתוח כל הזמן, ובוודאי לא במודל stateless. הרחבת Tasks עוברת מ-experimental להרחבה רשמית, מעוצבת מחדש סביב המודל החדש. הזרימה פשוטה ועמידה: 'שרת יכול לענות ל-tools/call עם task handle, והלקוח מנהל אותו עם tasks/get, tasks/update ו-tasks/cancel'. ה-handle הוא סתם מזהה שעובר ב-payload, אז כל instance יכול לשרת polling עליו — מה שמתיישב מושלם עם ה-stateless routing.

כדאי לציין שכל ההרחבות במודל החדש מזוהות ב-reverse-DNS IDs, מנוהלות במו"מ דרך extensions map ב-capabilities, חיות ב-repositories נפרדים מסוג ext-* עם maintainers מורשים, ומגרסאות באופן עצמאי מהמפרט. זה אומר ש-Tasks יכולה להתפתח בלי לחכות ל-release הבא של הליבה.

הרשאה: OAuth 2.0 / OIDC מוקשח

צוות אבטחה בארגון enterprise רוצה לדעת שאף שרת זדוני לא יכול להתחזות לשרת ה-authorization. ה-RC מהדק את זה: 'לקוחות חייבים עכשיו לאמת את פרמטר ה-iss בתגובות authorization לפי RFC 9207', וגרסאות עתידיות ידחו iss חסר. בנוסף, לקוחות מצהירים application_type במהלך Dynamic Client Registration, וה-credentials נקשרים ל-issuer של שרת ה-authorization — ונרשמים מחדש כשמשאב נודד בין שרתי authorization. גם refresh של token מתועד עכשיו עבור שרתים בסגנון OpenID Connect.

מה עוד נכנס — ומה יוצא

מעבר לכותרות, ה-RC מוסיף מטא-דאטה שימושית: תוצאות list ו-resource read נושאות עכשיו ttlMs ו-cacheScope (כדי שלקוחות יבינו טריות ובטיחות cache בין משתמשים), W3C Trace Context מתועד ב-_meta (traceparent, tracestate, baggage) ל-trace אחד דרך OpenTelemetry, ו-inputSchema/outputSchema של כלים מורמים ל-JSON Schema 2020-12 מלא (oneOf, anyOf, allOf, $ref, $defs). במקביל, שלוש יכולות נכנסות ל-deprecation רשמי עם לפחות 12 חודשים עד הסרה: Roots, Sampling ו-Logging.

ההקשר הרחב: מפת הדרכים של 2026

ה-RC הזה לא צץ מהאוויר. מפת הדרכים של MCP ל-2026, שפורסמה ב-9 במרץ 2026 על-ידי David Soria Parra, ארגנה מחדש את העבודה סביב Working Groups — 'Working Groups הם עכשיו הכלי המרכזי לפיתוח הפרוטוקול'. במקום roadmap ממוקד-releases (ש'מרמז על רמת חיזוי שעבודת תקנים פתוחה רק לעיתים רחוקות מספקת'), הוגדרו ארבעה תחומי עדיפות: scalability של transport, תקשורת בין סוכנים (agent communication), התבגרות ממשל (governance), ומוכנות enterprise. ה-stateless protocol וה-headers החדשים הם מימוש ישיר של עמודת ה-transport; Tasks היא עמודת agent communication; ו-OAuth/OIDC ו-audit trails הם enterprise readiness.

<b>אם אתם מריצים שרתי MCP בפרודקשן: עברו ל-handles מפורשים, אמתו iss, והכינו את ה-gateway לנתב לפי Mcp-Method — לפני 28 ביולי.</b>