MCP: בחינה ביקורתית של חסרונות ופוטנציאל

העמסת אחריות על MCP

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

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

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

החרב הפיפיות של LLM והחדרת הנחיות

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

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

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

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

אתגרי מדרגיות

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

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

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

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

התייחסות למגבלות באמצעות ממשק משתמש וניהול כלים

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

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

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

עם זאת, עצם קיום כלים בהקשר יכול לשנות באופן משמעותי את הפלט של מודל. בעוד שכלים רלוונטיים מבחינה הקשרית (המושגים באמצעות טכניקות כמו Retrieval-Augmented Generation או RAG) הם מועילים, הסתרת כל הכלים מאחורי בקשת ‘get_tools’ עלולה להזיק.

MCP כשכבת תעבורה והרשאה

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

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

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

הקלות של חשיפת נתונים רגישים

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

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

אנלוגיות ותכנון עירוני

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

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

LLM נוקטים פעולות לא רצויות

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

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

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

השאלה הבסיסית: למה לא פשוט להשתמש בממשקי API?

שאלה חוזרת ונשנית בדיונים על MCP היא מדוע לא פשוט להשתמש בממשקי API ישירות.

MCP מאפשרת ללקוחות LLM שהמשתמשים לא שולטים בהם ישירות (למשל, Claude, ChatGPT, Cursor, VSCode) ליצור אינטראקציה עם ממשקי API. ללא MCP, מפתחים יצטרכו לבנות לקוחות מותאמים אישית באמצעות ממשקי LLM API, מיזם יקר בהרבה משימוש בלקוחות קיימים עם מנוי ולימודם כיצד להשתמש בכלים ספציפיים.

מפתח אחד משתף את ניסיונו בבניית שרת MCP לחיבור לסינתיסייזר חומרת FM שלו באמצעות USB, מה שמאפשר עיצוב סאונד מונחה AI.

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

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

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

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

היעילות והשימושיות החוזרת של MCP

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

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

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

MCP וגישה למשאבים מקומיים

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

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

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

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

MCP הוא מטא-API המשלב נקודות קצה ופרטים תפעוליים שלהם במפרט, ומאפשר ל-LLM לקיים איתם אינטראקציה יעילה יותר.

MCP בתרחישים ספציפיים

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

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

MCP דומה למסגרת אפליקציית אינטרנט FastAPI לבניית תוכנה שיכולה לתקשר ברשת, שתוכננה במיוחד עבור חוויות סוכניות. ניתן לראות בו ‘Rails-for-Skynet’, המספק מסגרת סטנדרטית לפיתוח סוכני AI.

חששות לגבי שליטה של ספק

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

שימוש ב-OpenAPI מאפשר לסוכנים לאחזר מפרטי API מ-/openapi.json.

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

Sandbox וסיכוני אבטחה

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

זה דומה להזרקת SQL – מערכת המורכבת יחד שבה ניתן לנצל פגיעויות בכל נקודה עם יכולת צפייה מינימלית.

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

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

מיכל וגישה מבוקרת

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

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

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

מכונות וירטואליות וגישה לאינטרנט

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

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

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

השלבים המוקדמים של פיתוח MCP

MCP הוכרז רק בנובמבר 2024, וה-RFC מתפתח באופן פעיל.

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

הדחיפה הראשונית לעוזרי AI בסוף שנות ה-90 ותחילת שנות ה-2000 נכשלה מכיוון שמצברים תוכן עם שילוב אנכי וכוח קנייה בכמויות גדולות הוכיחו את עצמם כיעילים יותר. זה הוביל לעלייתן של פלטפורמות כמו Expedia ו-eBay.

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

גבולות הערך החופשי

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

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

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

אם ל-booking.com היה API, הם צפויים להחזיר את אותן תוצאות כמו באתר האינטרנט שלהם, אולי עם עיצוב JSON או XML.

עקיפת המתווך

אין היגיון רב שמתווך כמו booking.com יאפשר למשתמשים לעקוף לחלוטין את השירותים שלהם.

עם זאת, ייתכן שבתי מלון בודדים ימצאו את זה מועיל לעקוף את booking.com, מתווך שלעתים קרובות הם לא אוהבים.

Deep Research AI יכול לסרוק מלונות על סמך קריטריונים ספציפיים וליצור אינטראקציה עם שרתי Hotel Discovery MCP המופעלים על ידי מלונות בודדים, ולעקוף את הצורך לנווט בממשק ובמודעות של booking.com.

מקרי שימוש מעשיים

MCP יכול להקל על משימות כמו אחזור יומנים מ-Elasticsearch או שאילתות על מסדי נתונים בצורה מובנית יותר.

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

מודלים מכוונים

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

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

שיחות פתוחות ובעיות עסקיות

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

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

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

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

כלים ספציפיים למשתמש

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

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

סטנדרטים וטכנולוגיה מתפתחת

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

הורדת תוכניות שרת זעירות ממפתחים אקראיים כדי להוסיף ‘כלים’ ללקוחות LLM יכולה להיות מסוכנת.

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

קוד קלוד ושימוש בעולם האמיתי

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

זה מדגיש את החיסרון של הייפ ואימוץ מוקדם.

חלק מהמפתחים מוצאים שממשקי API של HTTP עדיפים על MCP עבור רוב מקרי השימוש. הם טוענים שהשימוש ב’כלי’ מסתכם בנקודות קצה של API עבור יכולות ופונקציונליות.

ממשקי API אינם מתארים את עצמם כברירת מחדל, מה שמייצג הזדמנות שהוחמצה עבור תומכי REST ו-HATEOAS להציג את הגישות שלהם.

MCP כחלופה ל-LangChain?

MCP תואר כבעל ‘ריח LangChain’ – לא פותר בעיה דחופה, מופשט יתר על המידה ומתקשה להסביר את היתרונות שלו.

אולי זה צריך להגיד ‘סוף שורה’ ולגרש האקרים שאפתנים לרשת המשחקים!

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

לעומת זאת, ככל שה-LLM יהפכו ליכולים יותר, ייתכן שכלים חיצוניים יהפכו פחות הכרחיים. למה שתרצה MCP להנעת פוטושופ כאשר ה-LLM יכול פשוט לערוך את התמונה ישירות?

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

בסיס המשתמשים ומודעות לאבטחה

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

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

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

יתירות ותשתית ענן

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

במה ישתמש ה-LLM כדי להתקשר למערכת OpenAPI? איך זה ייקשר למעטפת? איך המארח של ה-LLM יתזמר את זה?

MCP מספק דרך מובנית ל-LLM לבצע קריאות כלי.

שרתי MCP הם כבר שרתי HTTP.

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

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

CLI לעומת API

מדוע לא להשתמש ב-CLI ישירות, בהתחשב בכך ש-LLM מאומנים על שפה טבעית ו-CLIs הם פתרון נפוץ לקריאה וכתיבה על ידי בני אדם?

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

יש מחסור ביישומי עולם אמיתי.

יישומי מפתח של MCP

MCP משמש ב-Claude Desktop ובאפליקציות צ’אט AI נישתיות, כלי אוטומציה של קוד ומסגרות אוטומציה של סוכנים/LLM.

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

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

אנתרופיק פיתחה ‘תקן’ זה בוואקום, מה שהוביל לבעיות אבטחה.

JSON-RPC 2.0

MCP בנוי על JSON-RPC 2.0, פרוטוקול קל משקל המאפשר תקשורת בין לקוח לשרת באמצעות JSON.

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

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

זה לא תקן בוגר ולא תוכנן להיות מאובטח.

אמנם קיימות המלצות, אך הן אינן נאכפות או מיושמות.

Langchain וקריאת כלים

Langchain הוא אחת ממסגרות רבות המיישמות את תבנית ‘קריאת כלים’.

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

זה עוזר לתקן פרטים כך שכל שילוב עוזר/שילוב יהיה תואם.

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

אימות הוא חיוני ולא היה צריך להשמיט אותו מהגרסה הראשונית.

יש יותר מדי מורכבויות.