תקן MCP החדש: הפרוטוקול הפך חסר מצב — ומה זה משנה

מה בדיוק קרה ב-28 ביולי?

יצאה גרסה חדשה של תקן MCP, החמישית במספר, ולפי המפרסמים היא העדכון הגדול ביותר של הפרוטוקול מאז ההשקה. הגרסאות בתקן הזה נקראות בשם התאריך שלהן, כך שהשם הרשמי הוא פשוט 2026-07-28.

השאלה הראשונה שכל אחד שואל היא אם צריך לעשות משהו. התשובה הקצרה: אם אתם מתקינים שרתי MCP ומשתמשים בהם — לא, ולא בקרוב. אם אתם כותבים או מריצים שרת — כן, ויש לכם זמן.

כדי לקבל תחושה של הסדר גודל: לפי הפוסט של Anthropic, חבילות ה-SDK של הפרוטוקול עברו 400 מיליון הורדות בחודש, פי ארבעה בתוך שנה, וקטלוג החיבורים של קלוד מונה יותר מ-950 שרתים. זה כבר לא ניסוי.

מה שמעניין בעדכון הזה הוא שכמעט כל שורה בו נגזרת מהחלטה אחת. אם מבינים את ההחלטה, שאר השינויים מפסיקים להיות רשימה ומתחילים להיות היגיון.

ההחלטה האחת: MCP הפסיק להיות שיחה

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

התקן החדש מחליף את זה במשהו שכל מי שבנה API מכיר: בקשה ותשובה. אין לחיצת יד, אין מזהה סשן, וכל בקשה נושאת בעצמה את גרסת הפרוטוקול ואת יכולות הלקוח בשדה _meta. המפרט מנסח את זה כך שכל בקשה מתארת את עצמה — ולכן כל בקשה יכולה לנחות על כל מכונה מאחורי מאזן עומסים פשוט.

מכאן נגזר כל השאר. אם אין סשן, אין מה לזכור; ואם אין מה לזכור, כל המנגנונים ששירתו את הזכירה מתייתרים.

סיימון וילסון, שכתב על זה אחרי שבנה שלושה כלים חדשים על התקן, מנסח את הרווח בשורה אחת: הגרסה הקודמת דרשה שתי בקשות HTTP — אחת כדי לקבל מזהה סשן ואחת כדי להפעיל את הכלי — והחדשה מסתדרת באחת. לדבריו זה מוריד משמעותית את המורכבות של כתיבת לקוח ושל כתיבת שרת גם יחד.

מה נעלם, בטבלה אחת

מה שהיה עד עכשיו	מה שיש בתקן החדש
לחיצת יד: initialize ואחריה notifications/initialized	אין. כל בקשה נושאת גרסה ויכולות בשדה _meta
כותרת Mcp-Session-Id	אין סשן ברמת הפרוטוקול. שרת שצריך מצב מנפיק מזהה משלו ומעביר אותו כפרמטר רגיל של כלי
בקשת GET לזרם התראות, resources/subscribe	subscriptions/listen: זרם אחד, והלקוח נרשם במפורש לסוגי השינוי שמעניינים אותו
ping ו-logging/setLevel	אין. רמת הלוג נקבעת לכל בקשה בנפרד בתוך _meta
בקשות שהשרת יוזם אל הלקוח	תבנית MRTR, בהמשך
התאוששות זרם שנקטע (Last-Event-ID)	אין. זרם שנשבר מאבד את הבקשה, והלקוח שולח אותה מחדש עם מזהה חדש

נוספה גם בקשה אחת שכל שרת מחויב לממש: server/discover, שבה השרת מכריז אילו גרסאות פרוטוקול הוא מבין, מה היכולות שלו ומי הוא. לקוח יכול לקרוא לה לפני הכול כדי לבחור גרסה, או לדלג עליה.

ואם השרת צריך לשאול משהו באמצע?

זו השאלה הראשונה שעולה כשמבטלים חיבור פתוח. קודם, שרת שהיה צריך אישור מהמשתמש או השלמה מהמודל פשוט יזם בקשה בכיוון ההפוך. בלי זרם פתוח אין לו לאן ליזום.

הפתרון נקרא MRTR — בקשות מרובות סבבים. השרת מחזיר תשובה מסוג input_required ובתוכה בדיוק מה שהוא צריך, והלקוח שולח את הבקשה המקורית מחדש עם התשובות מצורפות. במקביל, כל תשובה בפרוטוקול נושאת מעכשיו שדה resultType שאומר אם היא סופית או ביניים.

זה מסודר יותר, אבל צריך לומר את המחיר בפה מלא: מה שהיה קריאה אחת שממתינה הופך לשתי קריאות ולוגיקה בצד הלקוח. המפרט עצמו כותב שתהיה עלות מעבר, במיוחד למי שהסתמך על מזהי סשן.

מה מקבל שנה לחיות

יחד עם התקן אומצה מדיניות מסודרת של יציאה משימוש, עם שלושה מצבים לתכונה — פעילה, בדרך היציאה, הוסרה — וחלון מינימלי של שנים-עשר חודשים לפני הסרה. זה פרט משעמם ששווה יותר מכמה תכונות: עד עכשיו לא היה לוח זמנים שאפשר לתכנן לפיו.

מה שסומן, ומה המפרט מציע במקום:

• Roots (הדרך שבה הלקוח הכריז לשרת אילו תיקיות מותרות לו): להעביר תיקיות וקבצים כפרמטרים של הכלי, כ-URI של משאב, או בהגדרות השרת
• Sampling (שרת שביקש מהמודל של הלקוח להשלים טקסט): להתחבר ישירות ל-API של ספק המודל
• Logging: לכתוב ל-stderr בתעבורת stdio, או להשתמש ב-OpenTelemetry
• תעבורת HTTP+SSE הוותיקה, שכבר הייתה מסומנת מ-2025: לעבור ל-Streamable HTTP
• רישום לקוח דינמי בתקן OAuth מפנה את מקומו למסמכי מטא-דאטה של מזהה לקוח, ונשאר זמין לתאימות לאחור

מסגרת ההרחבות: MCP Apps, Tasks והרשאות ארגוניות

הליבה נעשתה רזה, ומה שיצא ממנה לא נזרק — הוא עבר למסגרת הרחבות רשמית. הרחבה מזוהה בשם עם תחילית של יצרן, וההרחבות הרשמיות נושאות את התחילית io.modelcontextprotocol.

שלוש שראוי להכיר:

• MCP Apps: מאפשרת לשרת להציג ממשק אינטראקטיבי בתוך השיחה — גרף, טופס, נגן וידאו — במקום להחזיר טקסט. זו ההרחבה עם ההשפעה הישירה ביותר על מה שמשתמש רואה
• Tasks: עבודה ארוכה שאינה מסתיימת בתוך קריאה אחת. בגרסה החדשה בודקים התקדמות ב-tasks/get במקום להמתין לתשובה חוסמת, ויש tasks/update להזרמת קלט תוך כדי ריצה
• הרשאות: הרחבה לזרימת client credentials לתקשורת בין מכונות, והרחבת הרשאות מנוהלות לארגונים שצריכים בקרת גישה מרוכזת

שני פרטים שחשוב לדעת על הרחבות: הן כבויות כברירת מחדל ודורשות הצטרפות מפורשת של המפתח, וכשצד אחד תומך והשני לא, הצד התומך אמור ליפול חזרה להתנהגות הליבה. כלומר הרחבה אינה אמורה לשבור לקוח שלא מכיר אותה.

לצד אלה הזכירה Anthropic שתי יכולות בצד המוצר: לוחות מחוונים למי שמפרסם חיבור, ומנהרות MCP בתצוגת מחקר מקדימה — גישה לשרת ברשת פרטית בלי לחשוף כתובת ציבורית.

למה זה ישפיע עליכם גם אם לא תכתבו שורת קוד

הקשר הוא כלכלי, לא טכני. שרת עם מצב חייב מכונה שרצה כל הזמן ומנגנון שמנתב כל בקשה למכונה הנכונה. שרת חסר מצב רץ על פונקציה שנעורה לפי בקשה ומתה אחריה.

המשמעות המעשית: פחות שרתים שצריך להריץ מקומית בתהליך npx, יותר חיבורים מנוהלים שמוסיפים בקליק. זה בדיוק הכיוון שקטלוג החיבורים של קלוד הולך אליו.

ויש כבר ראיות שזה לא תיאורטי: ארבעת ה-SDK בשכבה הראשונה — TypeScript, Python, Go ו-C# — כבר תומכים בתקן, ה-SDK ב-Rust בבטא, ושרת ה-MCP של GitHub הכריז על תמיכה עוד לפני שהתקן ננעל.

והאם קלוד כבר מדבר את התקן הזה?

כאן צריך להיות מדויקים, כי זה הפרט שקל לפספס בכל הסיקור: התקן שוחרר, הלקוחות עוד לא זזו. הפוסט של Anthropic כותב שהתמיכה מתגלגלת למוצרי קלוד בהמשך, ולא שהיא כבר כאן.

ואפשר לראות את זה בתיעוד עצמו. עמוד ה-MCP של קלוד קוד אינו מזכיר את גרסת התקן החדשה בכלל, וממשיך לתאר שתי תכונות שהתקן החדש מסמן ליציאה משימוש: הוא מסביר איך קלוד קוד עונה לבקשת roots/list ומתי הוא שולח התראה על שינוי, ומציע להוסיף שרת מרוחק בתעבורת SSE.

זו אינה שגיאה בתיעוד — זה פשוט המצב. אבל שווה לשים לב למה שהוא יוצר: כותב שרת שקורא את התיעוד של קלוד קוד יתבקש לממש roots/list, בזמן שהמפרט של הפרוטוקול ממש עכשיו מבקש לא לאמץ אותה בשרתים חדשים. שתי ההוראות נכונות כל אחת בעולמה, והן מצביעות לכיוונים הפוכים.

הכלל המעשי לתקופת המעבר: כותבים שרת חדש? תומכים בתקן החדש, ומשאירים תמיכה בקודם כל עוד הלקוחות שלכם שם. בדיוק בשביל זה נוספה server/discover.

אז מה עושים עכשיו?

• משתמשים בלבד: שום דבר. הפקודות לא השתנו, והחיבורים הקיימים ממשיכים לעבוד. אם עוד לא הוספתם שרת ראשון, ההסבר מאיפה מתחילים נמצא במדריך MCP
• מריצים שרת בפרודקשן: בדקו אם משהו בקוד שלכם מסתמך על מזהה סשן. זו נקודת המעבר היחידה שהמפרט מציין במפורש כיקרה
• כותבים שרת חדש: התחילו מהתקן החדש, ואל תאמצו את Roots, Sampling ו-Logging. עדכנו ל-SDK בגרסה שתומכת
• מחפשים את היכולת החדשה שכדאי לנסות: MCP Apps. ממשק בתוך השיחה הוא השינוי שהמשתמשים שלכם ירגישו, לא הסרת לחיצת היד

שורה תחתונה

MCP הפסיק להיות שיחה והפך לבקשה ותשובה, וזה השינוי היחיד שצריך לזכור — כל השאר נגזר ממנו. למי שמשתמש בשרתים זה לא דורש כלום, וכנראה ייטיב איתו: שרת שזול להריץ הוא שרת שיותר אנשים יריצו בשבילכם. למי שכותב שרתים יש עבודה, ולראשונה יש גם לוח זמנים ברור לעשות אותה — שנה לפחות לכל תכונה שיוצאת משימוש.

הדבר היחיד שכדאי לא לעשות הוא להסיק מהכתרות שהכול כבר עבד אתמול. התקן מוכן, ה-SDK מוכנים, והלקוחות — כולל קלוד קוד — עוד בדרך.

רוצים את הבסיס לפני שצוללים לתקן? מה זה MCP ואיך מוסיפים שרת ראשון. ומי שרוצה לקבל את העדכונים האלה בעברית פעם בשבוע — ערכת ההתחלה היא המקום.