MCP מוסבר: כך פועל Model Context Protocol

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

ועדיין, יש בלבול לגבי מה MCP בעצם הוא.

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

נפרק את זה.

אם אתם רק רוצים לראות מה MCP מאפשר בפועל, צפו בסרטון הקצר הזה:

מהו פרוטוקול?

פרוטוקול הוא פשוט אוסף כללים שמגדיר כיצד שתי מערכות או יותר מתקשרות זו עם זו.

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

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

או חשבו עליו כמו USB-C לכלי AI. לפני עשרים שנה, השוק היה מוצף בסוגים שונים של כבלי טעינה ונתונים. בדומה לכך, לאקוסיסטמות AI היו כמה דרכים להעביר כלים למודלי שפה. פריימוורקים כמו LangChain, Haystack ו-Pydantic AI הגדירו כולם פורמטים משלהם לשילוב כלים, כלומר אם מפתח רצה לכתוב סט כלים עבור Google Maps, הוא היה צריך לעשות זאת עבור כל טכנולוגיה ספציפית.

כדי להפוך זאת למוחשי יותר, נבחן את הפרוטוקול הפופולרי ביותר, HTTP (Hypertext Transfer Protocol), שמפעיל אתרי אינטרנט. HTTP מגדיר, בין היתר, כיצד דפדפן (לקוח) מבקש דף אינטרנט משרת Web וכיצד השרת אמור להגיב.

הנה דוגמה למחזור בקשה-תגובה ב-HTTP:

1. הדפדפן מבצע בקשת HTTP

כאשר אתם מקלידים https://example.com בדפדפן, הדפדפן שולח בקשת HTTP מובנית לשרת ה-Web:

אלה הפרמטרים והערכים של HTTP המשמשים בדוגמה שלנו:

"GET" – זוהי הפעולה (בקשת דף אינטרנט).
"/index.html" – דף האינטרנט הספציפי המבוקש.
"HTTP/1.1" – גרסת הפרוטוקול שבה משתמשים.
"Host: example.com" – שם הדומיין של האתר.
"User-Agent: Mozilla/5.0" – מידע על הדפדפן שמבצע את הבקשה.

שרת ה-Web יודע כיצד לפרש את הבקשה הזו כי HTTP מסטנדרט את הפורמט הזה. הוא מבין את ה”שפה” הזו.

2. השרת מגיב באמצעות פרוטוקול HTTP

השרת מעבד את הבקשה ושולח בחזרה תגובת HTTP מובנית:

"HTTP/1.1 200 OK" – קוד התגובה (200 פירושו הצלחה).
"Content-Type: text/html" – סוג התוכן שנשלח בחזרה.
"Content-Length: 512" – גודל התגובה.
HTML Content – תוכן דף האינטרנט בפועל (יש בו רק כותרת "Welcome to Example.com")

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

איך MCP פועל כפרוטוקול

כעת נחיל את אותה חשיבה על MCP (Model Context Protocol).

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

מהם אותם “כלים”, אתם עשויים לשאול?

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

נניח שאתם שואלים סוכן AI:

“מה השעה בלונדון עכשיו?”

מכיוון שה-AI עצמו אינו יודע את התשובה הנכונה, שכן למודלי AI יש תאריך חתך ידע (אוקטובר 2023 עבור המודלים של OpenAI), הוא צריך להביא נתונים חיים משירות זמן. אבל במקום להשתמש ב-HTTP כדי לבקש דף אינטרנט, ה-AI משתמש ב-MCP כדי לבקש נתוני זמן.

כך זה קורה:

1. סוכן ה-AI מבצע בקשת MCP לשירות הזמן (דוגמה)

"method": "tools.call" → ה-AI קורא לכלי חיצוני.
"tool": "get_time" → שם הכלי שבו הוא רוצה להשתמש.
"args": { "location": "London" } → פרמטרי הקלט הספציפיים.

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

2. שרת הזמן של MCP מגיב

הכלי החיצוני (שרת הזמן) פועל לפי כללי התגובה של MCP ושולח בחזרה:

"status": "success" → מאשר שהבקשה עובדה כראוי.
"result" → מכיל את נתוני הזמן בפועל.

כעת, סוכן ה-AI יכול לקחת את הנתונים האלה ולנסח תגובה ממשית למשתמש:

“השעה הנוכחית בלונדון היא 12:20 PM (GMT).”

לסיכום ולהסרת הבלבול:

“MCP הוא אפליקציה.” → לא, MCP הוא אוסף כללים. כדי להשתמש בו בפועל צריך תוכנת AI וכלים שמיישמים MCP, בדיוק כפי שאפליקציית Instagram צריכה שרתי Instagram חיים כדי להגיב לבקשות HTTP ולספק נתונים.

“MCP הוא מסד נתונים.” → לא, MCP לא מאחסן נתונים. הוא עוזר לסוכני AI לדבר עם מסדי נתונים או APIs.

“MCP הוא כמו API.” → לא בדיוק. API הוא דרך ספציפית לתקשר עם מערכת אחת, בעוד שפרוטוקול (כמו MCP או HTTP) מגדיר דרך אוניברסלית שבה מערכות רבות ושונות יכולות לתקשר. MCP הוא שפה שמערכת AI יכולה להשתמש בה כדי לתקשר עם APIs ממשיים רבים (זמן, מסדי נתונים, Stripe, Slack וכו’).

למה MCP מעניין

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

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

השימוש בספריות האלה מאיץ את הפיתוח, אבל שילובן כראוי במערכת שלכם (אם היא אינה תואמת ליישום שמצאתם ב-GitHub) עדיין דורש מאמץ כדי לגרום לכלי לעבוד עם ה-AI.

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

נשווה בין שתי הגישות כדי לראות את ההבדלים בצורה ברורה יותר.

אינטגרציה רגילה לעומת שימוש ב-Model Context Protocol (MCP)

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

אינטגרציה רגילה

1. מציאת ספרייה והתאמתה: אתם מחפשים לקוח Google Drive API או פרויקט קוד פתוח. Google מספקת ספריות לקוח (למשל Google Drive API for Python), ואתם כוללים אותן בפרויקט. עדיין צריך לוודא שהן פועלות בסביבת ה-AI שלכם.

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

3. טיפול בשגיאות ובמקרי קצה: מוסיפים קוד לטיפול במקרים כמו “הקובץ לא נמצא”, שגיאות הרשאה או מגבלות קצב של API. אם ה-API של Google מחזיר שגיאה, אתם תופסים אותה ואולי מגיבים בהודעת התנצלות או מבקשים מה-AI לנסח מחדש. צריך גם להגן מפני מצב שבו ה-AI שולח יותר מדי בקשות מהר מדי.

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

התהליך הזה חל גם על כלים אחרים: רוצים להוסיף Slack או מסד נתונים ל-AI שלכם? צריך לחזור על כל התהליך עבור כל אחד מהם.

אינטגרציית MCP

כעת נראה איך התהליך הזה היה נראה כשמשתמשים ב-MCP.

ראשית, נגדיר מושגי מפתח:

Client – אפליקציית AI (ChatGPT, אפליקציית Claude, Quickchat AI) שיוצרת חיבור לשרת אחד או יותר ומבקשת מידע או פעולות לביצוע משימות שמשתמש ביקש.

Server – כל שרת עשוי להתחבר למשהו כמו מסד נתונים או API (Google Drive) ולהגדיר אוסף “כלים” או נתונים שהוא יכול לספק. במקרה הזה, שרת הוא תוכנית שחושפת את הכלים והיכולות האלה ל-Client (אפליקציית AI).

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

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

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

  לאחר שהשרת פועל, הוא ממתין לבקשות.

• חיבור LLM (לקוח) לשרת MCP. בשלב הבא, אפליקציית ה-AI (צד ה”לקוח”) צריכה להתחבר לשרת הזה. בפועל, אם אתם משתמשים בפלטפורמת AI שתומכת ב-MCP (כגון Claude Desktop), תגדירו אותה עם הכתובת או הפקודה להפעלת השרת. לאחר החיבור, הלקוח יוצר סשן עם השרת לפי לחיצת היד של MCP. אם אתם משתמשים בממשק של Claude, תראו ש-Claude “מחובר” לשרתי MCP מסוימים (ה-UI עשוי להציג מחברים זמינים).

כך זה נראה ב-UI של Claude

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

  לדוגמה, שרת עשוי להשיב שיש לו כלים זמינים מסוג create_file(path, content), read_file(path) ו-search_files(query). לאחר מכן הלקוח מעמיד את המידע הזה לרשות ה-LLM. במימושים רבים, הלקוח יעצב את תיאורי הכלים האלה ויכלול אותם בקונטקסט של המודל (למשל, יוסיף ל-system prompt: “יש לך גישה לכלים הבאים… [רשימת כלים]”).

הנה system prompt של AI יחד עם הודעת המשתמש שמבקשת את השעה הנוכחית

כאשר כלי MCP ממומשים, כלי בשם “get_current_time” משולב ומאפשר ל-AI לגשת למשאב חיצוני ולהביא את השעה המדויקת בלונדון

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

• שימוש בכלי דרך MCP. כאשר ה-AI צריך לבצע פעולה או להביא נתונים, הוא יפעיל כלי דרך MCP. מנקודת המבט של ה-AI (במיוחד עבור מודלים כמו Claude שתומכים באופן מובנה בשימוש בכלים), הוא יחליט בתהליך ההסקה שלו: “אני צריך לקרוא לכלי X עם הפרמטרים האלה.” לקוח ה-MCP לוכד את הכוונה הזו ושולח בקשת tools/call בפורמט MCP לשרת המתאים (שרת MCP של Google Drive).

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

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

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

  במקום פשוט להיכשל, סוכן ה-AI יכול לקחת את התגובה המובנית הזו ולנסח אותה מחדש כמשוב ידידותי למשתמש:

  “נראה שמזהה הקובץ שסיפקת קצר מדי. מזהי קבצים של Google Drive הם בדרך כלל באורך 28 תווים. האם אפשר לבדוק שוב ולנסות מחדש?”

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

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

  אם המשתמש מבקש יצירה של קובץ Google Sheets חדש, תשובת השרת (שמכילה את מזהה הקובץ וקישור שנוצר) תוזן למודל. לאחר מכן המודל יענה למשתמש: “חדשות טובות! קובץ Google Sheets החדש שלך מוכן. אפשר לגשת אליו כאן: [link].”

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

יתרונות השימוש ב-MCP

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

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

הנה סיכום של היתרונות המרכזיים:

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

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

• אינטגרציית Plug-and-play עם מודלי LLM שונים. MCP אינו תלוי במודל. לפרוטוקול לא אכפת אם הלקוח הוא Claude, GPT-4, DeepSeek או כל מודל עתידי, כל עוד הלקוח יכול לטפל בממשק MCP. בעתיד, אם תרצו לעבור למודל אחר, תוכלו לעשות זאת בלי לשכתב את כל האינטגרציות שלכם.

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

האם אינטגרציות API יתיישנו?

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

אם צריך להשתלב רק עם שירות חיצוני אחד או שניים והאינטראקציות פשוטות יחסית, אינטגרציית API ישירה היא לעיתים קרובות הפתרון המהיר ביותר. אם אפליקציית ה-Web שלכם רק צריכה לאמת טוקן תשלום של Stripe בתהליך התשלום, קריאה ישירה ל-API של Stripe היא פשוטה ויעילה. הכנסת MCP בתרחיש הזה עשויה להיות מוגזמת. אפשר לחבר סוכן AI לכל REST API מתועד באמצעות HTTP Action אחד שנבדק, או להשתמש באינטגרציה בלחיצה אחת כמו Google Sheets לרישום לידים ובקשות דמו, בלי להריץ שרת MCP.

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

לדוגמה מוחשית של האופן שבו כלי MCP נחשפים לסוכן AI בפרודקשן לצד פעולות API מותאמות אישית, ראו כיצד Quickchat AI Agents משלבים את שתי הגישות. הדיון המעמיק יותר לגבי מתי להשתמש ב-MCP, ב-AI Actions בודדות או ב-”Generate from Text” מופיע ב-APIs for AI Agents: From MCP to Custom Endpoints. כדי לנסות זאת בעצמכם, עקבו אחר המדריך צעד אחר צעד לחיבור סוכן ה-AI שלכם לשרת MCP מרוחק, כך שהוא יקרא לכלי חי באמצע שיחה.

רשימת שרתי MCP זמינים

אם אתם רוצים להתחיל לעבוד עם MCP, בדקו את ספריות שרתי MCP שלהלן:

• https://github.com/modelcontextprotocol/servers
• https://smithery.ai

אפשר גם להריץ אחד בלי לכתוב קוד: כל Quickchat AI Agent יכול להפוך לשרת MCP עם URL מתארח ש-Claude, ChatGPT ו-Cursor קוראים לו ככלי. החיבור עובד גם בכיוון השני: Quickchat AI Agent יכול לקרוא לשרת MCP מתארח של ספק ככלים שלו, וכך עוזר תזמון AI שנבנה על שרת MCP של Calendly בודק זמינות אמיתית וקובע פגישות מתוך צ’אט, וכך צ’אטבוט AI של Notion עונה ממרכז עזרה חי ומתעד בקשות תמיכה בחזרה במסד נתונים של Notion.

Quickchat AI גם מפעילה שרת MCP מרוחק עבור החשבון שלכם. חברו אותו ל-ChatGPT, Claude, Cursor או Codex, ותוכלו לנהל משם את סוכני ה-AI שלכם: אנליטיקה, תמלילי שיחות, עדכוני knowledge base ויצירת Agent חדש, מאחורי כניסת OAuth יחידה. מדריך ההגדרה לכל לקוח מופיע ב-Manage Your AI Agent from ChatGPT, Claude, and Codex with MCP.

שאלות נפוצות

האם זה עובד רק עם Claude?

MCP אינו תלוי במודל. לפרוטוקול לא אכפת אם הלקוח הוא Claude, GPT-4, נגזרת מקומית של LLaMA או כל מודל עתידי, כל עוד הלקוח יכול לטפל בממשק MCP. המשמעות היא שאינכם נעולים לספק AI יחיד כשאתם בונים את אינטגרציות הכלים שלכם.

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

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

מה אם נחבר עשרות כלים ל-AI? זה לא יעמיס על המודל או יגרום לו להשתמש בהם באופן שגוי?

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

MCP לעומת Function Calling

Function calling מסורתי (כפי שמופיע ב-API של OpenAI או ב-LLMs אחרים) מאפשר למפתח להגדיר אוסף פונקציות, לתת למודל את ההגדרות שלהן ולגרום למודל “לקרוא” להן לפי שם עם ארגומנטים. זה היה צעד גדול באינטגרציית AI, אבל יש לו מגבלות. הבדל מרכזי אחד הוא מתי וכיצד מוגדרים כלים. ב-function calling קלאסי, כל הפונקציות האפשריות חייבות להיות מוצהרות מראש (בזמן התכנון) בפרומפט או דרך ה-API. המודל יכול לקרוא רק לפונקציות הקבועות האלה. ב-MCP, כלים ניתנים לגילוי בזמן ריצה, ה-AI יכול לשאול מה זמין ואפילו לקבל כלים חדשים באמצע סשן.

MCP לעומת GPT Actions & Plugins

GPT Actions/Plugins מתייחסים לאקוסיסטם של OpenAI, שבו ניתן היה להפעיל פלאגינים (כמו דפדפן Web או קורא PDF) עבור ChatGPT, או את “GPTs” (סוכני ChatGPT מותאמים אישית) שיכולים להשתמש בכלים. אלה היו מעניינים, אבל הם דרשו פיתוח מותאם אישית לכל פלאגין והיו מוגבלים לפלטפורמות של OpenAI. אם רציתם פלאגין ChatGPT למשימה, הייתם צריכים ליצור API ומניפסט ולעבור את האישור של OpenAI או לפחות להפעיל אותו ידנית. כל פלאגין היה למעשה סילו, פלאגין מזג אוויר, פלאגין נסיעות וכו’, כל אחד עם נקודות קצה ולוגיקה משלו. MCP משפר את הרעיון הזה באמצעות איחוד ופתיחה שלו.

MCP לעומת RAG (Retrieval-Augmented Generation)

Retrieval-Augmented Generation (RAG) היא טכניקה שבה LLM מתוגבר באמצעות knowledge base חיצוני. בדרך כלל, RAG כולל מסד נתונים וקטורי או אינדקס חיפוש: שאילתת המשתמש משמשת להבאת מסמכים או נתונים רלוונטיים (באמצעות חיפוש סמנטי או שיטות אחרות), והמסמכים האלה מסופקים למודל כקונטקסט נוסף ל”קריאה” בעת ניסוח תשובה. RAG עוסק במתן ידע למודל שלא היה לו במקור, והוא שימושי במיוחד לשאלות ותשובות עובדתיות או למידע ספציפי לתחום. עם זאת, RAG הוא לקריאה בלבד, המודל מאחזר קטעי טקסט, אבל לא מבצע פעולות מעבר לאחזור.

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