Tools ו-MCP

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

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

הבעיה: אינטגרציה נפרדת לכל כלי

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

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

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

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

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

Client, Server ודרכי חיבור

MCP server הוא התוכנה שחושפת יכולות — חיבור ל-GitHub, למסד נתונים, למערכת קבצים. MCP client הוא הצד שצורך אותן, בדרך כלל בתוך ה-harness שמריץ את הסוכן.

בזמן ריצה ה-client שואל את השרת אילו כלים יש לו, ומקבל רשימת תיאורים כמו בדוגמה למטה. ה-harness מעביר את התיאורים למודל כמו כל כלי אחר — מבחינת המודל אין הבדל בין כלי מקומי לכלי שמגיע משרת MCP. ב-MCP שדה הסכמה נקרא inputSchema; ב-API של ספקי המודלים השם משתנה (למשל input_schema), וה-harness מתרגם ביניהם.

שרת MCP יכול לרוץ בשתי דרכים עיקריות: כתהליך מקומי שה-harness מפעיל ומדבר איתו דרך stdin/stdout (נקרא stdio) — מתאים לכלים שעובדים על המחשב שלכם, כמו גישה לקבצים; או כשירות מרוחק שמדברים איתו ב-HTTP — מתאים לשירותי ענן, ובדרך כלל כולל הזדהות (למשל OAuth).

{
  "name": "query_database",
  "description": "מריץ שאילתת SQL לקריאה בלבד על מסד הנתונים של ההזמנות",
  "inputSchema": {
    "type": "object",
    "properties": {
      "sql": { "type": "string", "description": "שאילתת SELECT אחת" }
    },
    "required": ["sql"]
  }
}

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

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

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

אמון: שרת MCP הוא קוד של מישהו אחר

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

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