6.1 MCP מבוא הרצאה

בפרקים הקודמים ראינו איך Claude Code עובד עם הtools המובנים שלו - קריאת קבצים, עריכה, הרצת פקודות מעטפת, חיפוש. אבל מה קורה כשאנחנו רוצים שהagent יעבוד מול מערכת שהיא לא הקבצים במחשב שלנו? למשל, לקרוא כרטיס מ-Jira, לשלוף שורות ממסד נתונים, או לבדוק שגיאות ב-Sentry. עד לא מזמן, כל אינטגרציה כזו הייתה דורשת קוד ייעודי לכל tool ולכל מודל בנפרד. בהרצאה הזו נכיר את הפרוטוקול שפותר בדיוק את הבעיה הזו - Model Context Protocol, או בקיצור MCP. נבין מה הוא, למה הוא נוצר, איך עובד מודל הלקוח-שרת שמאחוריו, ומה הוא פותח לנו כמפתחים שעובדים בגישה של agent-first.

מהי הבעיה - problem statement

תארו לעצמכם שיש לנו M מודלים שונים של בינה מלאכותית (Claude, וגם tools אחרים), ו-N מקורות מידע וtools חיצוניים (מסד נתונים, GitHub, Slack, מערכת קבצים). אם כל שילוב דורש קוד ייעודי, אנחנו מגיעים ל-M כפול N אינטגרציות שצריך לכתוב ולתחזק. זו בעיה ריבועית, וכל tool חדש מכפיל את העבודה.

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

MCP הוא פרוטוקול פתוח (open standard), שפורסם במקור על ידי Anthropic והפך לתקן שtools רבים תומכים בו. משמעות הדבר: שרת שכתבתם פעם אחת יעבוד עם כל לקוח שתומך ב-MCP, ולא רק עם Claude Code.

מודל הלקוח-שרת - client-server model

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

Host    - the application that manages everything (e.g. Claude Code or Claude Desktop)
Client  - a component inside the Host that keeps one connection to one server
Server  - a program that provides tools and data

ה-Host הוא האפליקציה שאתם מריצים - Claude Code הוא Host. עבור כל שרת שאליו הוא מתחבר, ה-Host יוצר Client ייעודי ששומר חיבור נפרד. אם Claude Code מחובר לשלושה שרתים, יש בתוכו שלושה לקוחות, כל אחד עם החיבור שלו. זו הפרדה חשובה: כל שרת מבודד, ותקלה באחד לא מפילה את האחרים.

+-------------------- Claude Code (Host) --------------------+
|                                                            |
|   Client 1 --------- dedicated connection ------> Server: Filesystem
|   Client 2 --------- dedicated connection ------> Server: Postgres
|   Client 3 --------- dedicated connection ------> Server: GitHub
|                                                            |
+------------------------------------------------------------+

ה-שרת יכול לרוץ מקומית על המחשב שלכם (למשל שרת מערכת קבצים שנפתח כתהליך בן), או מרחוק בענן (למשל שרת של Sentry שרץ אצל Sentry). המונח "שרת" מתייחס לתוכנית שמספקת את הנתונים, בלי קשר למיקום שבו היא רצה.

שתי השכבות - the two layers

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

• שכבת הנתונים - data layer: מגדירה את הפרוטוקול עצמו, מבוסס על JSON-RPC 2.0. כאן נמצאים ניהול מחזור החיים, ה-primitives (הtools, המשאבים, הפרומפטים), וההתראות.
• שכבת התובלה - transport layer: מגדירה איך ההודעות עוברות פיזית בין הלקוח לשרת. אותה הודעת JSON-RPC יכולה לעבור בכל אמצעי תובלה.

יש שני אמצעי תובלה עיקריים:

stdio            - standard input/output between local processes on the same machine.
                   Fast, no network. Suited for local servers.
Streamable HTTP  - HTTP POST for messages, with an option for Server-Sent Events for streaming.
                   Suited for remote servers, supports OAuth authentication and Bearer tokens.

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

שלושת ה-primitives של השרת - server primitives

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

• כלים - tools: פונקציות שהמודל יכול להריץ כדי לבצע פעולה. למשל, "בצע שאילתה על מסד הנתונים", "צור issue ב-GitHub", "שלח הודעה". הtool הוא פעולה שיש לה תופעות לוואי.
• משאבים - resources: מקורות נתונים שמספקים context. למשל, תוכן של קובץ, סכימה של מסד נתונים, תיעוד. משאב הוא מידע לקריאה, לא פעולה.
• פרומפטים - prompts: תבניות שיחה מוכנות מראש שהשרת מציע. למשל, "סקירת PR" עם מבנה קבוע. אלה הופכים ל-slash commands בתוך Claude Code.

הנה טבלה שמסכמת את ההבחנה, שכדאי לזכור:

Primitive	מה זה	מי יוזם	דוגמה
כלים - tools	פעולה עם תופעות לוואי	המודל בוחר להריץ	create_issue
משאבים - resources	נתונים לקריאה	המשתמש או המודל מבקש	סכימת DB
פרומפטים - prompts	תבנית שיחה	המשתמש מפעיל כפקודה	/mcp__github__pr_review

מעבר לשלושה אלה שהשרת מציע, גם הלקוח יכול לחשוף יכולות לשרת, למשל: sampling (השרת מבקש מהלקוח להריץ completion מהמודל), ו-elicitation (השרת מבקש קלט נוסף מהמשתמש באמצע פעולה). אבל ברוב המקרים, כמשתמשים, נעבוד בעיקר עם הtools והמשאבים.

איך זה עובד בפועל - lifecycle

בואו נראה איך נראית שיחה אמיתית בין לקוח לשרת, ברמת ה-JSON-RPC. זה עוזר להבין שאין כאן קסם - זו החלפת הודעות מסודרת.

הצעד הראשון הוא אתחול - handshake שבו שני הצדדים מכריזים על היכולות שלהם:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": { "elicitation": {} },
    "clientInfo": { "name": "example-client", "version": "1.0.0" }
  }
}

השרת עונה ומכריז מה הוא תומך בו, למשל שהוא מציע tools ושהוא יודע לשלוח התראה כשרשימת הtools משתנה:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": {}
    },
    "serverInfo": { "name": "example-server", "version": "1.0.0" }
  }
}

הצעד השני הוא גילוי tools - הלקוח שואל אילו tools קיימים:

{ "jsonrpc": "2.0", "id": 2, "method": "tools/list" }

השרת מחזיר רשימה, וכל tool מגיע עם name, description, ו-inputSchema (סכימת JSON שמתארת אילו פרמטרים הtool מקבל). ה-description הוא קריטי - זה מה שהמודל קורא כדי להחליט מתי להשתמש בtool.

הצעד השלישי הוא הרצה - כשהמודל מחליט להשתמש בtool, הלקוח שולח:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": { "location": "Tel Aviv", "units": "metric" }
  }
}

והשרת מחזיר את התוצאה כתוכן שהמודל יכול לקרוא. שימו לב: הגילוי הוא דינמי. השרת יכול בכל רגע לשלוח התראה notifications/tools/list_changed, והלקוח ירענן את רשימת הtools בלי צורך להתחבר מחדש.

מה זה פותח לנו - what it unlocks

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

הנה כמה סוגי משימות שנפתחות ברגע ששרתי MCP מחוברים:

• מימוש מתוך מערכת מעקב: "ממש את הפיצ'ר שמתואר ב-issue מספר ENG-4521 ופתח PR ב-GitHub". הagent קורא את הכרטיס דרך שרת אחד ופותח PR דרך שרת אחר.
• ניתוח נתוני ניטור: "בדוק ב-Sentry מהן השגיאות הנפוצות ב-24 השעות האחרונות". הagent שולף את הנתונים החיים, לא ניחוש מהזיכרון.
• שאילתות על מסד נתונים: "מצא לקוחות שלא ביצעו רכישה ב-90 הימים האחרונים". הagent מריץ שאילתה אמיתית.

הנקודה העקרונית לקורס הזה: MCP הופך את הagent מtool שעובד רק על הקבצים שלפניו, לtool שמשולב במערכת הtools האמיתית של הצוות. זו קפיצת מדרגה בגישת הagent-first, כי היא מרחיבה את טווח המשימות שאפשר להאציל.

מדוע JSON-RPC - why a standard protocol

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

• גילוי דינמי - discovery: הלקוח לא צריך לדעת מראש אילו tools יש. הוא שואל tools/list ומקבל תשובה. שרת יכול להוסיף tools תוך כדי, והלקוח מגלה אותם. בקריאות HTTP מותאמות היינו צריכים לכתוב קוד ידני לכל שרת.
• תיאור עצמי - self-description: כל tool מגיע עם סכימה שמתארת את הפרמטרים שלו. המודל קורא את הסכימה ואת התיאור, ויודע איך לקרוא לtool נכון, בלי תיעוד חיצוני.
• הפרדת אחריות: מחבר השרת כותב את הלוגיקה פעם אחת. הוא לא צריך לדעת דבר על המודל, על הפרומפט, או על איך הלקוח בונה את השיחה. MCP מתמקד רק בהחלפת הcontext, ולא מכתיב איך האפליקציה משתמשת במודל.

השימוש ב-JSON-RPC 2.0 הוא בחירה מכוונת: זה פרוטוקול פשוט, ותיק ומוכר, של בקשות ותשובות עם מזהים, ושל התראות בלי תשובה. אין כאן המצאה חדשה - יש שימוש חכם בתקן קיים.

דוגמה קונקרטית - a concrete server

בואו נחבר את המושגים לתמונה אחת עם דוגמה. נניח שרת שנותן context על מסד נתונים. הוא יכול לחשוף בו-זמנית את שלושת ה-primitives:

tools              : run_query    - run a query
resources          : schema://main - the database schema
prompts            : analyze-table - a template for analyzing a table

עכשיו התמונה שלמה. כשאתם שואלים את הagent "כמה משתמשים נרשמו החודש?", הנה מה שקורה מאחורי הקלעים: הagent אולי קורא קודם את המשאב schema://main כדי להבין את מבנה הטבלאות, מרכיב שאילתה מתאימה, קורא לtool run_query עם השאילתה, ומקבל תוצאה. כל זה דרך פרוטוקול אחיד, בלי שורת קוד אינטגרציה שכתבתם. זה הכוח של MCP: שרת אחד שנכתב פעם, ומודל שיודע להשתמש בו אוטומטית.

אזהרה חשובה - trust and security

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

לכן הכלל: התחברו רק לשרתים שאתם סומכים עליהם. שרת שמביא תוכן מהאינטרנט מסוכן יותר משרת שקורא קובץ מקומי. בהמשך הפרק נראה גם שכבות הגנה נוספות - הרשאות, hooks, ובידוד בsub-agents - אבל שיקול הדעת שלכם לגבי מקור השרת הוא קו ההגנה הראשון.

סיכום

בהרצאה הזו למדנו:

• MCP - Model Context Protocol הוא פרוטוקול פתוח שנותן דרך אחידה לחבר מודל בינה מלאכותית לtools ולנתונים חיצוניים, ופותר את בעיית ה-M כפול N של אינטגרציות. האנלוגיה: USB-C לעולם ה-AI.
• הארכיטקטורה היא לקוח-שרת עם שלושה שחקנים: Host (האפליקציה, למשל Claude Code), Client (חיבור אחד לכל שרת), ו-Server (שמספק tools ונתונים).
• הפרוטוקול בנוי משתי שכבות: שכבת נתונים מבוססת JSON-RPC 2.0, ושכבת תובלה עם שני אמצעים - stdio לשרתים מקומיים, ו-Streamable HTTP לשרתים מרוחקים.
• שרת חושף שלושה primitives: כלים (tools) לפעולות, משאבים (resources) לנתונים, ופרומפטים (prompts) לתבניות שיחה.
• מחזור החיים הוא: אתחול והכרזת יכולות, גילוי tools דינמי (tools/list), והרצה (tools/call). הגילוי דינמי, כך שהשרת יכול לעדכן את הtools תוך כדי.
• MCP פותח לagent טווח משימות רחב: קריאה ופעולה ישירה מול Jira, GitHub, מסדי נתונים ומערכות ניטור, במקום העתקה ידנית.
• שיקול ביטחון: התחברו רק לשרתים מהימנים, כי תוכן חיצוני עלול להכיל הזרקת פרומפט.