Tools ו-MCP

כלי (Tool) כיחידת היסוד — תזכורת קצרה

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

הבעיה: אינטגרציה משלה לכל כלי

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

התוצאה: בעיית N×M קלאסית — N כלים/מקורות מידע שצריך לחבר, כפול M אפליקציות/סוכנים שרוצים להשתמש בהם, כשכל צירוף דורש קוד גישור נפרד משלו. ככל שגדל מספר הכלים והאפליקציות, הבעיה גדלה בצורה לא פרופורציונלית.

תרשים המציג ארבע נקודות כחולות בטור משמאל (כלים) ושלוש נקודות כתומות בטור מימין (אפליקציות), עם רשת צפופה של קווים אפורים המחברים כל כלי לכל אפליקציה בנפרד — שנים-עשר חיבורים נפרדים, ממחיש את בעיית ה-N×M.
בעיית N×M: כל כלי דורש קוד אינטגרציה נפרד לכל אפליקציה שרוצה להשתמש בו

מה MCP בעצם מתקנן

MCP‏ (Model Context Protocol) הוא פרוטוקול סטנדרטי משותף לחשיפת יכולות ל-LLM: כלים (tools) שאפשר להפעיל, משאבי מידע (resources) שאפשר לקרוא, ותבניות פרומפט (prompts) מוכנות מראש — הכל בפורמט אחיד ומוסכם, ולא בפורמט ייעודי לכל אפליקציה.

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

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

מבנה Client-Server ברמת העיקרון

מבחינה מושגית (בלי להיכנס לפרטי הפרוטוקול ברמת ה-wire format): MCP server הוא התוכנה שחושפת יכולות מסוימות — למשל חיבור לגיטהאב, למסד נתונים, או למערכת קבצים — בפורמט הסטנדרטי של הפרוטוקול. MCP client (או host) הוא האפליקציה שצורכת את היכולות האלה — למשל ה-harness שמריץ את הסוכן.

בזמן ריצה, ה-client שואל את ה-server "אילו יכולות יש לך?", מקבל רשימה מתוארת בפורמט אחיד, ומעביר אותה למודל בדיוק כמו כל tool אחר — מבחינת המודל, אין הבדל בין tool מקומי לתוצאת שאילתת MCP; ההבדל הוא רק איך ה-harness השיג את תיאור הכלי מלכתחילה.

JSON
// דוגמה: תיאור כלי כפי שהוא מוחזר משרת MCP
{
  "name": "query_database",
  "description": "מריץ שאילתת SQL בקריאה בלבד",
  "input_schema": {
    "type": "object",
    "properties": {
      "sql": { "type": "string" }
    }
  }
}

למה זה חשוב בפרקטיקה

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

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