MCP הוא פרוטוקול שמאפשר לכלי AI לגלות ולהפעיל כלים שמערכת אחרת חושפת. לדוגמה, Claude Code יכול לקבל כלי לקריאת רשומות ממערכת תרגול ולהשתמש בתוצאה כדי להכין סיכום. כדי לאפשר גם שינוי ברשומות, צריך להגדיר בנפרד אילו פעולות מותרות, מי מאשר אותן ואיך השרת בודק את האישור.
החיבור אינו הופך כל מערכת לאוטומטית מעצמו. נדרש שרת MCP מתאים, דרך גישה למידע וכללים בצד המערכת. המדריך מציג מחבר מקומי שכתבנו לצורך תרגול, עם שלוש רשומות בדיוניות. הוא אינו מחבר רשמי של ספק CRM.
מה מחובר למה
Claude Code משמש כלקוח. שרת ה־MCP מציג רשימת כלים, תיאור ופורמט קלט לכל כלי. המודל יכול לבקש להפעיל כלי, והשרת מחזיר נתונים או שגיאה. מפרט כלי MCP מגדיר את גילוי הכלים, הקריאה להם ומבנה התוצאה.
במחבר עסקי אמיתי, מאחורי השרת יכולה להיות מערכת עם API. אם אין API מתאים או אם הרשאותיו מוגבלות, MCP אינו עוקף את המגבלה. לפני התקנה יש לזהות מי כתב את המחבר, מה הוא יכול לקרוא ולשנות ואילו פרטי גישה הוא דורש.
למי שטרם עבד עם כלי הפיתוח, מדריך Claude Code בעברית מציג את ההתקנה ואת סביבת העבודה. מדריך סוכן AI לעסק עוזר להגדיר קודם את התהליך שהחיבור אמור לשרת.
שלושה כלים בדוגמה המקומית
| כלי | מה הוא עושה | מה הוא אינו מאשר |
|---|---|---|
| list_records | קורא שלוש רשומות תרגול | אינו משנה סטטוס |
| propose_status | מכין הצעת שינוי לרשומה | אינו מבצע את השינוי |
| apply_approved_status | מיישם הצעה שאושרה בערוץ נפרד | אינו מאפשר למודל לאשר לעצמו |
הצעת השינוי כוללת מזהה רשומה, מצב קודם, מצב מבוקש וגרסה צפויה. כשמבקשים ליישם אותה, השרת בודק שיש אישור להצעה המסוימת ושגרסת הרשומה לא השתנתה. האישור נצרך לאחר שימוש אחד.
בקובץ התרגול האישור נשמר בקובץ מפעיל נפרד. זוהי המחשה בלבד: אם נותנים לסוכן גם גישה לעריכת קובץ האישורים דרך כלי קבצים, ההפרדה מתבטלת. במערכת אמיתית האישור צריך להישמר בערוץ שהמודל אינו יכול לשנות בעצמו, כגון שירות אישורים עם זהות משתמש מאומתת.
מה בדקנו בפועל
הרצנו לקוח בדיקה מקומי מול השרת דרך stdio, וביצענו את חילופי הודעות ה־JSON-RPC. נבדקו אתחול, גילוי שלושת הכלים וקריאת שלוש הרשומות. לאחר יצירת הצעת שינוי וידאנו שהרשומה עדיין לא השתנתה.
ניסיון ביצוע בלי אישור נדחה. גם הוספת confirmed: true לבקשת המודל נדחתה, משום ששדה כזה אינו נתמך. לאחר ששלב המפעיל בבדיקה אישר את ההצעה המסוימת, הסטטוס השתנה. ניסיון חוזר באותו אישור נדחה, וכך גם הצעה שהתיישנה אחרי שינוי ברשומה.
בנוסף בדקנו רשומה חסרה וסיום תקין של המחבר. בסך הכול עברו עשר בדיקות מתועדות. אפשר להוריד את דוח חילופי ההודעות והבדיקות ואת ערכת הקוד המקומית. זו בדיקת הפרוטוקול והלוגיקה של המחבר, ולא בדיקת חיבור למערכת לקוחות פעילה.
מדריכים ועדכונים לעבודה עם AI
מדריכים בעברית, עדכוני כלים ודוגמאות לעבודה עם בינה מלאכותית.
חיבור לסביבת Claude Code
תיאור הכלי הוא חלק מממשק העבודה
כלי בשם ״עדכן רשומה״ משאיר שאלות רבות פתוחות. איזו רשומה, באיזה חשבון, אילו שדות מותר לשנות ומה קורה כשהמזהה אינו קיים? תיאור מועיל צריך להסביר את הפעולה ואת גבולותיה. בדוגמת התרגול, ההפרדה בין הצעה לבין יישום אינה רק בחירת שמות: כל כלי מחזיר תוצאה אחרת ומקבל סוג אחר של קלט. כך קל יותר גם למודל וגם למפתח להבין באיזה שלב נמצאים.
בונים קלט מצומצם שאפשר לאמת
אם הפעולה משנה סטטוס, הגדירו את רשימת הסטטוסים המותרת ואת מזהה הרשומה. אין סיבה לקבל באותה קריאה אובייקט חופשי שמאפשר לשנות כל שדה במערכת. השרת צריך לדחות ערך שאינו נתמך ולהחזיר שגיאה שניתן לפעול לפיה. ההגדרה אינה צריכה לכלול תיאור מפורט של התשתית הפנימית; היא צריכה להסביר למשתמש בכלי איזה מידע דרוש ומה הוא יקבל בחזרה.
מגדירים מה פירושה של הצלחה
תוצאה כמו ״בוצע״ אינה תמיד מספיקה. בפעולת עדכון אפשר להחזיר את מזהה הרשומה, הסטטוס שנשמר ומספר הגרסה החדש. בפעולה שהוכנסה לתור, התוצאה צריכה לומר שהיא התקבלה לתור ולא שכבר הושלמה. ההבחנה הזאת חשובה במיוחד כאשר הסוכן מסכם את העבודה בשפה טבעית: הוא צריך להישען על מצב אמיתי, ולא להפוך קבלת בקשה לאישור שהיעד העסקי הושג.
בודקים שינוי שקרה במקביל
נניח שהסוכן הציע להעביר פנייה מ־new ל־contacted, ובזמן שהמתין לאישור עובד אחר כבר סגר אותה. ביצוע ההצעה הישנה עלול לפתוח מחדש תהליך שהסתיים. בדוגמת התרגול, הגרסה הצפויה מאפשרת לזהות את השינוי ולעצור. לאחר העצירה קוראים שוב את הרשומה ומכינים הצעה מעודכנת אם היא עדיין נדרשת. זו אינה תקלה שצריך להסתיר בניסיון אוטומטי נוסף, אלא מצב עסקי שדורש בחינה מחדש.
מחבר מקומי ומחבר מרוחק
במחבר מקומי, הלקוח מפעיל תהליך בסביבת המחשב ומחליף איתו הודעות. במחבר מרוחק, הוא פונה לשירות שמופעל במקום אחר. תיעוד Claude Code מציג את דרכי החיבור המתאימות לכל מסלול. מבחינת העסק, השאלה המרכזית היא מי מפעיל ומתחזק את השירות, היכן נשמרים פרטי הגישה ומי יכול להפסיק את החיבור. התקנה מקומית אינה אומרת שכל המידע נשאר מקומי; המחבר יכול לפנות ל־API חיצוני.
לפני הוספת מחבר, בדקו את הרשאות השירות שאליו הוא מתחבר. חשבון בעל גישה מלאה למערכת אינו נחוץ אם הסוכן צריך רק לקרוא רשימת מוצרים. הפרדה בין חשבונות וסוגי גישה מקלה גם על ביטול הרשאה בהמשך. אם עובד עוזב או שהפרויקט מסתיים, צריכה להיות דרך ברורה להפסיק את הגישה בלי לשנות את כל סביבת העבודה של הצוות.
כדאי גם להגדיר מי מאשר עדכון לגרסת המחבר. הוספת כלי חדש יכולה להרחיב את הפעולות הזמינות לסוכן, גם אם לא שיניתם את הפרומפט שלו. לאחר עדכון, עברו על רשימת הכלים ועל השדות שהם מקבלים. בדקו שוב את הפעולה הרגילה ואת המקרים שבהם השרת אמור לסרב. כך שינוי טכני בספרייה אינו הופך בלי כוונה לשינוי בסמכות שהעסק נתן למערכת.
תיעוד Claude Code מפרט חיבור לשרתי MCP מקומיים ומרוחקים, תחומי הגדרה ואפשרויות אימות. פעלו לפי הוראות החיבור העדכניות. עבור הדוגמה המצורפת, התהליך שמפעילים הוא Node עם הקובץ mcp-server.mjs מתוך תיקיית התרגול; אין צורך בפרטי גישה של עסק.
לאחר ההוספה בדקו שהשרת מחובר ושהכלים המופיעים הם אלה שציפיתם להם. התחילו בבקשת קריאה: ״הצג את שלוש רשומות התרגול וסכם כמה נמצאות בסטטוס new. אל תשנה דבר.״ אחר כך אפשר לבקש הצעת שינוי ולהשוות אותה לרשומה. אישור פעולה בממשק הלקוח אינו תחליף לכללי ההרשאה של השרת.
שימו לב גם לתחום ההגדרה: מחבר שנועד לפרויקט תרגול אחד אינו בהכרח צריך להופיע בכל פרויקט שלכם. אל תשמרו מפתחות בתוך קובץ שיפורסם עם הקוד.
מידע חסר ומחבר שלא מגיב
אם כלי מחזיר ״רשומה לא נמצאה״, אין להשלים אותה מזיכרון השיחה. בקשו מזהה נכון או הציגו את השגיאה בצורה שמאפשרת לצוות לבדוק. שגיאת כלי היא חלק מהתוצאה, ולא אישור שהפעולה הצליחה.
הגדירו זמן המתנה מוגבל לקריאה. אם חיבור נקטע בזמן כתיבה, בדקו את מצב הפעולה לפני ניסיון נוסף. אפשרות ניסיון חוזר מתאימה במיוחד לקריאה, אך כתיבה דורשת מזהה פעולה ומניעת כפילות. מחבר התרגול שומר נתונים בזיכרון בלבד ומאפס אותם בהפעלה מחדש; הוא אינו מדגים תור משימות או אחסון עמיד.
מה לבקש במסירה של חיבור עסקי
בקשו רשימה קצרה של הכלים שנחשפו, המקור שמאחוריהם וההרשאה הנדרשת לכל פעולה. לצד הרשימה צריכה להיות דוגמת קריאה תקינה ודוגמת כשל לכל פעולה מהותית. במסירת חיבור CRM, למשל, כדאי לראות מה קורה כאשר המזהה אינו נמצא, כאשר החשבון אינו רשאי לגשת אליו וכאשר הרשומה השתנתה מאז שהוכנה ההצעה. דוגמאות כאלה מסבירות את החיבור טוב יותר מהדגמת שיחה מוצלחת אחת.
לבסוף, הגדירו איך צוות התפעול מקבל מידע על כשל בלי לחשוף תוכן רגיש. מזהה פעולה, סוג שגיאה וזמן ניסיון יכולים להספיק לבירור ראשוני. אין צורך להעתיק כל מסמך או כל פנייה ליומן פתוח. מערכת שמחזירה שגיאה ברורה ושומרת תיעוד מתאים מאפשרת לטפל בתקלה, לשחזר את רצף האירועים ולהחליט אם נכון לנסות שוב. אלה פרטים שקובעים אם המחבר יוכל לשרת עבודה אמיתית לאורך זמן.
שאלו גם מה קורה כאשר המחבר אינו מחובר. אם הוא חיוני לתשובה, הסוכן צריך לציין שלא הצליח לקרוא את המערכת. אם אפשר להכין טיוטה בלי החיבור, עליה להיות מסומנת בהתאם ולא לכלול סטטוס שנלקח משיחה קודמת. ההבדל בין מידע שנקרא עכשיו לבין מידע שנזכר מהקשר קודם צריך להיות ברור למי שמקבל את התוצאה, במיוחד בפעולות שמשנות רשומות עסקיות.
שאלות נפוצות
האם MCP מחליף API?
לרוב הוא יושב מעל יכולות המערכת ומציג אותן לכלי AI בפורמט אחיד. החיבור למידע, ההרשאות והטיפול בשגיאות עדיין צריכים להיות ממומשים.
האם כדאי לתת לסוכן גישה לכל הכלים?
התחילו בכלים הדרושים לתהליך אחד. אם המטרה היא סיכום נתונים, אין סיבה להוסיף באותו שלב כלי מחיקה או שינוי. הרחבת הסמכות צריכה לבוא עם בדיקות מתאימות.
איך מתכננים חיבור למערכת שכבר קיימת בעסק?
מגדירים את הפעולה, מקור המידע והאישור הנדרש, ובודקים את ה־API וההרשאות של הספק. אפשר לדבר על המערכות שאתם עובדים איתן ולבחון חיבור מותאם ל־Claude, לסוכן AI או לאוטומציה קיימת.