---
title: "ארכיטקטורת שרת MCP לאינטגרציית כלים בארגון"
description: "ארכיטקטורת שרת MCP לארגונים: חמש שכבות, מפרט ההרשאות 2026-07-28, והמתקפות שכל שכבה צריכה לעצור."
source: "https://agntc.work/he/blog/mcp-server-architecture/"
pubDate: "2026-10-26T00:00:00.000Z"
category: "agent-protocols"
author: "Erez Eden"
proficiencyLevel: "Intermediate"
dependencies: ["MCP SDK","Node.js"]
tags: ["MCP","Tooling","Agents","Protocols","Security"]
---
# Executive Summary
שרת MCP ארגוני הוא גבול מוקלד ומורשה בין סוכנים למערכות פנימיות. לארכיטקטורה חמש שכבות: חוזה כלים, זהות, תעבורה, חוזה שגיאות ואובזרבביליטי. הפרוטוקול מסטנדרט את פורמט התקשורת. חמש השכבות האלה הן ההחלטות שהוא משאיר לכם.

# Key Takeaways
- ממדלים כל יכולת פנימית ככלי צר ומתואר היטב, לא כמריץ גנרי, ומתייחסים לתיאורי כלים כקלט לא מהימן.
- מפרט MCP 2026-07-28 הופך את השרת ל-resource server של OAuth 2.1. מנפיקים סקופים פר-כלי שמופקים מהקורא, לעולם לא חשבון שירות משותף.
- מחזירים שגיאות דטרמיניסטיות ומוקלדות כדי שסוכנים יוכלו להתאושש במקום לנחש.
- מתעדים בלוג כל קריאת כלי עם זהות הקורא מהיום הראשון. דיבאג של התנהגות סוכן בלי לוגים של קריאות הוא כמעט בלתי אפשרי.

# Glossary
## שרת MCP
שירות שחושף כלים ומשאבים לסוכנים דרך Model Context Protocol, ובדרך כלל עוטף מערכת פנימית אחת.

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

# FAQ
## מהו Model Context Protocol ב-AI ארגוני?
MCP הוא פרוטוקול פתוח שמאפשר לסוכנים לגלות ולקרוא לכלים דרך ממשק סטנדרטי, ומנתק את לוגיקת הסוכן מכל מערכת פנימית. גרסת הפרוטוקול הנוכחית היא 2026-07-28.

## איך סוכנים חולקים הקשר בצורה בטוחה?
ההקשר נחשף דרך כלים ומשאבים עם סקופים, כך שסוכן מקבל רק את המידע שהאישורים והתפקיד שלו מאפשרים. שרת ה-MCP פועל כ-resource server של OAuth 2.1 שמאמת טוקנים בכל קריאה.

## שרתי MCP צריכים לרוץ כתהליכים מקומיים או כשירותים משותפים?
שרתי stdio מקומיים מתאימים לכלי מפתח-יחיד. מערכות ארגוניות משותפות שייכות מאחורי Streamable HTTP עם אימות טוקנים, בדרך כלל מאוגדות מאחורי גייטוויי שמחזיק אימות ורייט לימיט.

## מה סיכון האבטחה הגדול של MCP בפרודקשן?
הרעלת כלים: הוראות זדוניות מוסתרות בתיאורי כלים שהמודל קורא אבל המשתמש אף פעם לא רואה. הבנצ'מרק MCPTox מדד שיעור הצלחת מתקפה ממוצע של 36.5% על פני 20 מודלים, עם הפגיע ביותר ב-72.8%, ולכן נועצים גרסאות של הגדרות כלים וסוקרים שינויי תיאורים כמו שינויי קוד.

---

סוכנים הופכים לשימושיים כשהם יכולים לפעול, ולפעול זה לקרוא למערכות פנימיות. [Model Context Protocol](https://modelcontextprotocol.io/specification/versioning) מסטנדרט את הגבול הזה: שרת מפרסם כלים, סוכן קורא להם, והתעבורה אחידה בין ספקים. מה שהפרוטוקול בכוונה לא מחליט הוא מודל האבטחה והשגיאות שלכם. זו הארכיטקטורה, והמדריך הזה עובר עליה שכבה אחר שכבה.

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

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

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

| שכבה | ברירת מחדל חלשה | חוזה ארגוני |
| --- | --- | --- |
| חוזה כלים | מריץ `run_query` גנרי אחד | כלים צרים ומוקלדים, תיאורים נסקרים |
| זהות | חשבון שירות משותף | resource server של OAuth 2.1, סקופים פר-כלי |
| תעבורה | stdio מקומי לכל דבר | Streamable HTTP מאחורי גייטוויי |
| שגיאות | חריגות מושלכות | תוצאות מוקלדות ומתועדות |
| אובזרבביליטי | אין לוג קריאות | כל קריאה מתועדת עם זהות הקורא |

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

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

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

```ts
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 חשפה מתקפות הרעלת כלים](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks): הוראות מוסתרות בתוך תיאורי כלים שהמודל קורא והמשתמש אף פעם לא רואה. [בנצ'מרק MCPTox](https://arxiv.org/abs/2508.14925) (אוגוסט 2025) הפך את החשיפה למספרים: כלים מורעלים שכוונו ל-45 שרתי MCP חיים ו-20 מודלים, עם שיעור הצלחת מתקפה ממוצע של 36.5%, כמה מודלים מעל 60%, והפגיע ביותר (o1-mini) ב-72.8%. [הערת מחקר של Cloud Security Alliance](https://labs.cloudsecurityalliance.org/research/csa-research-note-mcp-tool-poisoning-ai-agent-exfiltration-2/) מסיקה את אותה מסקנה תפעולית: מתייחסים לכל שרת MCP כלא מהימן, אפילו אחד שכבר אישרתם. המשמעות המעשית: נועצים גרסאות של שרתים וכלים, עושים diff לשינויי תיאורים בסקירה כמו שהייתם עושים לקוד, ואף פעם לא נותנים לשרת צד שלישי לעדכן את התיאורים שלו בשקט.

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

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

הפרוטוקול השלים את הפער. [מפרט ההרשאות הנוכחי של MCP, גרסה 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization), הופך את השרת ל-resource server של OAuth 2.1, תפקיד שהמפרט מגדיר מאז רוויזיית 2025-03-26. שלוש דרישות חשובות לעיצוב שלכם:

1. השרת חייב לפרסם [מטא-נתונים של משאב מוגן (RFC 9728)](https://www.rfc-editor.org/rfc/rfc9728.html) כדי שלקוחות יוכלו לגלות לאיזה שרת הרשאות לפנות.
2. טוקנים קשורים למשאב עם [אינדיקטורים של משאבים (RFC 8707)](https://www.rfc-editor.org/rfc/rfc8707.html), כך שטוקן שהונפק לשרת MCP אחד לא ניתן להשמעה מחדש מול אחר. זה הורג את פטרן ה-confused deputy שבו גייטוויי מעביר בשמחה טוקן לכל מקום.
3. Dynamic Client Registration יצא משימוש לטובת Client ID Metadata Documents, כך ששרת ההרשאות שלכם כבר לא צריך נקודת קצה פתוחה לרישום לקוחות.

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

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

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

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

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

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

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

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

הספרות האקדמית כבר מסכימה. [מאמר מיוני 2026 על פטרני ארכיטקטורה של שרתי MCP](https://arxiv.org/html/2606.30317) אומר את זה ישירות: מחזירים שגיאות כלים כתוכן מובנה כדי שהמודל יוכל לראות את השגיאה, להסיק אם לנסות שוב, ולהחליט מתי להעלות למשתמש. ונותנים לכל שגיאה קוד יציב קריא-מכונה. בני אדם קוראים הודעות. סוכנים מתפצלים על קודים.

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

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

מזינים את הלוגים האלה לאותו צינור כמו [אודיט לוג סוכני ה-AI](/blog/ai-agent-audit-log/) (באנגלית), כדי שקריאת כלי, אישור וקריאת מידע יחלקו ציר זמן אחד. כשאדם חייב לאשר קריאה רגישה לפני שהיא מתבצעת, רשומת הלוג היא מה שהופך את האישור למחייב, כפי שכיסיתי ב-[Human-in-the-Loop AI Approval That Actually Binds](/blog/human-in-the-loop-ai-approval-that-actually-binds/) (באנגלית).

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

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

| מתקפה | חשיפה | שכבת הארכיטקטורה שעוצרת אותה |
| --- | --- | --- |
| הרעלת כלים: הוראות מוסתרות בתיאורים | Invariant Labs, אפריל 2025 | חוזה כלים: נועצים גרסאות, סוקרים תיאורים |
| MCPoison: קובץ קונפיגורציית MCP שכבר אושר מוחלף בשקט בזדוני | [CVE-2025-54136](https://nvd.nist.gov/vuln/detail/CVE-2025-54136), קרסר, CVSS 8.8, Check Point Research, תוקן יולי 2025 | חוזה כלים: נועצים קונפיגורציות ומאשרים מחדש בכל שינוי |
| השמעה חוזרת של טוקן בין שרתים | טופל בקישור RFC 8707 במפרט 2026-07-28 | זהות: טוקנים קשורי-משאב |
| RCE דרך ספריית התעבורה `mcp-remote` | [CVE-2025-6514](https://nvd.nist.gov/vuln/detail/CVE-2025-6514), CVSS 9.6, יותר מ-437,000 הורדות בעת החשיפה | תעבורה: מתקנים ונועצים ספריות לקוח |
| הדלפה שקטה של מידע על ידי שרת מושחת | פגמי בידוד בין-טננטיים שדווחו באינטגרציות ארגוניות | אובזרבביליטי: לוגים פר-קריאה עם זהות |

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

## לבנות או לאמץ

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

## לקריאה נוספת

- [How to Evaluate Any MCP Gateway](/blog/mcp-gateways-verified/): הרובריק של הקונה לנקודת הבקרה בשכבה 3, עם קריטריונים מאומתים (באנגלית).
- [AI Agent Audit Log](/blog/ai-agent-audit-log/): מודל האירועים מאחורי שכבה 5, כולל מה לתעד לכל קריאה (באנגלית).
- [Permission-Aware RAG for Enterprise Knowledge Systems](/blog/permission-aware-rag/): אותו משמעת זהות מיושמת על שליפה, שם מצב הכישלון הוא תשובה נכונה שנבנתה ממסמך שהקורא אף פעם לא הורשה לקרוא (באנגלית).