מה זה MCP? הסבר על Model Context Protocol

#מה זה MCP

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

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

הפרוטוקול מוגדר ב-revision 2026-07-28, הגרסה שדף המפרט הצביע עליה כשהמאמר הזה נכתב. המפרט הוא הסמכות לשמות שדות ולכללים. המאמר מסביר את המודל שמאחוריו, כדי שאפשר יהיה לקרוא את המפרט ואת קוד השרת עם תמונה ברורה.

#למה זה חשוב

יש שלוש סיבות ללמוד MCP.

הראשון הוא שימוש חוזר. אפשר להתקין שרת filesystem, שרת GitHub או שרת מסד נתונים בכל host תואם. לא צריך לכתוב שוב את אותו קוד חיבור לכל אפליקציה.

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

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

#התפקידים: host, ‏client ו-server

בארכיטקטורה יש שלושה משתתפים. המפרט וסקירת הארכיטקטורה משתמשים באותם שמות.

ה-host הוא אפליקציית ה-AI שהמשתמש עובד בה. Claude Desktop, ‏Claude Code ו-IDE עם עוזר הם כולם hosts. ה-host מחליט לאילו שרתים להתחבר ובאילו כלים המודל רשאי להשתמש.

ה-client הוא רכיב בתוך ה-host. ה-host יוצר client אחד לכל שרת, וכל client מחזיק חיבור ייעודי לשרת אחד בדיוק. אם host מתחבר לשלושה שרתים, הוא מריץ שלושה clients.

ה-server הוא תוכנה שחושפת יכולות. הוא יכול לרוץ על המחשב הנייד שלך כתהליך בן, או על מחשב מרוחק מאחורי URL. שרתים מקומיים משרתים בדרך כלל client אחד. שרתים מרוחקים משרתים לעיתים קרובות הרבה clients.

תמונה פשוטה:

Host (your AI app)
 ├── Client A ── stdio ──> filesystem server (local process)
 ├── Client B ── stdio ──> database server (local process)
 └── Client C ── HTTPS ──> ticket system server (remote)

כל חץ נושא הודעות JSON-RPC 2.0. לפרוטוקול יש שתי שכבות. שכבת הנתונים מגדירה את ההודעות ואת המשמעות שלהן. שכבת התעבורה מגדירה איך ההודעות נעות.

#הפרימיטיבים

הפרימיטיבים קובעים מה שרת יכול להציע. המפרט נוקב בשלוש יכולות שרת.

Tools הם פונקציות שהמודל יכול לקרוא להן. לכלי יש שם, תיאור, סכמת קלט שכתובה ב-JSON Schema ו-handler בצד השרת. להצגת הכלים קוראים למתודה tools/list. להרצת כלי קוראים למתודה tools/call. בכלים מתרחשות הפעולות: כתיבת קובץ, שליחת בקשה, הרצת שאילתה.

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

Prompts הם תבניות הודעה לשימוש חוזר שהשרת מפרסם, לעיתים קרובות עם ארגומנטים. משתמש בוחר prompt כמו שבוחרים פקודה, וה-host ממלא אותו ושולח למודל.

ל-clients יש יכולות משלהם. Elicitation מאפשר לשרת לבקש מהמשתמש קלט נוסף במהלך פעולה, כמו אישור או ערך חסר. שתי יכולות client ישנות, sampling ו-logging, הוצאו משימוש ב-revision 2026-07-28. Sampling אפשר לשרת לבקש completion מהמודל של ה-host. סקירת הארכיטקטורה אומרת שמימושים חדשים צריכים להתחבר ישירות ל-APIs של ספקי מודלים, ולרשום לוג ל-stderr ב-stdio או להשתמש ב-OpenTelemetry.

כל פרימיטיב הולך לפי דפוס: מתודת */list לגילוי, מתודת */get או */read לאחזור, ומתודת קריאה כשהפרימיטיב הוא פעולה. רשימות יכולות להשתנות בזמן ריצה. client שפותח subscription יכול לקבל התראות על שינויים, כך שהוא מתרענן בלי polling.

#תעבורות

תעבורה היא הדרך שבה הודעות עוברות. סקירת הארכיטקטורה נוקבת בשתיים.

stdio מפעיל את השרת כתהליך בן. ה-host כותב הודעות JSON-RPC לקלט הסטנדרטי של השרת וקורא תגובות מהפלט הסטנדרטי שלו. אין פורט רשת. זו התעבורה הרגילה לשרתים מקומיים, וזו שמשמשת במעבדה. הכלל החשוב ביותר: ב-stdio, הפלט הסטנדרטי שייך לפרוטוקול. print תועה ל-stdout משחית את הזרם. הודעות אבחון הולכות ל-stderr.

Streamable HTTP מריץ את השרת מאחורי endpoint של HTTP. ה-client שולח הודעות ב-HTTP POST, והשרת יכול להזרים בחזרה תגובות או התראות עם Server-Sent Events. זו התעבורה לשרתים מרוחקים. מכיוון שהיא חשופה לרשת, היא מביאה את בעיות ה-HTTP הרגילות: אימות, TLS, בדיקות origin ומגבלות קצב. סקירת הארכיטקטורה ממליצה על OAuth לקבלת טוקנים.

שכבת הנתונים נשארת זהה בשתיהן. קריאה לכלי נראית אותו דבר בין אם עברה ב-pipe ובין אם ב-socket.

#איך סשן רץ, שלב אחר שלב

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

1. ה-host מפעיל את תהליך השרת עם הפקודה שהוגדרה לו. בשרת stdio זו שורת הפקודה בקונפיגורציה של ה-host.
2. ה-client יכול לשלוח בקשת גילוי, server/discover, שכל שרת חייב לממש. הקריאה לא חובה, כי כל בקשה נושאת את מה שהשרת צריך. השרת עונה עם גרסאות הפרוטוקול שהוא תומך בהן, היכולות שלו והזהות שלו. ב-revision 2026-07-28, כל בקשה נושאת את גרסת הפרוטוקול ואת יכולות ה-client בשדה _meta. הפרוטוקול חסר מצב: כל בקשה נושאת את מה שהשרת צריך כדי לעבד אותה, כך שהשרת לא מסתמך על מה שקרה קודם בחיבור.
3. ה-client קורא למתודות tools/list, ‏resources/list וגם prompts/list עבור היכולות שהשרת הצהיר עליהן.
4. ה-host נותן למודל את הגדרות הכלים. המודל מחליט מתי לקרוא לאחד מהם ועם אילו ארגומנטים.
5. ה-host שולח tools/call. השרת מריץ את ה-handler שלו ומחזיר תוצאה עם מערך content, שיכול להכיל טקסט, תמונות או משאבים מוטמעים. קריאה שנכשלה מחזירה תוצאת שגיאה שהמודל יכול לקרוא.
6. אם רשימת הכלים של השרת משתנה, client שנרשם עם subscriptions/listen מקבל הודעת notifications/tools/list_changed, ויכול לבקש שוב את הרשימה.

ה-host יושב בין שלבים 4 ו-5. הוא הרכיב שמבקש ממך אישור, אם הוא מבקש בכלל. הנקודה הזאת חוזרת בסעיף האבטחה.

#מודל האבטחה

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

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

בפועל זה אומר ארבעה הרגלים.

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

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

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

מעקב אחרי מה שחוזר. תוצאות כלים ותוכן משאבים הם נתונים. הם יכולים להכיל טקסט שנראה כמו הנחיות למודל, שהועתק מדף web או מקובץ. ה-host לא אמור להתייחס לטקסט הזה כהוראה, וגם לא מי שקורא אותו. זה השורש של prompt injection דרך כלים, שיש לו מאמר משלו.

#תרגיל מעשי: שרת ה-filesystem בארגז חול

המעבדה הזאת משתמשת בשרת הייחוס הרשמי של filesystem מהמאגר modelcontextprotocol/servers, וב-MCP Inspector הרשמי. לא צריך מודל, מפתח API או חשבון בתשלום. צריך Node.js. ה-Inspector דורש Node 22.19.0 ומעלה, ולכן משתמשים בגרסת LTS עדכנית. יוצרים תיקייה, מפעילים את השרת עם התיקייה הזאת כתיקייה המורשית היחידה שלו, ובודקים מה השרת מאפשר לעשות.

מריצים את הפקודות האלה בטרמינל שבו רוצים את המעבדה. ב-Git Bash, ב-Linux או ב-macOS:

mkdir mcp-sandbox && echo 'hello from the sandbox' > mcp-sandbox/note.txt

ב-PowerShell מקבלים את אותה תוצאה כך:

New-Item -ItemType Directory mcp-sandbox | Out-Null
Set-Content -Path mcp-sandbox\note.txt -Value 'hello from the sandbox'

מפעילים את ה-Inspector עם השרת כיעד:

npx @modelcontextprotocol/inspector npx -y @modelcontextprotocol/server-filesystem ./mcp-sandbox

ה-Inspector מדפיס URL מקומי שנושא טוקן להפעלה הזאת, ופותח את ה-URL בדפדפן. משאירים את הטרמינל פתוח, כי השרת רץ כתהליך בן של ה-Inspector כל עוד משתמשים בו. ההפעלה הראשונה יכולה לקחת זמן כי npx מוריד את החבילות. אם החיבור נכשל בזמן שחבילות עדיין יורדות, מחכים דקה ומנסים שוב. במצב CLI, ‏--connect-timeout מעלה את המגבלה, והפקודות בהמשך משתמשות בו.

#התחברות והצגת כלים

בדף ה-web לוחצים על Connect. אחר כך פותחים את הלשונית שמציגה את הכלים של השרת ומריצים את פעולת ההצגה. תוויות משתנות בין גרסאות, ולכן מחפשים את הלשונית והכפתור שמציגים כלים. אמורים להופיע כלי ה-filesystem. בגרסה שבדקתי, שרת הייחוס חשף שישה־עשר כלים, כולל list_directory, read_text_file, write_file וגם list_allowed_directories. read_file עדיין שם ומסומן כהוצא משימוש לטובת read_text_file.

מריצים קודם את list_allowed_directories. הוא אומר מה השרת יקבל. התוצאה מציגה נתיב אחד, המיקום המוחלט של mcp-sandbox. שום דבר אחר לא נגיש.

#קריאה ל-list_directory ול-read_text_file

בוחרים את list_directory ומעבירים . כנתיב, כלומר התיקייה המורשית עצמה. התוצאה אמורה להציג רשומה אחת: [FILE] note.txt.

בוחרים את read_text_file ומעבירים note.txt כנתיב. התוצאה אמורה להכיל את הטקסט שנכתב, hello from the sandbox.

כדאי לשים לב לנתיב. הוא note.txt ולא ./mcp-sandbox/note.txt. השרת מפרש נתיבים יחסיים ביחס לתיקייה המורשית שלו, ולא ביחס לתיקייה שממנה הופעל ה-Inspector. טעיתי בזה בניסיון הראשון. השרת החזיר שגיאת "no such file" עבור הנתיב הסופי mcp-sandbox\mcp-sandbox\note.txt. הודעת השגיאה הראתה באיזה נתיב השרת עבד בפועל, ולכן כדאי לקרוא טקסט שגיאה בתשומת לב.

#ניסיון של נתיב מחוץ לארגז החול

יוצרים קובץ בתיקיית האב, רמה אחת מעל mcp-sandbox:

echo 'this file is outside the sandbox' > outside.txt

חוזרים ל-Inspector וקוראים לכלי read_text_file עם הנתיב ../outside.txt. צפויה תוצאת שגיאה, ולא תוכן הקובץ. אצלי השרת החזיר את הטקסט הזה, עם נתיב מקוצר:

Access denied - path outside allowed directories: ...\mcplab\outside.txt not in ...\mcplab\mcp-sandbox

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

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

#מה ראיתי

הרצתי את אותן קריאות במצב CLI של ה-Inspector, ששולח את אותן הודעות JSON-RPC כמו לקוח ה-web:

npx @modelcontextprotocol/inspector --cli --connect-timeout 120000 npx -y @modelcontextprotocol/server-filesystem ./mcp-sandbox --method tools/call --tool-name read_text_file --tool-arg path=note.txt

התשובה חזרה כ-JSON, ותוכן הטקסט היה hello from the sandbox ואחריו תו שורה חדשה. אותה פקודה עם --tool-name list_allowed_directories הציגה את הנתיב המורשה היחיד. הקריאה עם ../outside.txt החזירה את הסירוב שמופיע למעלה. גרסאות החבילות ביום ההרצה היו @modelcontextprotocol/inspector 2.14.0 וגם @modelcontextprotocol/server-filesystem 2.2.0. השרת הדפיס Secure MCP Filesystem Server running on stdio ל-stderr, וזה כלל ה-stdio בפעולה. ה-stdout שלו נשאר שמור להודעות הפרוטוקול.

הרצתי את זה ב-Windows 11 עם Git Bash ו-Node 24, ולא השתמשתי בדף ה-web בהרצות האלה. הגרסאות והנתיבים אצלך יהיו שונים, ורשימת הכלים יכולה להשתנות בין גרסאות.

#טעויות נפוצות

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

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

מתן גישת כתיבה כברירת מחדל. מתחילים בקריאה בלבד. מוסיפים סקופי כתיבה רק כשמשימה צריכה אותם.

הדפסה ל-stdout בשרת stdio. לוגים והדפסות דיבוג שנכתבים ל-stdout שוברים את הפרוטוקול. משתמשים ב-stderr.

אמון ב-annotations של כלים. כלי שמסומן לקריאה בלבד עדיין מריץ כל קוד שהשרת מכיל.

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

ציפייה שה-Inspector יבצע ביקורת. ה-Inspector מציג מה השרת מחזיר ל-client. זו תצוגת דיבוג, ולא סקירת אבטחה.

#איך ממשיכים

קוראים קודם את סקירת הארכיטקטורה, ואז את דפי מושגי השרת ומושגי ה-client. הם מסבירים את הפרימיטיבים עם עוד דוגמאות. אחר כך קוראים את סעיפי הפרוטוקול הבסיסי והאבטחה במפרט, כי הם קובעים את הכללים שכל שרת ו-host חייבים לעמוד בהם.

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

תיקיית המעבדה נשארת קטנה וחד־פעמית, ובסיום מוחקים אותה. המאמר הבא במסלול, מה זה prompt injection באפליקציות LLM, עוסק בתקיפה שתוצאות כלים מאפשרות. לרקע שהמאמר הזה מניח, מתחילים ב-מה הם סוכני AI ושימוש בכלים.

#מקורות

• Model Context Protocol, specification (revision 2026-07-28): https://modelcontextprotocol.io/specification
• Model Context Protocol, architecture overview: https://modelcontextprotocol.io/docs/learn/architecture
• Model Context Protocol, reference servers repository: https://github.com/modelcontextprotocol/servers
• MCP Inspector documentation: https://modelcontextprotocol.io/docs/tools/inspector