מבוא
תארו לעצמכם עולם שבו האפליקציה שלכם לא צריכה להתעדכן בכל פעם ש-API עובר מגירסה v1 לגירסה v2. עולם שבו ה-AI שלכם יכול ללמוד אוטומטית איך לעבוד עם APIs חדשים, בלי שתצטרכו לכתוב שורת קוד אחת נוספת. נשמע כמו חלום של מפתח? זה בדיוק מה שMCP מבטיח להביא לשולחן ואני כאן כדי לספר לכם למה זה כל כך מלהיב, ואיך זה יכול לשנות את הדרך שבה אתם מפתחים עם AI.
לאורך השנים התממשקתי עם צורות שונות של APIs, ותמיד מדובר באותן צרות: הדוקומנטציה לא מדוייקת, הגירסה משתנה וצריך לעדכן בקוד ולפחד מבאגים שקשורים למיגרציה ועוד. אבל זה מה יש.
כששמעתי על MCP בימיו הראשונים, התחלתי לשחק איתו ובניתי MCP שמחפש לי רשימת מוצרים בסופר אונליין ומוסיף אותם לעגלת הקניות. ככל שהתקדמתי בבניה וככל קראתי יותר על היכולות הטמונות בו הבנתי שמדובר בשינוי עמוק יותר. זו לא עוד צורה של API, זה משנה את הצורה שבה אנחנו מפתחים API.
על היסודות של MCP יש הרבה מאוד מאמרים באינטרנט, הנה על קצה המזלג:
- ההכרזה על MCP: …www.anthropic.com
- מאמר שמרחיב עם דוגמות קוד: …www.philschmid.de/mcp-introduction
- סקירה רחבה: …medium.com
במאמר הזה אני ארצה להיכנס יותר לעומק, בהנחה ואתם מכירים מה זה Tool Call (או בשמו הקודם Function Calling) ויש לכם ידע בסיסי על MCP.
במאמר נדבר על:
- ההייפ הנוכחי והפספוס הגדול
- התכונות הפחות מוכרות שיש לMCP
- הפוטנציאל האמיתי של MCP 1st party
- השוואה בין MCP ל-tool calling
- אתגרים בשימוש ב-MCP
- סיכום שמתמקד בפוטנציאל העתידי
ההייפ הנוכחי
ההייפ סביב MCP מוצדק רק חלקית בנקודת הזמן הנוכחית. כי הדבר הגדול נמצא עוד לפנינו:
כרגע ההתלהבות היא מLLM שמצליח לבצע פעולות פשוטות בפלטפורמה חיצונית. למעשה, כבר היה ניתן לפני שנתיים לתקשר עם כל API שמוגש בפורמט OpenAPI (לא להתבלבל עם OpenAI החברה). שיחקתי עם חיבורים כאלה עוד ב2023 וזה עבד מצוין כשהיה API ברור ופעולות פשוטות.
החיסרון היה שלרוב, APIs נבנו בגישת REST שעובד עם סוג אחד של מידע בכל קריאה. ולא מבצע פעולה שלמה, כמו לדוגמה הזמנת פיצה. בפועל, כשצריך להזמין פיצה זה בדרך כלל לא קריאת API אחת, אלא צרוף של כמה קריאות בתוספת לוגיקה מסויימת בין הקריאות. הLLM לא ידע ולא הכיר את התהליך המלא לביצוע פעולות, ושם הוא היה נתקע.
כשהגיע הMCP שמחתי מאוד, כי הוא קידם את הסטנדרט של עבודה עם Tools, כלומר פעולות כשמאחורי כל פעולה יכולות להתבצע כמה פעולות או קריאות API.
MCP הוא הרבה יותר מTools
לא פלא אם כן, שרוב הדיבור על MCP מתייחס לתכונה הכל כך שימושית, הפעלת הTools שלו. אבל MCP הוא הרבה יותר מזה. הפרוטוקול מאפשר לMCP לגשת למשאבים, להשתמש בפרומפטים מוכנים, ולקבל עדכונים כשמשהו חיצוני מתעדכן ועוד.
רגע, בואו נעבור על זה לאט יותר:
Resources
הפרוטוקול מאפשר לתת גישה למשאבים, הכוונה היא שהLLM יוכל לבקש מהשרת קריאה של קובץ, לוגים ועוד. אלו דברים שלא היו קיימים עד היום ויוצרים הבדל עצום בתוצאות. לדוגמה: ניתן לחבר שרת MCP שנותן גישה ללוג של הדפדפן. המשמעות היא שהLLM יכול לכתוב קוד שמיועד לדפדפן, ולבקש משרת הMCP להריץ את הקוד בדפדפן ולקבל את הלוגים שנוצרו במהלך הריצה, כדי להבין אם הקוד עובד. אם הלוג כולל שגיאה, הLLM יוכל אוטומטית לתקן את הקוד עוד לפני שהמפתח יבדוק את הקוד.
Notifications
זו יכולת שמתלבשת על המשאבים ומאפשרת ללקוח הMCP לקבל אוטומטית עדכונים מהשרת כשמשאב מתעדכן, לדוגמה כשנוסף תוכן ללוג. ככה שהLLM יוכל מיד לנתח את הלוג החדש.
Prompts
פרומפטים. הפרוטוקול מאפשר ליוצר הMCP לכתוב פרומפטים והנחיות שימוש, שהLLM יקח ויעבוד איתם מול הכלים הזמינים. בואו נמשיך עם דוגמת הפיצה, אנחנו רוצים לאפשר הזמנת פיצה בצ'ט עם LLM. יש לכם API עם כמה נקודות קצה – בחירת מיקום משלוח, בחירת זמן משלוח, רשימת תוספות זמינות, ולוגיקת הנחות (למשל, קנה שתיים וקבל את השלישית בחינם).
תחשבו על השלבים של API להזמנת פיצה:
- בדיקת זמינת משלוח לפי כתובת
- בדיקת זמינות משלוח לפי זמן
- כמות המגשים
- כל מגש – התוספות שרוצים
- החלת מבצעים וקופונים
- חישוב מחיר
- הזנת פרטי יצירת קשר
- הזנת פרטי אשראי
איך LLM יכול לעבור את כל השלבים האלה בצורה מדוייקת?! עכשיו, תחשבו על ה-AI שלכם: הוא צריך להבין את התהליך הזה, אבל הוא לא יודע באופן טבעי מה הסדר הנכון – האם צריך לבחור זמן משלוח לפני המיקום? האם ההנחה תחול אוטומטית, או שצריך להפעיל אותה ידנית?
פה מגיעה תכונה מעניינת שיש בMCP. בפרוטוקול MCP, אפשר לשים גם רשימת פרומפטים מוכנה שהיוזר מגדיר לLLM להשתמש בזה. אז אפשר לתת לו פרומפט שמגדיר לו את סדר הפעולות שהוא צריך לבצע. הLLM לוקח את הפרומפט שמגדיר לו את התהליך ומתחיל לעבוד איתו, לעבור פעולה פעולה.
פרומפט לדוגמה
"אתה עוזר וירטואלי שמסייע ללקוחות להזמין פיצה באופן יעיל ומדויק. עליך להוביל את הלקוח דרך כל שלבי ההזמנה בסדר הנכון ולהשתמש ב-API בצורה אופטימלית.
עליך לעבור את השלבים הבאים בדיוק בסדר המפורט:
- אימות כתובת המשלוח
- תבקש את כתובת המשלוח ותוודא זמינות משלוח לכתובת
- אם הכתובת אינה בטווח משלוח, הצע לבחור כתובת אחרת או איסוף עצמי
- בחירת זמן משלוח
- תבדוק את לבדיקת זמינות בזמן המבוקש
- תציע ללקוח חלונות זמן אפשריים נוספים אם הזמן המבוקש אינו זמין
- אין לעבור לשלב הבא עד שזמן המשלוח מאושר
- בחירת פיצות וכמויות
אם הלקוח ביקש יותר מ4 מגשים, תציע לו לחשב כמות לפי מספר האנשים
וכו'"
בAPI מסורתי, המתכנת נדרש לקבוע את כל הלוגיקה הזו בקוד עצמו, ונדרש לוודא תאימות בכל שינוי ב-API. לעומת זאת MCP יכול לכלול הוראות שה-AI יכול לעקוב אחריהן ישירות, ללא ידע מוקדם, ובכך הופך את החוויה לחלקה יותר.
זה מצריך ממפתח שרת הMCP להזמנת הפיצה, לחשוב בLLMית. לספר על התהליך. בפעולות עצמן, להחזיר תשובות אנושיות במקום שגיאות. לדוגמה אם המשתמש התחיל את הבקשה "תזמין לי שני מגשי פיצה", ולמעשה דילג על פרמטר של כתובת המשלוח, בAPI מסורתי, עונים בשגיאת 400 שפרמט מסויים חסר. אבל הLLM עשוי לפרש את זה כשגיאה, ולומר ללקוח שיש תקלה בMCP במקום זה, הכלי צריך להגיב: "תשאל את הלקוח מתי ואיפה הוא רוצה את זה". זה שינוי מחשבתי, תהליכי ופיתוחי.
הסופר-כוח של MCP: 1st party והסתגלות אוטומטית לשינויים
כיום יש קצת ג'ונגל, ורוב שרתי הMCP שנתקלתי בהם, אלו שרתי MCP שנוצרו על ידי צד שלישי, שעטף API של ממשק מוכר כמו ג'ירה, פיגמה, ואחרים.
אבל הפוטנציאל האמיתי טמון בשרתי MCP 1st party מטעם היצרן עצמו, כמו שגיטהאב וקלאוד פלייר שחררו. שאז זה תחליף טוב פי כמה מהAPI שלהם.
אחד היתרונות הכי משמעותיים של MCP הוא היכולת שלו להתמודד עם שינויים ב-API בצורה אוטומטית – וזה משהו שכל מפתח ששדרג פעם גרסה של API יעריך. בואו נחזור לדוגמה של חנות הפיצה שלנו. נניח שמפתחי ה-API מוציאים גרסה חדשה – עכשיו הכתובת היא store/v2/… במקום store/v1/…. אולי הם הוסיפו תכונה חדשה, שינו את שמות הפרמטרים, או שינו את מבנה התגובה.
עם UX שמשתמש בAPI מסורתי, זה סיוט. אתם צריכים ללמוד את השינויים, לעדכן את הקוד שלכם, לבדוק שהכל עובד, ולפעמים להתמודד עם באגים שנובעים מהשינוי. אבל אם יוצרי הAPI מפרסמים שרת MCP שבו הם כבר ביצעו את השינויים לעבוד עם v2, הקסם קורה: ה-LLM בצד הלקוח יכול ללמוד אוטומטית איך להשתמש בגרסה החדשה של ה-API, ישירות מההנחיות שמספק היצרן של הMCP. אין צורך לעדכן קוד, אין צורך ללמוד את השינויים – הכל קורה מאחורי הקלעים. זה חוסך זמן, מפחית את הסיכון לטעויות, ומאפשר לכם להתמקד במה שבאמת חשוב: בניית המוצר שלכם.
MCP & Tool calling השאלה היא מי מגדיר את הפונקציות
בדיון שהשתתפתי בו בנושא ברשת חברתית, היו מי שכתבו שהם כבר משתמשים בTool Calling (בעבר נקרא Function Calling), אז מה ההבדל אם הכלים מוגדרים בTool Calling או בשרת MCP?! למעשה, ההבדל הוא עצום, כי השאלה היא מי צריך להגדיר את הכלים ולתחזק אותם. בTool Calling האחריות היא על הצד שצורך את הAPI, היא דורשת ממכם לכתוב את כל הפונקציות בעצמכם. אתם צריכים להגדיר את הפרמטרים, לתאר את ההתנהגות, ולוודא שהכל עובד בצורה חלקה עם ה-LLM.
עם MCP, לעומת זאת, העבודה הזו נעשית על ידי יוצר הMCP. הוא מספק את ההנחיות המובנות, וה-LLM פשוט "קורא ומבצע". זה לא רק חוסך מכם את הצורך לכתוב קוד נוסף, אלא גם מבטיח סטנדרטיזציה – כל הכלים שמשתמשים ב-MCP עובדים באותה שפה, מה שמפחית את הסיכון לטעויות ומקל על מעבר בין ספקים שונים. לדוגמה החלפה בין ספק נתוני מזג אויר אחד לשני עשוי להסתכם בשינוי הקישור לשרת הMCP. בלי שינוי בקוד.
גם כאן יהיה הבדל עצום בין 1st party שבו היצרן עצמו דואג להגדיר את הפונקציות שלו, והן תמיד מדוייקות, לעומת 3rd party שיכול להוביל לחוסר תאימות מול היצרן.
אבל מה עם האתגרים?
צריך להודות שMCP הוא לא פתרון מושלם, לפחות לא עדיין. יש כמה אתגרים שצריך לקחת בחשבון, וצריך להכיר בזה ולדעת למה נכנסים.
אבטחה: אחד החששות הגדולים סביב MCP הוא אבטחה. מאחר שהפרוטוקול מאפשר ל-AI לבצע פעולות על סמך הנחיות משרתים חיצוניים, בנוסף בדרך כלל הMCP חשוף לAPI Token שמאפשר גישה לנתונים חיצוניים, לכן צריך להיזהר מאוד משימוש עיוור בשרתי MCP שהם 3rd Party, שגם אם לא יזיקו לכם, עלולים לעשות שימוש לרעה ולגשת לנתונים שלכם. גם שרתי 1st party צריכים להיבדק ולוודא שאין שם פוטנציאל לביצוע פעולות מזיקות או גישה לרשת פנימית וכדומה.
באזור חדש בDocker Hub הם מנסים לתת לזה מענה על ידי Docker Images של יוצרים מאומתים. שווה לבדוק את האפשרות הזו.
בשלות הפרוטוקול: MCP הוא עדיין חדש יחסית, ויש מי שטוענים שהוא לא בשל מספיק ליישומים בקנה מידה גדול. באלמנטור לדוגמה רצינו להפעיל שרת MCP שכולו בדפדפן, במקום להפעיל אותו במחשב עצמו (כמו שרת שמתחבר לקבצים המקומיים) או להפעיל אותו בענן (להפעיל שירותים חיצוניים) רצינו שהוא יפעיל פעולות בתוך האדיטור שלנו לעיצוב אתרים שחי בדפדפן. אבל מתברר שחלקים מסויימים במימוש לא כל כך מתאימים. למרות זאת, פיתחנו השלמות מעל MCP, ומפתחים כרגע מוצר חדש שיוכל להריץ שרתי MCP שפועלים בדפדפן.
לסיכום: איפה הפוטנציאל האמיתי
ההייפ שיש כרגע סביב MCP הוא בעיקר על היכולת של LLMs לבצע פעולות פשוטות, אבל זה לא הפוטנציאל האמיתי. הפוטנציאל הגדול של MCP נמצא ביכולת נוספות שלו כמו פרומפטים מובנים, ותגובה לאירועים כדי לשנות את הדרך שבה אנחנו חושבים על ממשקי תוכנה – מעבר מREST ותשובות של קוד 200 או 500 אל שיחה והכוונת הLLM להשיג את הפעולה המבוקשת.
כשיצרני מוצרים יתחילו לפתח שרתי MCP first-party, שמספקים יכולות עדכניות וללא צורך בעדכון קוד. המהפכה האמיתית בהיבט הזה תהיה כשיצרני המוצרים יתמכו בתהליכים שלמים במקום רק פעולות נקודתיות, וידאגו להחזיר תגובות אנושיות שמכווינות את הLLM בדרך הנכונה.
MCP הוא לא רק כלי טכני – הוא User Interface למשתמשים מסוג חדש, בינה שמשתמשת במוצר, ולכן זו דרך חדשה לחשוב על אינטראקציה בין מערכות, שמותאמת לעידן ה-AI. והפוטנציאל האמיתי שלו עוד לפנינו.
