רשימות על עבודה עם AI
MCP למד את הטריק שחברת הסלולר שלכם עוד לא הבינה
כל חיבור MCP עבד עד היום כמו מוקד שירות ששוכח אתכם ברגע שמעבירים אתכם הלאה. זה משתנה, וזה אומר שעוד ועוד תוכנות שאתם כבר משתמשים בהן יתחברו ל-Claude.
כל נציג שואל אותה שאלה
מתקשרים כמעט לכל מוקד שירות, מעבירים אתכם פעמיים, ואתם כבר יודעים מה קורה. מסבירים שוב את מספר הלקוח. מסבירים שוב את הבעיה. לנציג בצד השני אין שום זיכרון מהשיחות הקודמות, כי הדבר היחיד שנשא את ההקשר הייתם אתם, שאמרתם אותו בקול, בפעם השלישית.
ככה בערך עבד MCP עד עכשיו. MCP הוא הפרוטוקול שמאפשר ל-Claude לדבר עם כלים שאתם כבר עובדים איתם, סלאק, מסד נתונים, מערכת פנימית, וכל חיבור שנבנה עליו התחיל במשהו שדומה מאוד לשיחת הטלפון הזאת.
הלחיצת יד שמאחורי הקלעים
שרת MCP נהג להתחיל בלחיצת יד. האפליקציה שלכם שלחה בקשת initialize, השרת החזיר session ID, וכל הודעה אחרי זה הייתה חייבת לחזור בדיוק לאותו מופע שרת שהנפיק אותו. אם חברה מריצה שלושה עותקים של השרת מאחורי load balancer, כל בקשה מלקוח אחד חייבת להמשיך להגיע לאותו עותק, סידור שמהנדסים קוראים לו sticky session.
sticky sessions הם בדיוק הפרט שאף אחד לא רוצה להתעסק בו, והוא צץ ברגע שמפעילים משהו בקנה מידה אמיתי. צריך חוקי ניתוב שמצמידים לקוח לשרת מסוים, או מסד נתונים רק כדי לזכור מי באמצע שיחה עם מי. זה גם הפך אירוח serverless לכמעט בלתי אפשרי, כי מופע כזה יכול להיעלם ברגע שסיים לטפל בבקשה, ואיתו נעלם ה-session ID.
פתק שכל הסיפור כבר כתוב עליו
הפרוטוקול פשוט ויתר על כל זה. אין יותר לחיצת יד, ואין מה לעקוב אחריו אחר כך. כל בקשה נושאת עכשיו לבד את מה שהשרת צריך כדי לענות עליה, פרטי הלקוח, גרסת הפרוטוקול, כותרת שמציינת בדיוק מה מבקשים. זה פחות דומה לשיחת טלפון ויותר לפתק שכל הסיפור שלכם כבר כתוב עליו, כך שמי שמרים אותו פשוט קורא ועונה. כל מופע שרת יכול לענות על כל בקשה, כי אף אחד מהם לא צריך לזכור אתכם באופן ספציפי.
השינוי הזה לבדו גם מסביר למה שרתי MCP סוף סוף יכולים לרוץ בנוחות על תשתית serverless. פונקציה שקמה, עונה על בקשה אחת, ונעלמת, עובדת מצוין עכשיו, כי אין לה יותר מה לשכוח.
לקח שפרוטוקולים ממשיכים ללמוד מחדש
לפני עשרים שנה REST לימד את האינטרנט בדיוק את אותו דבר. אם רוצים שמשהו יתרחב, ההקשר של הבקשה צריך לנסוע איתה, לא לחיות בחיבור שיושב על שרת מסוים. MCP ניסה קודם מודל עם state, בדיוק כמו הרבה פרוטוקולים מוקדמים אחרים באינטרנט, ועכשיו הוא חוזר בצעדים לאותה מסקנה בדיוק ש-REST כבר הגיע אליה. זו לא ביקורת על העיצוב המקורי. פרוטוקולים מבוססי session הגיוניים לגמרי עד הרגע שבו צריך באמת להתרחב, ו-MCP פשוט עוד לא הגיע לרגע הזה.
מה זה אומר לתוכנות שאתם כבר משתמשים בהן
הנה החלק שחשוב גם למי שלא בונה תוכנה בשביל הפרנסה. שרת MCP עם state דרש מישהו שמבין ברצינות ניהול sessions ואיזון עומסים לפני שהוא יכול לטפל בתעבורה אמיתית. שרת stateless נראה הרבה יותר כמו API endpoint רגיל, משהו שצוות קטן יכול להקים תוך אחר צהריים אחד.
זה משנה מי בכלל טורח לבנות אחד. תוכנת ההנהלת חשבונות שאתם משתמשים בה, מערכת ההזמנות, הכלי הפנימי שמנהל התפעול נשבע בו, לכולם עכשיו יש דרך זולה יותר להציע חיבור ל-Claude. הציפייה הכנה היא שעוד ועוד מהם יעשו את זה, לא כי הרעיון עצמו השתנה, אלא כי עלות הניסיון ירדה.
החלק שלא משתנה
שום דבר מכל זה לא נוגע בשאלה שבאמת חשובה ברגע ש-Claude מתחבר למשהו, והיא מה מותר לו לעשות ברגע שהוא בפנים. האם בקשה נענית על ידי שרת אחד או אחר לא קשור לשאלה אם הפעולה שמאחוריה בטוחה. connector שנותן ל-Claude לקרוא מהיומן שלכם או מהמייל שלכם צריך עדיין להיבנות לקריאה בלבד, לא לכתיבה, אלא אם מישהו אישר את זה במפורש. הפרוטוקול שנהיה קל יותר לבנייה הוא סיבה לצפות ליותר connectors כאלה. הוא לא סיבה להתרשל בהגדרת מה כל אחד מהם מותר לו לגעת בו.