מפרט MCP מיולי 2026 מסיר כל צורה של מצב סשן (session state) משכבת הפרוטוקול, ומאלץ את כל המצב להתקיים בתוך חלון ההקשר (context window) של המודל. השינוי מאפשר לכל שרת MCP לענות על כל בקשה, מה שפותח את הדלת לפריסות חסרות מצב (stateless) לחלוטין מאחורי מאזני עומסים (load balancers), פונקציות serverless ו-Kubernetes pods המתרחבים אוטומטית.

למה השינוי הזה חשוב

מאז גרסתו הראשונה, MCP (Model Communication Protocol) שמר על לחיצת יד (handshake) קלה של סשן וכותרת Mcp-Session-Id כדי לעקוב אחר מצב השיחה לאורך מספר קריאות HTTP. עיצוב זה אפשר לשרת לזכור אילו handles של כלים, קצבי דגימה (sampling rates) או העדפות רישום (logging) שייכים ללקוח מסוים. הוא גם הציע זרמי Server-Sent Events (SSE) הניתנים להמשך, כך שחיבור שנותק יכול היה להמשיך בדיוק מהנקודה שבה הפסיק.

המפרט מ-28 ביולי 2026 מבטל לחלוטין את לחיצת היד של הסשן. כל בקשה נושאת כעת גרסת פרוטוקול ויכולות לקוח בשדה _meta, וכותרת ה-Mcp-Session-Id נעלמת. שדות ה-Roots, sampling ו-logging מסומנים כ-deprecated. בקיצור, פרוטוקול התקשורת (wire protocol) הוא כעת pure request-response; אין יותר "סשן" שיש לתחזק.

מה מפתחים צריכים לעשות אחרת

המצב (State) אינו lagi עניין של השרת; הוא חי בתוך חלון ההקשר של המודל. כאשר מודל צריך להתייחס למשאב חיצוני, הוא חייב לקבל handle מפורש מהשרת כחלק מתוצאת כלי (tool result). הבקשה הבאה כוללת את ה-handle הזה כארגומנט, והמודל מתייחס אליו כמו לכל token אחר.

מכיוון שחלון ההקשר הוא באפר (buffer) של tokens בגודל קבוע, כל handle צורך מקום שמתחרה במקום עם הנחיות המשתמש (prompts) או פלט המודל.

גם האמינות משתנה. ללא יכולת המשכיות ב-SSE או שליחה מחדש של הודעות, זרם שמתנתק מאבד את הבקשה לחלוטין. לקוחות חייבים להתחיל את הקריאה מחדש מאפס. עבור שאילתות stateless מהירות, זה מקובל; עבור משימות שליפה ארוכות או משימות סוכנים (agents) רב-שלביות, זה מחייב מפתחים לבנות לוגיקת ניסיונות חוזרים (retry logic) משלהם או לפצל את המשימה לחלקים קטנים יותר.

פרוטוקול Pilot ממלא את הפער

חוסר המצב (statelessness) של MCP הוא מכוון, אך הוא מותיר את שכבת הרשת ללא זהות ברמת החיבור או ערבויות לאמינות. פרוטוקול Pilot, היושב מתחת ל-MCP, ממלא את הפער הזה. Pilot מבסס את הזהות פעם אחת ומשתמש בהצפנה כדי לקשור את החבילות (packets) לשולח. מנקודת המבט של MCP, הלקוח פשוט שולח בקשת HTTP חדשה בכל פעם; Pilot שומר על שכבת התחבורה (transport) היסודית יציבה.

שני הפרוטוקולים משלימים זה את זה: MCP נשאר רזה, זול לכל בקשה וקל להרחבה מאחורי כל נקודת קצה (endpoint) של HTTP, בעוד Pilot מטפל בעבודה הקשה שפרוטוקולים מבוססי-סשן מסורתיים נהגו לספק.

יתרונות בקנה מידה גדול

  • ידידותי למאזני עומסים (Load-balancers) – אין צורך בקישוריות סשן (session affinity); כל backend יכול לשרת כל בקשה.
  • מוכן ל-Serverless – פונקציות יכולות לקום לפי דרישה, לטפל בבקשה ולהיסגר ללא מצב (state) שנותר.
  • Kubernetes autoscaling – ניתן להוסיף או להסיר Pods בחופשיות; שכבת הבקרה (control plane) כבר לא עוקבת אחר מפות סשן.

הפשרות (Trade-offs)

  • עומס (Overhead) של tokens – handles וכל מצב אחר תופסים כעת מקום בחלון ההקשר של המודל, ומתחרים ישירות ב-prompt ובתוצאה.
  • נכונות מונעת-מודל – המודל חייב להחזיר את ה-handles בצורה מדויקת; הזיה (hallucination) או טעות הקלדה עלולות לשבש את זרימת העבודה.
  • אין יכולת המשכיות מובנית – משימות ארוכות חייבות ליישם מנגנון נקודות שמירה (checkpointing) משלהן או לקבל את הסיכון של הפעלה מחדש מלאה.
  • ביטול (Deprecation) של כלי אבחון – שדות ה-Roots, sampling ו-logging נעלמו, כך שמפתחים מאבדים נקודת חיבור נוחה לניטור מעודן, אלא אם יוסיפו זאת בשכבת האפליקציה.

שורה תחתונה

על ידי מחיקת מצב הסשן מהתקשורת (wire), MCP 2026-07 הופך את הפרוטוקול ל-HTTP endpoint טהור שיכול לשבת מאחורי כל מאזן עומסים, פלטפורמת פונקציות או צומת קצה (edge node). היתרון הוא יכולת הרחבה (scalability) ברורה; החיסרון הוא שהמצב חי כעת בחלון ה-tokens המוגבל של המודל, והאמינות נשענת על הלקוח ועל שכבת ה-Pilot שבבסיס. ככל שסוכני AI יתפרסו משניות לשעות, האיזון בין תמחור זול לכל בקשה לבין הלחץ על תקציב ה-tokens יקבע אם המודל חסר המצב (stateless) יוכיח עצמו כניצחון ארוך טווח.