מה זה MCP? הסבר מלא על Model Context Protocol
MCP, ראשי תיבות של Model Context Protocol, הוא תקן פתוח לחיבור יישומי AI למערכות חיצוניות. אם הגעתם לכאן בחיפוש אחר מפרק MCP — המפרק המסרקי-גליל בכף היד — העמוד הזה עוסק בפרוטוקול תוכנה ולא באורתופדיה. בשורה אחת: במקום שכל מודל ילמד מחדש כל מערכת, השרת מצהיר אילו יכולות יש לו, הלקוח מגלה אותן בזמן ריצה, והמודל מבקש להפעיל אותן — הכול מעל JSON-RPC 2.0.
גרסת המפרט שמסומנת כנוכחית: 2025-11-25. בדקנו בעצמנו: 27.07.2026.
עמוד הגרסאות הרשמיההגדרה המדויקת, ולמה כל מילה בה חשובה
MCP הוא פרוטוקול ברמת האפליקציה. הוא לא מגדיר מודל, לא מגדיר prompt ולא מגדיר איך סוכן מחליט מה לעשות. הוא מגדיר דבר אחד בלבד: איך צד אחד מצהיר על יכולות, איך הצד השני מגלה אותן, ואיך קוראים להן. ההודעות עצמן הן JSON-RPC 2.0 — אותו פורמט בקשה-תשובה שמאחורי Language Server Protocol. הדמיון אינו מקרי: LSP פתר בעיה זהה בין עורכי קוד לשפות תכנות, ו-MCP מחיל את אותו פתרון על מודלים ומערכות.
שלושה תפקידים, ורוב הבלבול בשיחות על MCP נובע מכך שמערבבים ביניהם. ה-host הוא היישום שאתם פותחים: Claude Desktop, ChatGPT, VS Code. ה-client הוא רכיב בתוך ה-host, וכל client מחזיק חיבור אחד בלבד מול שרת אחד. ה-server הוא התהליך שחושף את היכולות. כשמישהו אומר "התקנתי שלושה MCP", מה שקרה בפועל הוא ששלושה clients נפתחו בתוך אותו host, כל אחד מול שרת אחר. ההבחנה נשמעת פורמליסטית עד הפעם הראשונה שצריך לדבג, ואז היא ההבדל בין "ה-AI לא רואה את הקבצים" לבין "ה-client נכשל ב-initialize".
שתי תעבורות. ב-stdio השרת רץ כתת-תהליך על המכונה שלכם וההודעות עוברות בצינור. בתעבורת HTTP בסטרימינג השרת רץ מרחוק — וכאן, לא לפני כן, מתחילה שאלת ההרשאות. חשוב לדעת ש-authorization במפרט היא OPTIONAL, ולגבי stdio המפרט אומר במפורש:
Implementations using an STDIO transport SHOULD NOT follow this specification, and instead retrieve credentials from the environment.
לגרסאות יש כלל שכדאי להכיר לפני שמתכננים פרויקט. מזהה הגרסה הוא תאריך בפורמט YYYY-MM-DD, והוא עולה רק כשיש שינוי שובר-תאימות; גרסה שמסומנת Current עדיין יכולה לקבל שינויים תואמים בלי שהמזהה שלה ישתנה. המשמעות המעשית: המשפט "אנחנו על גרסה 2025-11-25" הוא הצהרה חלשה יותר משנדמה, ולכן אנחנו מקשרים לעמוד הגרסאות במקום לקבע מספר בטקסט.
האנטומיה: מי מדבר עם מי, ואיפה עובר גבול האמון
הדיאגרמה מראה את מה שהטקסט מתקשה להעביר: את כלל אחד-לאחד. שני clients בתוך host אחד, שני שרתים נפרדים, שני חיבורים נפרדים. client אינו מרבב חיבורים, ואף client לא מגיע לשרת של client אחר. הקו המודגש הוא מסלול בקשה אחת, מהרגע שהמודל ביקש כלי ועד שהמערכת העסקית ענתה.
הגבול המקווקו הוא הנקודה שבה נגמרת ההצהרה ומתחילה ההרשאה. מעליו נמצא הקשר של מודל, שאפשר להזרים אליו טקסט מכל מקום. מתחתיו יושבים מפתחות, טוקנים והרשאות כתיבה. כל שאלה רצינית על אבטחת MCP היא שאלה על מה עובר את הקו הזה, לאיזה כיוון, ומי אישר.
שלוש יכולות לשרת, שלוש ללקוח
המפרט מנסח את זה בזהירות שכדאי לשמר: שרת מציע כל אחת מתוך שלוש יכולות, ולקוח רשאי להציע שלוש אחרות. "כל אחת" ו"רשאי" הן המילים החשובות. שרת שחושף Tools בלבד הוא שרת MCP תקין לחלוטין — וכך בדיוק מתנהג השרת הרשמי שהרצנו בהמשך העמוד, שמצהיר על Tools ותו לא.
מה שרת עשוי להציע
- Resources
- מידע לקריאה, מזוהה ב-URI: קובץ, רשומה, תוצאה של שאילתה. מי שמחליט אם להכניס resource להקשר הוא היישום — לא המודל. בפועל זה אומר שאם ה-host שלכם לא בנה ממשק לבחירת resources, השרת יכול לחשוף אותם ואף אחד לא ישתמש בהם.
- Prompts
- תבניות אינטראקציה מוכנות שהמשתמש בוחר במפורש — התפריט שנפתח כשמקלידים לוכסן, או "הוסף הקשר". זו היכולת היחידה מהשלוש שנשלטת ישירות בידי המשתמש, ולא בידי המודל או היישום — ולכן היא גם היחידה שלא תופיע בשום מקום אם ה-host לא בנה לה ממשק בחירה.
- Tools
- פעולות שהמודל יכול להחליט לקרוא להן. זו היכולת שכולם מתכוונים אליה כשהם אומרים "MCP", וזו גם היחידה שבה ההחלטה היא של המודל. כלי שכותב, מוחק או שולח כסף שייך לכאן — ולכן כאן נדרש אישור אנושי, ולא במקום אחר.
מה לקוח רשאי להציע
- Sampling
- השרת מבקש מהלקוח השלמה מהמודל. המשמעות המסחרית: שרת יכול להשתמש ב-LLM בלי להחזיק מפתח API משלו ובלי שתשלמו לו על טוקנים בנפרד — הטוקנים נצרכים בחשבון של הלקוח.
- Roots
- הלקוח מודיע לשרת באילו תיקיות או URIs מותר לו לעבוד. בתעתיק שבהמשך תראו את זה קורה: הלקוח שלנו לא הצהיר על Roots, והשרת נפל חזרה לרשימת התיקיות שקיבל בשורת הפקודה. זו יכולת של הלקוח שקובעת גבול הרשאות אמיתי, ולכן היעדרה נראה מיד: השרת עצמו כתב ל-stderr שהלקוח לא תומך ב-Roots.
- Elicitation
- השרת מבקש קלט נוסף מהמשתמש באמצע פעולה. המנגנון נושא כללים נורמטיביים חדים: שרתים חייבים שלא להשתמש במצב form כדי לבקש סיסמאות, מפתחות API, טוקני גישה או פרטי תשלום, ולהשתמש במצב URL במקום. לקוחות חייבים שלא למשוך מראש את הכתובת, שלא לפתוח אותה בלי הסכמה מפורשת, ולהציג אותה במלואה לבדיקה.
SEP-2577
והערה שתחסוך לכם ארכיטקטורה מיותרת. בגרסת 2026-07-28 סומנו Roots, Sampling ו-Logging כמיושנים, במסגרת SEP-2577. הן, בלשון המפרט, remain fully functional during the deprecation window, והמועד המוקדם ביותר להסרה מנוסח כ-First revision released on or after 2027-07-28.
מסלולי המעבר שהתקן מפרסם, מילה במילה: עבור Roots — Pass directories or files via tool parameters, resource URIs, or server configuration; עבור Sampling — Integrate directly with LLM provider APIs; עבור Logging — Log to stderr for stdio transports; use OpenTelemetry for observability. אם מישהו מציע לכם היום ארכיטקטורה שנשענת על Sampling, זו הפסקה שכדאי לצרף לבקשת התקציב.
מה MCP מחליף — ומה הוא לא מחליף
לפני MCP, כל צירוף של יישום AI ומערכת עסקית היה פרויקט בפני עצמו. m יישומים מול n מערכות ייצרו m כפול n אינטגרציות, לכל אחת הגדרות כלים משלה, מחזור שחרור משלה ובעלים משלה. תקן משותף הופך את המכפלה לחיבור: m ועוד n.
אבל צריך לדייק, כי כאן נמצא רוב השיווק הלא מדויק בתחום. MCP לא מחליף את ה-API. שרת MCP ל-Priority עדיין קורא ל-REST API של Priority, ומישהו עדיין צריך לכתוב את הקוד הזה, לטפל בשגיאות שלו ולתחזק אותו. מה שהתקן מחליף הוא שכבת התיאור: במקום שכל יישום AI ילמד מחדש איך נראה ה-API ומה מותר לעשות בו, השרת מתאר את עצמו פעם אחת בפורמט שכל לקוח יודע לקרוא.
ההחלפה השנייה מעשית יותר, ופחות מדברים עליה: function calling ידני. עד MCP, הגדרות הכלים חיו בקוד של האפליקציה — כדי להוסיף כלי, שחררתם גרסה. עכשיו הן חיות בשרת ומתגלות בזמן ריצה. זה בדיוק מה שהופך את MCP לנוח, וזה בדיוק מה שהופך אותו למסוכן: רשימת הכלים והתיאורים שלהם יכולה להשתנות בין חיבור לחיבור, בלי שאף אחד אצלכם שחרר דבר ובלי שאיש אישר.
ומה MCP לא מחליף אצלכם בארגון: את מנוע התהליכים. אין בפרוטוקול מתזמן, אין trigger, אין מדיניות ניסיון חוזר ואין ניהול מצב של תהליך ארוך. אם אתם מחפשים "כשמגיע ליד חדש, בצע שבעה שלבים ותיעד", זו עדיין עבודה של שכבת אורקסטרציה — MCP הוא איך היא מדברת עם המערכות, לא היא עצמה.
ההשוואה המלאה: MCP מול אינטגרציית APIדוגמה עובדת: הרצנו שרת וקראנו את מה שהוא ענה
הדרך המהירה ביותר להבין MCP היא להריץ שרת אחד ולקרוא את התשובה. בחרנו את שרת הקבצים הרשמי מהמאגר של פרויקט MCP עצמו, מוצמד לגרסה מדויקת. קודם ההצהרה שה-host קורא בעלייה, ואז שלוש ההודעות שהחליפו בינינו.
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/[email protected]",
"/Users/you/Documents"
]
}
}
}$ npx -y @modelcontextprotocol/[email protected] ./probe -> {"jsonrpc":"2.0","id":1,"method":"initialize","params": {"protocolVersion":"2025-11-25","capabilities":{}, "clientInfo":{"name":"mcpisrael-probe","version":"1.0.0"}}} -> {"jsonrpc":"2.0","method":"notifications/initialized"} -> {"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}<- {"result":{"protocolVersion":"2025-11-25", "capabilities":{"tools":{"listChanged":true}}, "serverInfo":{"name":"secure-filesystem-server", "version":"0.2.0"}},"jsonrpc":"2.0","id":1} <- 14 tools. One entry, verbatim (schemas elided): {"name":"write_file","title":"Write File", "description":"Create a new file or completely overwrite an existing file with new content. Use with caution as it will overwrite existing files without warning. Handles text content with proper encoding. Only works within allowed directories.", "annotations":{"readOnlyHint":false,"idempotentHint":true, "destructiveHint":true,"openWorldHint":false}, "execution":{"taskSupport":"forbidden"}, ...} # stderr Secure MCP Filesystem Server running on stdio Client does not support MCP Roots, using allowed directories set from server args: [ './probe' ]
מקור: החבילה ב-npm · המאגר הרשמי · הרצנו: 29.07.2026
שלוש הודעות, וכל הפרוטוקול כבר גלוי. initialize הוא משא ומתן על גרסה: ביקשנו 2025-11-25 והשרת החזיר 2025-11-25. אילו תמך רק בגרסה ישנה יותר, היה מחזיר אותה, והלקוח היה צריך להחליט אם להמשיך. לחיצת היד הזו שייכת לגרסה שמסומנת כנוכחית: גרסת 2026-07-28 מסירה אותה לגמרי לטובת ליבה חסרת מצב, שבה כל בקשה נושאת בעצמה את גרסת הפרוטוקול שלה.
capabilities היא הצהרה, לא שאלון. השרת הזה הצהיר על tools בלבד, עם listChanged. אין Resources ואין Prompts — וזה שרת רשמי של הפרויקט. זו התשובה הטובה ביותר לשאלה אם שרת חייב לחשוף את שלוש היכולות: הוא לא חייב, והמפרט כותב "כל אחת מהן" בדיוק כדי לאפשר את זה.
tools/list החזיר ארבעה-עשר כלים. הכלי write_file הגיע עם annotations: readOnlyHint שקר, destructiveHint אמת, idempotentHint אמת, openWorldHint שקר. הערכים האלה נראים כמו בקרת הרשאות. הם לא. הסכימה עצמה אומרת:
NOTE: all properties in ToolAnnotations are hints. They are not guaranteed to provide a faithful description of tool behavior (including descriptive properties like `title`). Clients should never make tool use decisions based on ToolAnnotations received from untrusted servers.
ומפרט הכלים מוסיף, בניסוח שלא השתנה בין הגרסאות: For trust & safety and security, clients MUST consider tool annotations to be untrusted unless they come from trusted servers. גם ברירות המחדל בנויות להיות לא נוחות בכוונה — readOnlyHint ברירת המחדל שלו היא שקר, ו-destructiveHint ברירת המחדל שלו היא אמת. כלומר שרת ששותק נחשב מסוכן, לא בטוח. זו הסיבה שאישור הכתיבה אצלנו נאכף בשער שאנחנו מתחזקים, מול רשימת היתר, ולא לפי דגל שהשרת מדווח על עצמו.
ושימו לב לשורה האחרונה ב-stderr. הלקוח שלנו לא הצהיר על Roots, ולכן השרת נפל חזרה לרשימת התיקיות שקיבל בשורת הפקודה. במילים אחרות: גבול ההרשאות בפועל נקבע כאן על ידי ארגומנט בשורת פקודה, ולא על ידי הצהרה של הלקוח. זה מה שקורה כשיכולת לקוח קיימת במפרט אבל לא מיושמת בלקוח.
והערה שמשלימה את התמונה, כי בלעדיה הדוגמה הזו מטעה: לשרת הזה בדיוק היו שתי חולשות ידועות. CVE-2025-53109 בציון CVSS 8.4 — בדיקת symlink שבחנה את תיקיית האב של הקישור במקום את היעד שלו, כך שקישור יכול היה להגיע לקבצים כמו /etc/sudoers; ו-CVE-2025-53110 בציון CVSS 7.3 — התאמת prefix נאיבית שאפשרה לנתיב בשם allowed_dir_sensitive_credentials לעבור רשימת היתר של allowed_dir. דווחו ב-30.03.2025, תוקנו ב-01.07.2025. אנחנו הרצנו גרסה מאוחרת ומוצמדת. "רשמי" אינו מילה נרדפת ל"בטוח", והצמדת גרסה היא מה שמאפשר לכם לדעת בדיוק מה רץ אצלכם.
מה MCP הוא לא
- לא מודל ולא סוכן
- MCP לא חושב, לא מתכנן ולא מחליט. הוא מעביר הצהרות וקריאות. סוכן שבנוי סביבו טוב בדיוק כמו המודל וההוראות שמפעילים אותו.
- לא מנוע אוטומציה
- אין מתזמן, אין triggers, אין ניסיונות חוזרים ואין ניהול מצב. השוואה ל-Zapier, ל-Make או ל-n8n היא השוואה בין שכבות שונות — הם מנהלים תהליך, MCP מגדיר איך מדברים עם המערכת שבקצה.
- לא שכבת אבטחה
- authorization היא OPTIONAL בפרוטוקול, ובתעבורת stdio המפרט אומר במפורש לא ליישם אותה אלא למשוך אישורים מהסביבה. חיבור MCP אינו מאובטח בזכות היותו MCP; הוא מאובטח בזכות מה שבניתם סביבו.
- לא תחליף ל-API
- מאחורי כל שרת יש עדיין API, הרשאות, הגבלות קצב ושגיאות. השרת הוא תרגום ותיחום, לא ביטול.
- לא תו תקן של איכות
- רישום במרשם הרשמי הוא אימות namespace, לא ביקורת אבטחה. המרשם מגדיר את עצמו כ-preview ומצהיר שהוא מאציל את סריקת האבטחה למאגרי החבילות שמתחתיו.
- לא קפוא
- גרסת 2026-07-28 מסירה את סשן ה-Mcp-Session-Id, הופכת את הליבה לחסרת מצב, ומיישנת מספר יכולות. מי שבונה היום צריך לתכנן להסבה, לא להניח יציבות.
ממשל: זו לא אופנה, וזו לא ועדה
השאלה שחוזרת בכל פגישה ראשונה היא אם MCP הוא עוד טרנד שיחלוף. התשובה היא עובדה שאפשר לבדוק, לא הבטחה. ב-09.12.2025 הפך MCP לפרויקט מייסד של Agentic AI Foundation — קרן ייעודית תחת Linux Foundation, שנוסדה במשותף בידי Anthropic, Block ו-OpenAI, עם תמיכה של Google, Microsoft, AWS, Cloudflare ו-Bloomberg.
הפרט שחשוב יותר מרשימת השמות הוא הניסוח שהקרן עצמה פרסמה: היא will not dictate the technical direction of MCP. כלומר התרומה העבירה בעלות משפטית ונייטרליות מוסדית, בלי להעביר את ההחלטות הטכניות לוועדה. זה בדיוק ההבדל בין תקן פתוח לבין פרויקט של ספק אחד שקוראים לו פתוח.
מה שכן השתנה עם הממשל הוא משמעת הגרסאות. מצבי גרסה מסומנים Draft, Current, Final ו-Deprecated. מדיניות מחזור החיים מגדירה חלון הוצאה משימוש של שנים-עשר חודשים לפחות — ובמפורש גם חריג להסרה מזורזת שמקצר אותו לתשעים יום. החריג אינו תיאורטי: תעבורת HTTP+SSE כבר סווגה Deprecated, והשעון שלה מנוסח כ"שלושה חודשים אחרי ש-SEP-2596 מגיע ל-Final" — לא שנה.
ולסיום הפרספקטיבה, מלשון הערות השחרור עצמן: SDKs will adopt this version at their own pace, and the prior version of the spec may remain in use for an undetermined amount of time. תקן שיש לו ממשל מסודר אינו תקן שקפוא, והתכנון שלכם צריך להניח את זה.
איך מבדילים שרת MCP אמיתי מעטיפה דקה
כל אחת מהבדיקות האלה אפשר להריץ לפני שחותמים על משהו, ורובן לוקחות דקות. הן ממוינות לפי מה שמסנן הכי מהר.
- 01
הריצו initialize וקראו את capabilities
אם השרת לא עונה, נגמר. אם הוא עונה — עכשיו אתם יודעים מה הוא באמת מציע, במקום מה שכתוב ב-README. שרת שמציע tools בלבד הוא לגיטימי; שרת שלא מצליח לעשות initialize הוא לא מוצר.
- 02
קראו את תיאורי הכלים, לא רק את השמות
תיאור שמכיל הוראות למודל — always call this first, ignore previous instructions — הוא לא תיעוד, הוא prompt. Trail of Bits תיארו ב-21.04.2025 בדיוק את זה: התיאורים שחוזרים מ-tools/list נכנסים להקשר של המודל בזמן החיבור, לפני שהופעל כלי ולפני שאושר משהו. שער אישור שיושב על הפעלת כלים סוגר את הדלת אחרי שהמטען כבר בפנים.
- 03
בשרת מרוחק, בדקו שהוא מחזיר 401
נקודת קצה שמחזירה 401 עם אתגר WWW-Authenticate ועם resource_metadata היא נקודת קצה חיה שאוכפת הרשאה לפני שמגיעים לכלים. נקודת קצה שמחזירה 200 בלי הזדהות היא הבעיה, לא ההוכחה.
- 04
בדקו את מודל האישורים
האם השרת מבקש credential אחד משותף, או OAuth לכל משתמש בנפרד? עטיפה דקה כמעט תמיד מבקשת מפתח אחד — וברגע שהיא רצה תחת מפתח אחד בעל הרשאות רחבות, כל מי שמדבר איתה מקבל בפועל את ההרשאות של המפתח, בלי קשר להרשאות שלו במערכת.
- 05
שאלו אם השרת מעביר את הטוקן שלכם הלאה
המפרט אוסר: The MCP server MUST NOT pass through the token it received from the MCP client. התוצאות שהמפרט עצמו מונה: עקיפה של הגבלת קצב, ולידציה וניטור; שבירה של שרשרת הביקורת; ותוקף שמחזיק טוקן גנוב יכול להשתמש בשרת כ-proxy להוצאת מידע.
- 06
בדקו מי מפרסם את החבילה
החבילה postmark-mcp פורסמה ב-npm בידי צד שלישי שהתחזה לפרויקט הלגיטימי. גרסאות 1.0.0 עד 1.0.15 היו העתק נקי של הקוד האמיתי; גרסה 1.0.16, שעלתה ב-17.09.2025, הוסיפה שורה אחת ששלחה BCC של כל מייל יוצא לכתובת של התוקף. הצמדת גרסאות עם lockfile היא לא בירוקרטיה.
- 07
אל תסמכו על readOnlyHint
וגם לא על destructiveHint. הדגלים האלה הם רמזים שהשרת מדווח על עצמו, והמפרט אומר במפורש ללקוחות להתייחס אליהם כלא אמינים. אכיפת כתיבה שייכת לרשימת היתר שאתם מתחזקים.
מכאן ממשיכים
העמוד הזה מסביר את התקן. שלושת הבאים עונים על השאלות שמגיעות אחריו: מה באמת מתחבר היום, מה נדרש כדי שזה יהיה בטוח, ומה ההבדל המעשי מול אינטגרציה רגילה.
רוצים לדעת מה מזה רלוונטי אצלכם?
סקירת מוכנות MCP היא פגישת עבודה של תשעים דקות ומסמך כתוב שנשלח אליכם תוך שלושה ימי עסקים.
נבדק לאחרונה: 29.07.2026