ארכיטקטורת שרת MCP לאינטגרציית כלים בארגון

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

הגרסה המקורית של המאמר כיסתה שלוש החלטות. שני CVE-ים ורוויזיית פרוטוקול אחת אחר כך, הוא מכסה חמש.

ארכיטקטורת הייחוס

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

שאר המדריך הוא חמש השורות האלה, מורחבות.

שכבה 1: כלים, לא מריץ גנרי

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

server.tool(
  'get_invoice_status',
  { invoiceId: z.string().uuid() },
  async ({ invoiceId }, ctx) => {
    const invoice = await billing.getInvoice(invoiceId, ctx.auth.scopes);
    if (!invoice) return { error: 'not_found' as const };
    return { status: invoice.status, dueAt: invoice.dueAt };
  }
);

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

הנקודה השנייה הפכה לקונקרטית באפריל 2025, כשInvariant Labs חשפה מתקפות הרעלת כלים: הוראות מוסתרות בתוך תיאורי כלים שהמודל קורא והמשתמש אף פעם לא רואה. בנצ’מרק MCPTox (אוגוסט 2025) הפך את החשיפה למספרים: כלים מורעלים שכוונו ל-45 שרתי MCP חיים ו-20 מודלים, עם שיעור הצלחת מתקפה ממוצע של 36.5%, כמה מודלים מעל 60%, והפגיע ביותר (o1-mini) ב-72.8%. הערת מחקר של Cloud Security Alliance מסיקה את אותה מסקנה תפעולית: מתייחסים לכל שרת MCP כלא מהימן, אפילו אחד שכבר אישרתם. המשמעות המעשית: נועצים גרסאות של שרתים וכלים, עושים diff לשינויי תיאורים בסקירה כמו שהייתם עושים לקוד, ואף פעם לא נותנים לשרת צד שלישי לעדכן את התיאורים שלו בשקט.

שכבה 2: זהות היא פר-קריאה, לא פר-שרת

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

הפרוטוקול השלים את הפער. מפרט ההרשאות הנוכחי של MCP, גרסה 2026-07-28, הופך את השרת ל-resource server של OAuth 2.1, תפקיד שהמפרט מגדיר מאז רוויזיית 2025-03-26. שלוש דרישות חשובות לעיצוב שלכם:

1. השרת חייב לפרסם מטא-נתונים של משאב מוגן (RFC 9728) כדי שלקוחות יוכלו לגלות לאיזה שרת הרשאות לפנות.
2. טוקנים קשורים למשאב עם אינדיקטורים של משאבים (RFC 8707), כך שטוקן שהונפק לשרת MCP אחד לא ניתן להשמעה מחדש מול אחר. זה הורג את פטרן ה-confused deputy שבו גייטוויי מעביר בשמחה טוקן לכל מקום.
3. Dynamic Client Registration יצא משימוש לטובת Client ID Metadata Documents, כך ששרת ההרשאות שלכם כבר לא צריך נקודת קצה פתוחה לרישום לקוחות.

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

שכבה 3: תעבורה ודיפלוימנט

MCP מציע שתי תעבורות, והן מובילות לשתי ארכיטקטורות שונות.

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

Streamable HTTP מריץ את השרת כשירות רשת. זה הנתיב הארגוני: השרת מאמת טוקנים בעצמו, אפשר להרחיב אותו בנפרד, ואפשר לשים לפניו נקודת בקרה. נקודת הבקרה הזו היא בדרך כלל גייטוויי שמסיים אימות, אוכף רייט לימיט ומנתב לשרתים בודדים. mcp-gateway הפתוח של Microsoft הוא ייחוס שימושי למה שפרודקשן אומר כאן: StatefulSets של קוברנטיס, מטא-דאטה של משאבים ב-Redis או Cosmos DB, אימות Entra ID, וכלל קשיח ששרתי הכלים הפנימיים דוחים כל בקשה בלי ה-header הסודי של הגייטוויי. בניתי רובריק איוול לנוף הזה ב-How to Evaluate Any MCP Gateway (באנגלית).

מלכודה אחת שכדאי לציין בשמה: סטייט. תעבורת HTTP+SSE המקורית שמרה סשנים ארוכי-חיים, מה שהקשה על סקיילינג אופקי, ורוויזיית 2026-07-28 כבר לא כוללת אותה בכלל. Streamable HTTP נותן להריץ שרתים סטייטלס, עם כל סטייט מתמשך שנדחף לחנות שהרפליקות חולקות. מתכננים לסטייטלס מההתחלה.

שכבה 4: שגיאות הן חלק מהממשק

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

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

שכבה 5: אובזרבביליטי היא לא אופציונלית

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

מזינים את הלוגים האלה לאותו צינור כמו אודיט לוג סוכני ה-AI (באנגלית), כדי שקריאת כלי, אישור וקריאת מידע יחלקו ציר זמן אחד. כשאדם חייב לאשר קריאה רגישה לפני שהיא מתבצעת, רשומת הלוג היא מה שהופך את האישור למחייב, כפי שכיסיתי ב-Human-in-the-Loop AI Approval That Actually Binds (באנגלית).

המתקפות, ממופות לשכבות

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

אף שכבה בודדת לא מספיקה. בשביל זה יש חמש.

לבנות או לאמץ

אם יש לכם סוכן אחד ושלושה כלים פנימיים, דלגו על הגייטוויי והריצו שני-שלושה שרתי Streamable HTTP עם סקופים מצומצמים ואימות טוקנים. הסטאק המלא משלם לעצמו כשעוברים בערך עשרה שרתים, כמה צוותים, או דרישת קומפלייאנס להוכיח מי קרא למה. מתחת לקו הזה זו אורקסטרציה שאתם עוד לא צריכים, וWhen to Use Multi-Agent Orchestration (באנגלית) טוען את אותה טענה מצד הסוכן.

לקריאה נוספת

• How to Evaluate Any MCP Gateway: הרובריק של הקונה לנקודת הבקרה בשכבה 3, עם קריטריונים מאומתים (באנגלית).
• AI Agent Audit Log: מודל האירועים מאחורי שכבה 5, כולל מה לתעד לכל קריאה (באנגלית).
• Permission-Aware RAG for Enterprise Knowledge Systems: אותו משמעת זהות מיושמת על שליפה, שם מצב הכישלון הוא תשובה נכונה שנבנתה ממסמך שהקורא אף פעם לא הורשה לקרוא (באנגלית).