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

מאת חן רז · פורסם: 26 ביולי 2026

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

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

מה זה MCP בשתי פסקאות?

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

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

מה משתנה כשקלוד יכול לפעול במערכות שלכם?

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

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

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

איך זה נראה בפועל מול CRM או בסיס נתונים?

נניח שאתם רוצים שהסוכן יענה על שאלות מתוך מערכת ניהול הלקוחות ויפתח משימות מעקב. ההחלטה הראשונה היא לא "איך מתחברים ל-CRM" אלא אילו פעולות בכלל קיימות.

סט סביר להתחלה נראה בערך כך:

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

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

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

איך מגבילים את ההרשאות של הסוכן?

הרשאות נבנות בשכבות, ולא באחת מהן לבד:

1. זהות נפרדת. לסוכן יש משתמש או מפתח משלו, לא הטוקן האישי של מנהל המערכת. כך אפשר לבטל לו גישה בלי להשבית אף אדם, ולראות בדיוק מה נעשה בשמו.
2. הרשאת מינימום במערכת המקור. המגבלה האמיתית נאכפת בצד ה-CRM או בסיס הנתונים, לא בקוד השרת. משתמש קריאה בלבד הוא משתמש קריאה בלבד גם אם מישהו יטעה בהגדרת הכלי.
3. הפרדה בין כלי קריאה לכלי כתיבה. קריאה זמינה תמיד, כתיבה מוגדרת בנפרד ומופעלת ביודעין.
4. צמצום לפי נתונים, לא רק לפי פעולה. רק הרשומות של אותו לקוח, רק החודשים האחרונים, ורק השדות הדרושים למשימה. הסינון הזה קורה בשרת, כך שמידע שלא צריך להגיע למודל פשוט לא נשלף.
5. טוקנים קצרי תוקף שמתחלפים. אף פעם לא בתוך המאגר של הקוד, תמיד במנגנון ניהול סודות עם החלפה תקופתית.

נקודה שחשוב לי להדגיש: התוכנה שמריצה את הסוכן מציעה לרוב שכבת אישורים משלה. ב-Claude Code, למשל, אפשר לאשר או לחסום קריאות לכלים ולהגדיר רשימות היתר, וזה מה שתמצאו באנגלית תחת claude code mcp. השכבה הזו נוחה ומועילה, אבל היא נוחות ולא אבטחה. היא חיה בצד הלקוח ואפשר לשנות אותה. הגבול האמיתי הוא זה שנאכף בשרת ובמערכת המקור.

מה קורה כשהסוכן טועה?

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

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

איך יודעים בדיעבד מי עשה מה?

תיעוד הוא לא תוספת נחמדה בסוף הפרויקט, הוא תנאי סף להתחלה שלו. שלוש נקודות מעשיות:

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

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

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

איפה שרת ה-MCP חי ואיך הוא מזדהה?

יש שתי צורות פריסה שונות מאוד, והבלבול ביניהן הוא מקור לא מבוטל לתסכול:

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

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

בצד הלקוח, חיבור השרת אל Claude Code נעשה דרך פקודות ה-MCP שלו. אם אתם רוצים לארוז את אותה יכולת לתוך מוצר או שירות משלכם ולא רק לעבוד מולה בטרמינל, זה כבר עולם ה-claude agent sdk. ונהלים חוזרים שאתם רוצים שהסוכן יבצע באותה צורה בכל פעם נארזים כ-claude code skills, שזה כלי טוב לעקביות אבל לא תחליף להרשאות.

מתי מחבר מוכן מספיק, ומתי צריך שרת משלכם?

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

שרת משלכם נדרש בעיקר במקרים האלה:

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

מתי בכלל שווה לחבר סוכן, ומתי אוטומציה רגילה עדיפה?

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

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

שאלות ותשובות

האם קלוד "רואה" את כל בסיס הנתונים כשמחברים MCP?

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

אפשר לתת לסוכן גישת קריאה בלבד?

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

מה קורה אם הטוקן של הסוכן דולף?

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

האם המידע העסקי שלי נשלח למודל?

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

כמה זמן לוקח להקים שרת MCP מול מערכת קיימת?

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

צריך מפתח בשביל זה?

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

סיכום

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

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