MCP או API ישיר? אותה משימה, שני מימושים, השוואה צד-לצד

השאלה שנשאלת בפועל היא לא "מה יותר טוב"

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

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

המשימה שנשווה עליה

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

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

גרסה א׳ — אינטגרציית REST ייעודית

מה שנכתב בפועל, בסדר הכתיבה:

1. findCustomerByPhone(phone)
   GET /api/v2/contacts?phone=...      + טיפול ב-404 ובכפילויות
2. listOpenOrders(customerId)
   GET /api/v2/orders?contact=...      + pagination + סינון סטטוס
3. formatReply(orders, lang)
   תבנית טקסט, או קריאה למודל עם ההזמנות כהקשר
4. ניתוב כוונה: מהו המשפט הזה בכלל? (regex / מסווג)
5. אימות: refresh token, אחסון סוד, rotation
6. עמידות: retry עם backoff, timeout, מעגל ניתוק
7. בדיקות: mock לשרת ה-CRM, בדיקת רגרסיה על כל שדה

שבעה רכיבים, מתוכם שניים בלבד (1 ו-2) הם "החיבור למערכת". החמישה האחרים הם התשתית שסביבו, והם אלה שנכתבים מחדש בכל אינטגרציה חדשה.

גרסה ב׳ — שרת MCP

1. שרת MCP שמצהיר על שני כלים:
   find_customer(phone)           → אותה קריאת GET בדיוק
   list_open_orders(customer_id)  → אותה קריאת GET בדיוק
2. סכמת קלט לכל כלי, ותיאור מילולי שהמודל קורא
3. הרשאות: קריאה בלבד; אין כלי כתיבה בשרת הזה
4. חיבור הלקוח (Claude / ChatGPT / כלי משלכם) לשרת
5. ניתוב הכוונה, ניסוח התשובה ושאלת ההבהרה — אצל המודל

שימו לב קודם כול למה שלא נעלם. שתי קריאות ה-HTTP ל-CRM נכתבות בשתי הגרסאות, מילה במילה. הטיפול ב-404, ב-pagination וב-rate limit של ה-CRM נכתב בשתי הגרסאות. אחסון הסוד ו-rotation שלו נכתבים בשתי הגרסאות. מי שמוכר לכם MCP כ"בלי לכתוב אינטגרציה" מוכר לכם משהו אחר ממה שקיים.

מה באמת השתנה בין שתי הגרסאות

• הניתוב עבר מהקוד למודל. סעיף 4 בגרסה א׳ — הלוגיקה שמחליטה איזו פונקציה להפעיל — נעלם מהקוד שלכם. זה הרווח הגדול, וזה גם הסיכון הגדול: הוא לא נעלם, הוא הפך ללא-דטרמיניסטי.
• הסכמה הפכה לתיעוד שמכונה קוראת. ב-REST, השדות של הפונקציה נמצאים בקוד ובקובץ README שמתיישן. ב-MCP הם חלק מהתשובה שהשרת מחזיר, ולכן הם עדכניים בהגדרה — ואם הם שקריים, המודל יטעה בביטחון מלא.
• ניסוח התשובה נמחק מהקוד. formatReply על כל התבניות שלו לא נכתב. במקומו יש עלות טוקנים לכל פנייה.
• נוסף רכיב שלא היה קיים: אישור פעולה. בגרסה ב׳ מישהו צריך להחליט אילו כלים דורשים אישור אנושי לפני הרצה. בגרסה א׳ השאלה הזו לא נשאלת, כי הקוד לעולם לא יעשה משהו שלא כתבתם.
• ה-latency גדל. קריאת REST ישירה היא קפיצה אחת. תשובת MCP היא לפחות קריאה אחת למודל, לרוב שתיים או שלוש, ובכל אחת מהן הקשר שגדל.

טענת התחזוקה — הצד החזק של MCP

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

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

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

מתי API ישיר הוא התשובה הנכונה — בלי התחמקות

יש מקרים שבהם הוספת MCP היא הנדסה מיותרת, ולפעמים ממש טעות:

• זרימה דטרמיניסטית שחייבת לרוץ אותו דבר בכל פעם. הוצאת חשבונית, חיוב אשראי, עדכון מלאי, שידור דיווח לרשות. אלה תהליכים שבהם "המודל בחר אחרת הפעם" הוא תקלה, לא גמישות. כתבו קוד.
• נפח גבוה. אלפי פעולות ביום שכולן זהות במבנה שלהן לא צריכות מודל שיחליט עליהן. העלות והזמן מצטברים לכיוון אחד בלבד.
• latency שמשפיע על המשתמש. אם התשובה צריכה לחזור תוך מאות מילישניות, סבב מודל אחד כבר הוציא אתכם מהתקציב.
• אין מודל בלולאה. סנכרון לילי בין מערכות, ETL, webhook שמעדכן טבלה — אין כאן מי שיקרא את תיאור הכלי. MCP במקרה כזה הוא שכבת תרגום ללא צרכן.
• צרכן יחיד וקבוע, מול API פשוט ויציב. אם החיבור הוא ארבעים שורות מול ממשק שלא השתנה שנתיים, שרת MCP הוא יותר קוד לתחזק, לא פחות.
• דרישת ביקורת שמחייבת עקבה זהה. כשצריך להוכיח לרגולטור או למבקר שכל בקשה מטופלת באותו רצף פעולות מדויק, קוד מפורש מוכיח את זה. רצף שנקבע בזמן ריצה על ידי מודל מקשה על ההוכחה הזו.

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

מה MCP לא פותר

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

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

ההחלטה בפועל: כמעט תמיד שתיהן

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

רשימת בדיקה לפני שמחליטים

1. מי קורא לממשק — קוד שלי, או מודל שמחליט בזמן ריצה?
2. כמה צרכנים שונים יצטרכו את אותה מערכת בשנה הקרובה?
3. מה קורה אם הפעולה תרוץ פעמיים, או בסדר לא צפוי?
4. מהי תקרת ה-latency שהמשתמש שלי סובל?
5. מה נפח הפעולות ביום, ומה העלות לפעולה בכל אחת מהגישות?
6. האם קיים שרת רשמי למערכת הזו, או שאני בונה גם אותו?
7. אילו כלים בשום מקרה לא יורצו בלי אישור אנושי?

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

סיכום

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