ארכיטקטורת MCP: פירוט טכני מלא עם תרשימים

ארכיטקטורת MCP היא מערך הרכיבים וכללי התקשורת הבסיסיים שמאפשרים את קיומו של MCP (Model Context Protocol). MCP הוא תקן קוד פתוח, וארכיטקטורת MCP היא התשתית שעליה הוא פועל.

כל ארכיטקטורת MCP כוללת שלושה רכיבי ליבה ובנויה סביבם: מארח, לקוח ושרת. מסגרת התקשורת של MCP מתוארת לעיתים קרובות כמורכבת משכבת נתונים ומשכבת תעבורה. שכבת הנתונים היא מערך הכללים שקובע כיצד מעוצבות ההודעות (בקשות MCP נשלחות ב-JSON-RPC 2.0). שכבת התעבורה מעבירה את ההודעות האלה, ומשתמשת ב-Streaming HTTP לחיבורים חיצוניים.

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

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

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

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

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

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

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

אפליקציית המארח היא פלטפורמת התזמור המרכזית, והיא מתחברת למודל שפה גדול (LLM). כלים מוכרים כמו Perplexity ו-Claude Desktop יכולים לשמש כמארחים במערכת MCP.

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

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

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

תרשים של מארח MCP, כמו Perplexity, שמתזמר שלושה לקוחות MCP, שכל אחד מהם מחובר לשרת MCP משלו, כמו מסד נתונים, קבצים או API חיצוני.

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

שרתי MCP יכולים לספק גישה לשלוש קטגוריות של פרימיטיבים:

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

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

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

כל ארכיטקטורות ה-MCP פועלות לפי תהליך בסיסי של (1) אתחול וגילוי על ידי המארח, (2) תגובה של שרת ה-MCP, ו-(3) קריאה של המארח (לעיתים לפי החלטת מודל השפה), כשכל שלב מיוצג בהודעת JSON נפרדת.

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

בואו נראה איך גילוי כלים עובד באמצעות שתי דוגמאות (הן יכולות לחול גם על משאבים או הנחיות):

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

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

כך נראית בקשת tools/list לשרת MCP מאפליקציית פתקים דמיונית:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

בדוגמה הזו, “id”:101 מזהה את הבקשה באמצעות מזהה, כדי שהלקוח יוכל להתאים בין תגובות לבקשות, והשדה “params” מכיל מידע נוסף על הלקוח, כמו שם הלקוח (notes-app-client) והיכולות שלו.

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

כך עשויה להיראות בקשה:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

השדה “method” מודיע לשרת ה-MCP שמדובר בקריאה לכלי, “name” מציין איזה כלי להפעיל, ו-“arguments” מספק את הקלטים הנדרשים.

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

ל-MCP יש שני נתיבי תעבורה:

קלט/פלט סטנדרטי: נתיב זה משמש כששרת ה-MCP פועל באותה סביבה מקומית כמו אפליקציית המארח. הלקוח כותב את בקשת ה-JSON לקלט הסטנדרטי של השרת. השרת קורא אותה, מבצע את הפעולה המבוקשת וכותב את התגובה לפלט הסטנדרטי.
Streamable HTTP: כששרת ה-MCP פועל מחוץ לאפליקציית המארח, לקוח ה-MCP שולח בקשות לשרת באמצעות HTTP POST. השרת מגיב בהודעת JSON יחידה או בזרם Server-Sent Events (SSE), ערוץ "האזנה" קבוע שמאפשר לו להחזיר כמה הודעות לאורך זמן.

ארכיטקטורת MCP מרובת דיירים (multi-tenant) היא סוג של מימוש שיכול לשרת כמה משתמשים (דיירים) בו־זמנית.

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

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

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

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

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

גילוי כלים: אפליקציית הפתקים (המארח) משתמשת בלקוח ה-MCP שלה כדי לבקש מהשרת את הכלים הזמינים באמצעות בקשת tools/list. השרת מחזיר את השמות, התיאורים והקלטים הצפויים שלהם, כולל אלה של הכלי add-task. זה עשוי לקרות עוד לפני שליחת הנחיה.
קלט משתמש: שולחים בקשה לאפליקציית הפתקים מבוססת מודל השפה דרך הצ׳אטבוט שבאפליקציה, למשל: "צור משימה ביומן שלי לסקור את הטיוטה החדשה שלי בעדיפות בינונית."
עיבוד במודל: המארח שולח את הבקשה ואת הגדרות הכלים הרלוונטיות למודל השפה.
בחירת כלי: מודל השפה יוצר בקשת כלי מובנית שמציינת את הכלי ואת הקלטים שלו: add-task עם title: Review the draft ו-priority: Medium. המארח בודק אם הפעולה מותרת ומעביר את הבקשה ללקוח ה-MCP, ששולח הודעת JSON-RPC.
בקשה: לקוח ה-MCP שולח בקשת tools/call לשרת ה-MCP שלו.
הפעלת הכלי: שרת ה-MCP קורא ל-API של אפליקציית ניהול המשימות כדי ליצור משימה חדשה עם הכותרת והעדיפות שצוינו.
החזרת התוצאה: השרת שולח את התוצאה בחזרה ללקוח ה-MCP, שמעביר אותה למארח. המארח מוסיף אותה למידע שמסופק למודל השפה.
יצירת תשובה: מודל השפה משתמש בתוצאה כדי ליצור תשובה למשתמש, למשל: "יצרתי משימה לסקור את הטיוטה בעדיפות בינונית."

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

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

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

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

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

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

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

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

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

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

מהי ארכיטקטורת MCP?

רכיבי ארכיטקטורת MCP: מארחים, לקוחות ושרתים

מארח

לקוח

שרת

מהי שכבת הנתונים בארכיטקטורת MCP?

מהי שכבת התעבורה בארכיטקטורת MCP?

מהי ארכיטקטורת MCP מרובת דיירים?

תרשים ארכיטקטורת MCP: הסבר שלב אחר שלב

במה שונה ארכיטקטורת MCP מארכיטקטורת API מסורתית?

האם ארכיטקטורת MCP מאובטחת?

מה צופן העתיד לארכיטקטורת MCP?