פרוטוקול Model Context (MCP) שוחרר כסטנדרט קונקרטי להפיכת מודלי שפה גדולים (LLMs) לסוכנים שיכולים לקרוא לכלים חיצוניים בלולאה מדידה ומאובטחת. על ידי הגדרת "תקע" משותף בין כל מארח (host) המכיר את ה-MCP לבין כל שרת MCP, הפרוטוקול מאפשר למפתחים להחליף קוד ad-hoc בתהליך עבודה צפוי וניתן לביקורת.

מדוע LLMs זקוקים לפרוטוקול

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

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

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

האנטומיה הדו-חלקית של סוכן MCP

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

הגדרת סוכן (התבנית)

  • לולאת מארח (Host loop) – המנצח (orchestrator) המניע את מחזור השאלה-כלי-קריאה-החלטה.
  • הקשר מערכת (System context) – פרסונה והוראות ברמה גבוהה המעצבות את התנהגות המודל.
  • סט שרתי MCP – קטלוג של מקורות כלים זמינים שהמארח עשוי לקרוא להם.
  • מדיניות כלים – רשימה מפורשת של הכלים המותרים עבור סוכן נתון.
  • בחירת LLM – המודל הספציפי שיפיק את הנימוק הטקסטואלי.
  • מגבלות סיום – מספר מקסימלי של איטרציות ותקציב טוקנים למניעת לולאות אינסופיות.
  • חוזה משימה – תיאור פורמלי של הקלטים שהסוכן מקבל ופורמט הפלט שהוא מחזיר.
  • אסטרטגיית הקשר – כללים לאופן שבו היסטוריית השיחה נחתכת או מסוכמת כדי להישאר במסגרת מגבלות הטוקנים.

מופע סוכן (המשימה הרצה)

  • מטרה – בקשת המשתמש שמתחילה את הלולאה.
  • הקשר עבודה – היסטוריה שנצברה, כולל תוצאות כלים קודמות.
  • הרשאות (Credentials) – טוקנים או סטים של הרשאות הנדרשים כדי להפעיל את הכלים שנבחרו.
  • תקציב שנצרך – ספירה של טוקנים שהושקעו וצעדים שבוצעו עד כה.

אלמנטים אלו מראים הן מה סוכן מורשה לעשות והן מה הוא עושה כרגע.

כיצד MCP משנה את זרימת הפיתוח

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

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

לנראות זו יש שני יתרונות מעשיים:

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

מה עדיין לא מוגדר

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

מה לעקוב אחריו בהמשך

  • ערכות מדדים (Metric suites) – המאמר הבא בסדרה מבטיח רשימת תיוג של המספרים שמפתחים צריכים לעקוב אחריהם (הוצאת טוקנים, מספר איטרציות, שיהוי/latency לכל כלי). מדדים אלו יהפכו לבדיקות הבריאות (health checks) דה-פקטו עבור כל סוכן מבוסס MCP.

בשורה התחתונה

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