MCP: לא תרופת פלא, אבל עדיין טוב למדי

חשיפת ה-MCP: פרוטוקול מאוחד להפעלת כלים

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

הזינוק בפופולריות של טכנולוגיית Agent, שנגרם על ידי עליית Manus, הזין את ההתלהבות של מפתחים גלובליים. MCP, המוצג כ’פרוטוקול מאוחד’ להפעלת כלי Agent, צבר תאוצה במהירות, ואבטח תמיכה משחקני בינה מלאכותית גדולים כמו OpenAI ו-Google תוך חודשיים בלבד. העלייה המהירה הזו הפכה את MCP ממפרט טכני יחסית לא ידוע לתקן יסודי בתוך המערכת האקולוגית של הבינה המלאכותית, ומסמנת ‘אירוע פנומנלי’ בתחום תשתית הבינה המלאכותית.

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

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

הגדרת MCP

MCP הוא פרוטוקול טכני פתוח שנועד לתקנן את האופן שבו מודלים גדולים של שפה (LLMs) מקיימים אינטראקציה עם כלים ושירותים חיצוניים. חשבו על זה כעל מתרגם אוניברסלי בתוך עולם הבינה המלאכותית, המאפשר למודלים של בינה מלאכותית ‘לשוחח’ עם מגוון רחב של כלים חיצוניים. הוא מספק שפה ומבנה משותפים עבור LLMs לבקש ולהשתמש בפונקציות המוצעות על ידי יישומים ושירותים שונים.

הצורך ב-MCP

לפני הופעת ה-MCP, הפעלת כלי בינה מלאכותית סבלה משני אתגרים מרכזיים:

• פיצול ממשק: כל LLM השתמש בפורמטים שונים של הוראות, בעוד שלכל API של כלי היה מבני הנתונים הייחודיים שלו. מפתחים נאלצו לכתוב קוד חיבור מותאם אישית עבור כל שילוב, מה שהוביל לתהליך פיתוח מורכב ולא יעיל.
• חוסר יעילות בפיתוח: גישת ‘תרגום אחד לאחד’ זו התגלתה כיקרה וקשה להרחבה. זה היה דומה להעסקת מתרגם ייעודי עבור כל לקוח זר, מה שמפריע ליעילות ולזריזות.

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

הבנת הפונקציונליות של MCP

ניתן לתפוס את הארכיטקטורה הטכנית של MCP כמערכת המורכבת משלושה מרכיבי ליבה: MCP Host, MCP Client ו-MCP Server. אלמנטים אלה פועלים בסינרגיה כדי להקל על תקשורת חלקה בין מודלים של בינה מלאכותית לעולם החיצון.

כדי לתפוס את תפקיד ה-MCP, שקול סביבה ארגונית מודרנית. באנלוגיה זו:

• משתמשים מייצגים מנהלים בכירים, האחראים להבנת צרכי המשתמשים וקבלת החלטות סופיות.
• מודלים גדולים של שפה (LLMs) (כמו קלוד או GPT) מבינים הוראות ניהוליות, מתכננים שלבי משימה, קובעים מתי להשתמש בשירותים חיצוניים ומאחדים מידע כדי לספק תשובות.
• מערכות Agent מתפקדות כעוזרים אישיים או מזכירים בכירים, המבצעים משימות לפי ההוראות.
• MCP משמשת כפלטפורמת תקשורת סטנדרטית או מערכת גישה לשירותים ארגוניים המשמשת את המזכירים. היא לא מקבלת החלטות אלא פועלת לפי ההוראות, מתקשרת עם ספקי שירות שונים בפורמט ופרוטוקול מאוחדים.

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

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

MCP: ארגז כלים הבנוי על Function Call

חשוב להבין ש-MCP אינו תחליף ל-Function Call המסורתי; אלא, זהו מרכיב משלים המשפר את יכולותיו.

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

MCP משמשת כמערכת סיווג כלים, המספקת מסגרת מובנית לארגון וגישה לכלים שונים. לכן, MCP לא מחליפה את Function Call אלא פועלת בשיתוף עם Agents לביצוע משימות מורכבות.

תהליך הפעלת הכלים השלם כולל שילוב של ‘Function Call + Agent + MCP System’.

בעיקרון, ה-LLM מביע את הצורך לקרוא לכלי ספציפי באמצעות Function Call. ה-Agent פועל לפי ההוראות כדי לבצע את הפעלת הכלי, בעוד ש-MCP מספקת מפרט הפעלת כלי סטנדרטי.

קחו את האנלוגיה הבאה: בוס (משתמש) רוצה קפה. במשרד (MCP Host), מנהל המשרד (LLM) מורה למזכיר (Agent) לקנות אמריקנו (Function Call). המזכיר בודק את רשימת הספקים ומוצא שספק קפה אמריקנו השתלב עם Meituan או עם מערכת הרכש האחידה של החברה (יישם MCP Server). לאחר מכן המזכיר מאתר את הספק במערכת הרכש (MCP Client) ומבצע הזמנה.

בעבר, ללא MCP, כאשר ה-LLM היה מוציא Function Call, ה-Agent היה מתרגם ומתחבר ישירות ל-API כדי להפעיל את הכלי. כל API דרש מצב הפעלה נפרד ורשימת כלים מוגדרת ומצב הפעלה עבור ה-Agent לפרש. עם MCP, ניתן להזמין ממשקי API רבים ישירות דרך MCP Client של הספק, מה שחוסך ל-Agent זמן ומאמץ. עם זאת, ה-Function Call של ה-LLM נשאר ללא שינוי, עדיין בפורמט {tool: ‘buy coffee’, ‘type’: ‘Americano’}.

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

אתגרי הפיתוח של MCP ונוף השוק

חידת הפיתוח

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

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

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

הופעת ה-MCP התקבלה בתחילה בברכה על ידי יישומי לקוח מקומיים, אך יישומי לקוח ענן ומפתחי שרת MCP התמודדו עם אתגרים.

MCP מקורו באפליקציית Claude Desktop של Anthropic, שתוכננה בתחילה כפרוטוקול ממשק להפעלת קבצים ופונקציות מקומיות, המושרשת עמוק בצרכים של צד הלקוח.

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

יישומי לקוח מקומיים כמו Cursor ו-Claude Desktop מינפו את MCP כדי לאפשר למשתמשים להוסיף באופן דינמי כלים על סמך צרכים אינדיבידואליים, ולהשיג הרחבה בלתי מוגבלת של יכולות עוזר ה-AI.

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

עם זאת, הערעור של MCP פוחת כאשר בוחנים פיתוח בצד השרת (MCP Server) ולקוחות ענן. גרסאות מוקדמות של MCP השתמשו במנגנון קישור כפול עבור שרתי ענן (מרוחקים), באמצעות חיבור ארוך SSE לדחיפת הודעות חד כיווניות מהשרת ללקוח וחיבור קצר HTTP לשליחת הודעות.

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

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

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

שנית, ל-MCP יש מגבלות בתחום יישומי הענן. סוכני AI בענן (סוכנים בצד השרת) פועלים בדרך כלל בשירותים חסרי מצב, מעבדים משימות לאחר קבלה ומשחררים משאבים עם השלמתם. שימוש ב-MCP Client בצד השרת דורש יצירה זמנית של קישור SSE, שליחת בקשת הפעלת כלי, קבלת התוצאה מה-SSE ולאחר מכן סגירת קישור ה-SSE, שהיא גישה לא יעילה המגדילה את המורכבות ומפחיתה את הביצועים. בקשת RPC בודדת צריכה להספיק בתרחיש זה.

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

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

צוות ה-MCP הפגין היענות למשוב משתמשים. לאחר קבלת משוב ממפתחים בצד השרת, MCP עדכנה את הפרוטוקול שלה ב-26 במרץ, והחליפה את הובלת ה-SSE המקורית בהובלת HTTP ניתנת להזרמה. הפרוטוקול החדש תומך הן בתרחישי שירות חסרי מצב הדורשים רק בקשות הפעלת כלי בודדות, והן בדרישות דחיפה בזמן אמת אשר נענו בעבר באמצעות קישורי HTTP + SSE כפולים.

שיפורים אלה מצביעים על כך שבעיות ה-MCP הנוכחיות נובעות ממגבלות עיצוב ראשוניות, אך אינן בלתי עבירות.

חוסר הסדר של השוק

אתגר נוסף העומד בפני MCP הוא השימושיות הנמוכה של יישומים רבים בשוק.

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

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

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

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

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

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

עורכי קוד כמו Cursor כוללים פונקציות פיתוח מובנות, מה שהופך את רוב כלי ה-MCP החיצוניים למיותרים.

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

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

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

MCP הוא טוב, לא תרופת פלא

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

ביקורת אחרונה אחת מתייגת את MCP כפרוטוקול פגום מכיוון שהוא אינו מכתיב את דפוסי האינטראקציה בין LLMs ל-MCP.

חלקם מצפים ש-MCP ישפר אוטומטית את קבלת ההחלטות של מערכת AI או יגביר את יעילות תכנון המשימות. ציפייה זו מבלבלת כלים עם אומנים.

הבעיה נובעת מחוסר התאמה קוגניטיבית - לצפות מפרוטוקול תקשורת לבצע משימות של מערכת אינטליגנטית. זה כמו להאשים את USB שלא עורך תמונות או לפסול תקני 5G שלא כותבים קוד. MCP הוא בעיקר ‘שקע כלי’ סטנדרטי, המבטיח תאימות לתקע ולא מכתיב באיזה מכשיר להשתמש או כיצד.

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

אנו מחפשים לעתים קרובות כדורי כסף בטכנולוגיה, פתרונות ישימים באופן אוניברסלי. בדומה לאקסיומה ‘אין כדור כסף’ של הנדסת תוכנה, לשימוש בכלי AI אין פתרון קסם. מערכת AI חזקה זקוקה לרכיבים מתוכננים: LLMs להבנה ויצירה, מסגרות Agent לתכנון וביצוע ו-MCP המתמקדת בממשקי כלים מאוחדים.

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

ישויות כמו Qwen של Alibaba, ‘Xinxiang’ של Baidu ו-Kouzi Space של ByteDance מאמצות את פרוטוקול MCP, ומנסות לבסס מערכות אקולוגיות פנימיות יעילות יותר של MCP.

עם זאת, ישנם הבדלים מרכזיים בפריסה: Baidu ו-ByteDance אגרסיביות יותר. Baidu מנסה גישת C-end, שילוב מספר מודלים של AI וכלים חיצוניים באמצעות ‘Xinxiang’ (Kokone) הממנפת את פרוטוקול MCP, בעיקר עבור מכשירים ניידים, כדי להשתלב בחיי היומיום של המשתמשים ולעודד אימוץ.

ל-Kouzi Space של ByteDance יש 60+ תוספי MCP. ניתן לגשת אליה באמצעות דף אינטרנט, והיא גם השיקה IDE מקורי ל-AI, Trae, התומך ב-MCP, שמטרתו בעיקר תרחישי פרודוקטיביות.

Alibaba שילבה את פרוטוקול MCP במוצרים כמו Alipay, ואפשרה הפעלת כלי AI בלחיצה אחת, ופתחה את קוד המקור של מודל Qwen3, התומך בפרוטוקול MCP, מה ששיפר את יכולות ה-Agent שלו.

מפתחי Tencent Cloud שחררו חבילת פיתוח AI התומכת בשירותי אירוח תוספי MCP. מנוע הידע הגדול של Tencent Cloud מאפשר למשתמשים לקרוא לתוספי MCP. סוכן אינטליגנטי לפיתוח תוכנה Craft שהושק על ידי CodeBuddy של Tencent Cloud תואם למערכת האקולוגית הפתוחה של MCP. בנוסף, Tencent Maps ו-Tencent Cloud Storage שחררו את MCP SERVER שלהם.

שימוש בכלי AI עשוי להתפתח מפעולה ישירה של כלי יחיד לשיתוף פעולה מקצועי של Agent, בדיוק כפי שסגנונות תכנות התפתחו משפת סף לאוריינטציה אובייקט.

בפרדיגמה זו, MCP עשויה פשוט להפוך לחלק מהתשתית הבסיסית, במקום לממשק הפונה למשתמש או למפתח. תוכנית שלמה יותר עשויה לדרוש ארכיטקטורות כמו Agent to Agents (A2A) כדי לשפר את תכנון המשימות ויעילות בחירת הכלים על ידי הגדלת רמות ההפשטה.

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