MCP – Model Context Protocol: המדריך המלא

מאת צוות מדיה דיל · 09.08.2026 · AI · 7 דק׳

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

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

מה זה MCP ולמה הוא נוצר

MCP הוא פרוטוקול תקשורת מבוסס JSON-RPC 2.0 שמגדיר ממשק אחיד בין לקוח (בדרך כלל אפליקציית AI או Agent) לבין שרת שחושף יכולות — כלים להרצה, מסמכים לקריאה, או תבניות פרומפט. הרעיון המרכזי דומה למה ש-LSP (Language Server Protocol) עשה לעולם עורכי הקוד: במקום שכל IDE יממש תמיכה נפרדת בכל שפת תכנות, כל שפה מממשת שרת אחד שמדבר בפרוטוקול משותף. באותו אופן, במקום שכל אפליקציית AI תממש אינטגרציה ייעודית לכל מערכת חיצונית, כל מערכת חושפת שרת MCP אחד שכל לקוח יודע לדבר איתו.

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

הארכיטקטורה: Host, Client, Server

MCP בנוי משלושה רכיבים:

• Host — האפליקציה שמריצה את המודל (למשל סביבת פיתוח, ממשק צ'אט או Agent Runtime). ה-Host אחראי על ניהול הרשאות, אישור משתמש והצגת התוצאות.
• Client — רכיב בתוך ה-Host ששומר על חיבור אחד-לאחד עם שרת MCP ספציפי, מתווך את הבקשות והתשובות.
• Server — תהליך עצמאי שחושף יכולות: כלים (Tools), משאבים (Resources) ותבניות פרומפט (Prompts). השרת יכול לרוץ מקומית (למשל גישה למערכת קבצים) או מרוחק (חיבור ל-API של SaaS).

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

איך זה עובד מתחת למכסה המנוע: Tools, Resources, Prompts

שרת MCP חושף שלושה סוגי יכולות עיקריים:

• Tools — פונקציות שהמודל יכול להריץ, עם סכימת קלט מוגדרת (JSON Schema). למשל search_orders(customer_id) או run_query(sql). אלו מקבילות ל-function calling הקלאסי, אבל מוגדרות בצד השרת ולא בקוד האפליקציה.
• Resources — מקורות מידע שניתן לקרוא (קבצים, רשומות DB, תוצאות API) שמזוהים ב-URI ייעודי. ה-Host יכול להציג אותם למשתמש או לצרף אותם להקשר של השיחה.
• Prompts — תבניות פרומפט מוגדרות מראש שהשרת חושף, כדי לתקנן משימות נפוצות (למשל "סכם טיקט תמיכה" עם פרמטרים קבועים).

כשמודל מחליט להשתמש בכלי, ה-Client שולח בקשת tools/call בפורמט JSON-RPC, השרת מריץ ומחזיר תוצאה מובנית (טקסט, תמונה, או שגיאה מובנית). כל התקשורת הזו נעה מעל שכבת תעבורה (transport) — בדרך כלל stdio לשרתים מקומיים, או HTTP עם Streamable HTTP/SSE לשרתים מרוחקים שתומכים בכמה לקוחות במקביל.

{
  "mcpServers": {
    "postgres-orders": {
      "command": "node",
      "args": ["./mcp-servers/postgres.js"],
      "env": { "DATABASE_URL": "postgres://...readonly" }
    },
    "crm-remote": {
      "url": "https://mcp.example.com/v1",
      "headers": { "Authorization": "Bearer ${CRM_TOKEN}" }
    }
  }
}

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

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

שיקול נוסף הוא גבולות ההרשאה: שרת MCP שרץ כתהליך נפרד יכול לקבל credentials מצומצמים (read-only, scope מוגבל) ללא תלות בהרשאות שיש לתהליך ה-Host עצמו — עיקרון של least privilege שמפורט במדריך אורקסטרציית סוכנים.

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

מכיוון ש-MCP הפך לסטנדרט פתוח, קיימים כבר עשרות שרתים קהילתיים לכלים שונים — וזה בדיוק המקום שבו נדרשת זהירות. שרת MCP חיצוני שמותקן בלי בדיקה יכול לחשוף תיאורי כלים (tool descriptions) שמכילים הוראות נסתרות למודל, תופעה שנקראת Tool Poisoning. באופן דומה, שרת עם הרשאות רחבות מדי (למשל גישת כתיבה מלאה למסד נתונים כשנדרשת רק קריאה) הופך לנקודת כשל יחידה במקרה של Prompt Injection. הרחבה בנושא בעמוד Tool Poisoning ובמדריך AI Guardrails. כלל אצבע: כל שרת MCP צריך scope הרשאות מינימלי, רישום (audit log) של כל קריאה, ואישור אנושי (human-in-the-loop) לפעולות בלתי הפיכות.

MCP מול Function Calling קלאסי

שאלה שחוזרת אצל לקוחות: אם כבר יש function calling, למה צריך MCP? התשובה היא שכבת ההפשטה. Function calling מגדיר את הכלים בתוך קוד האפליקציה — כל שינוי בכלי דורש דיפלוי מחדש של האפליקציה. MCP מפריד בין הגדרת הכלי (בשרת) לשימוש בו (בלקוח), כך שאפשר לעדכן, להחליף או להוסיף כלים בלי לגעת בקוד ה-Agent הראשי. זה שימושי במיוחד בארגונים עם כמה צוותים שכל אחד מתחזק שרת נפרד, ובמערכות Multi-Agent שבהן כמה סוכנים חולקים את אותם כלים.

טעויות נפוצות ביישום MCP

• חשיפת יותר מדי כלים לשרת אחד — כשמודל רואה עשרות כלים בבת אחת, איכות הבחירה שלו יורדת ועלות ה-token גדלה. עדיף לפצל לשרתים ממוקדים.
• תיאורי כלים לא מדויקים — המודל מסתמך על תיאור הכלי כדי להחליט מתי להשתמש בו; תיאור עמום מוביל לקריאות שגויות.
• התעלמות מטיפול שגיאות — שרת שמחזיר שגיאת HTTP גולמית במקום שגיאה מובנית גורם למודל "לנחש" מה קרה.
• העדר timeout וניהול חיבורים — שרת תקוע חוסם את כל שרשרת ה-Agent; יש להגדיר timeouts ומנגנוני retry.
• ערבוב שרתי צד שלישי לא מאומתים עם שרתים פנימיים קריטיים — הרצת שרת קהילתי לא מבוקר באותה סביבה כמו שרת שמחזיק גישה למסד נתונים רגיש מגדילה משמעותית את שטח התקיפה; יש להפריד סביבות ריצה ולהגביל הרשאות רשת בין השרתים.

ביצועים והשפעה על Latency

כל קריאת כלי דרך MCP מוסיפה עוד hop ברשת (אלא אם השרת רץ מקומית מעל stdio) — ובנייה נאיבית שמקשרת כמה קריאות MCP בשרשרת עלולה להכפיל את זמן התגובה הכולל של הסוכן. שני דפוסים מקטינים את הבעיה: קריאות מקבילות כשאין תלות בין הכלים (למשל שליפת נתוני לקוח ובדיקת מלאי בו-זמנית, לא ברצף), נושא שמפורט במדריך Parallel Tool Calling; וcaching ברמת השרת לתוצאות שלא משתנות בתדירות גבוהה, כדי לחסוך round-trip מיותר בפעם הבאה שאותו כלי נקרא עם אותם פרמטרים. חשוב גם להגדיר timeout סביר לכל כלי — כלי שתקוע במשך 30 שניות עוצר את כל שרשרת ה-reasoning של המודל וגורם לחוויית משתמש גרועה, גם אם בסוף הוא מחזיר תוצאה תקינה.

דוגמה מהשטח: מעבר מ-Custom Integrations ל-MCP

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

ניהול גרסאות ותאימות לאחור

נקודה שלרוב מתעלמים ממנה בשלב התכנון: שרת MCP הוא ממשק חוזה (contract) בין הלקוח לשרת, ולכן שינוי בסכימת כלי — למשל הוספת פרמטר חובה — יכול לשבור Agents שכבר "למדו" להשתמש בכלי בפורמט הישן. מומלץ לנהוג בשרתי MCP כמו ב-API ציבורי: לגרסא נתיבים (למשל orders-v2), לתעד שינויים לא תואמים לאחור, ולהריץ בדיקות רגרסיה על תיאורי הכלים לפני עדכון בפרודקשן. בסביבות עם כמה שרתים במקביל, כדאי גם לשקול שכבת ניהול מרכזית שמנטרת אילו שרתים פעילים, מהי זמינות (uptime) שלהם ואילו Agents תלויים בהם — נושא שמתקשר ישירות לארכיטקטורת AI Gateway.

שאלות נפוצות

האם MCP מחליף את ה-API הרגיל של הספק?

לא. MCP הוא שכבה נוספת מעל API קיים — השרת בדרך כלל עוטף API רגיל (REST, GraphQL, SQL) וחושף אותו בפורמט שמודל שפה יודע לצרוך בצורה עקבית. ה-API המקורי ממשיך להתקיים ולשמש צרכנים אחרים (אפליקציות front-end, שירותים פנימיים) שאינם קשורים למודל בכלל.

האם MCP עובד רק עם מודלים מסוימים?

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

איך שולטים בהרשאות של שרת MCP?

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

מה קורה אם שרת MCP נופל באמצע ריצה?

תלוי במימוש ה-Client — מערכות טובות מיישמות retry עם backoff וגם fallback שמדווח למודל שהכלי אינו זמין, כדי שיוכל להתאים את התוכנית.

האם כדאי לחשוף שרת MCP לאינטרנט הפתוח?

רק עם שכבת אימות (OAuth, API key) ו-rate limiting מוקפדים. שרת MCP חשוף ללא הגנה הוא וקטור תקיפה ישיר לכל המערכות שהוא מתחבר אליהן.

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

תגיות: MCP · Model Context Protocol · AI Agents · Tool Calling · JSON-RPC · אינטגרציות AI

← חזרה לבלוג · צור קשר