Enterprise MCP Registry: איך בונים קטלוג מרכזי ומאושר ל-MCP Servers

מאת צוות מדיה דיל · 06.08.2026 · Enterprise AI · 7 דק׳

מדריך ארכיטקטוני לבניית Enterprise MCP Registry: סכימת נתונים, תהליך אישור servers, ניהול גרסאות, והקשר ההכרחי בין הרשומה ל-MCP Gateway שאוכף אותה.

הבעיה: כל צוות מחבר MCP server אחר, ואף אחד לא יודע מה בכלל אושר

ברגע שארגון עובר לעבודה עם MCP (Model Context Protocol) בקנה מידה - לא agent בודד אלא עשרות צוותים שכל אחד מחבר את ה-agents שלו ל-tools חיצוניים ופנימיים - מתגלה בעיה שמזכירה מאוד את ימי ה-shadow IT הקדומים: צוות שיווק מחבר MCP server של ספק חיצוני לניתוח סנטימנט, צוות תמיכה מחבר server פנימי לגישה ל-CRM, וצוות פיתוח מנסה server ניסיוני מ-GitHub שמישהו מצא בפורום. בלי מקור אמת מרכזי, אין דרך לענות על השאלה הבסיסית ביותר: אילו MCP servers בכלל מותר להשתמש בהם בארגון, ובאילו תנאים. Enterprise MCP Registry הוא בדיוק התשתית שסוגרת את הפער הזה - קטלוג מרכזי, עם תהליך אישור מובנה, שמגדיר מהו ה"מדף המאושר" של MCP servers שממנו agents רשאים לבחור.

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

Registry שהוא רק רשימת שמות של servers עם קישור לא שווה הרבה. סכימה שעובדת בפרודקשן כוללת, לכל server רשום, לפחות את השדות הבאים:

{
  "server_id": "mcp-crm-readonly-v3",
  "name": "CRM Read-Only Connector",
  "vendor": "internal",
  "version": "3.2.1",
  "endpoint": "https://mcp.internal/crm-readonly",
  "approval_status": "approved",
  "risk_tier": "medium",
  "exposed_tools": ["search_contact", "get_deal_history"],
  "data_classification": "PII-medium",
  "owner_team": "sales-eng",
  "security_review_date": "2026-05-14",
  "last_audit_result": "pass",
  "deprecation_date": null
}

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

תהליך האישור: מ-Submission ל-Production

שלב הגשה (Submission)

צוות שרוצה לחבר MCP server חדש - בין אם פנימי שהוא בנה, ובין אם ספק חיצוני - מגיש בקשה מובנית שכוללת תיאור היכולות, סיווג הנתונים שה-server ניגש אליהם, ורשימת ה-tools שהוא חושף. הגשה לא מובנית, כמו "תוסיפו לי server" בהודעת סלאק, היא בדיוק מה שיוצר shadow AI - שלב זה חייב להיות פורמלי ומתועד.

סקירת סיכון (Risk Review)

צוות אבטחה (או, במימוש בשל, מנוע דירוג אוטומטי שמזהה דפוסי סיכון גבוה כמו tools שמבצעים כתיבה או גישה לנתונים רגישים) מדרג את ה-server לפי רמת סיכון, בדומה לשיטת ה-blast radius שתוארה במאמרים על AI-SPM ועל Agent Security Testing. server בסיכון נמוך (קריאה בלבד, נתונים ציבוריים) יכול לעבור אישור מהיר; server בסיכון גבוה (כתיבה, נתונים רגישים, ספק חיצוני לא מוכר) דורש בדיקת אבטחה מלאה לפני אישור.

אישור ופרסום (Approval & Publish)

לאחר אישור, ה-server מקבל סטטוס approved ב-registry, וממשק אוטומטי מפרסם אותו כזמין לשימוש - כולל, במימושים מתקדמים, סנכרון אוטומטי לרשימת ה-allowlist שה-MCP Gateway אוכף בזמן ריצה.

ניהול גרסאות (Versioning) - הבעיה שרוב הארגונים מתעלמים ממנה

MCP server מתעדכן - כמו כל תוכנה. הבעיה היא שעדכון גרסה יכול לשנות את רשימת ה-tools שה-server חושף, את הפרמטרים שהם מקבלים, או אפילו את ההתנהגות שלהם בלי לשנות את החתימה החיצונית - תרחיש שמכונה בקהילת ה-MCP "rug pull": server שאושר בגרסה מסוימת ואז "מחליף זהות" בגרסה הבאה. Registry בשל לא סתם שומר גרסה אחת לכל server; הוא שומר היסטוריית גרסאות מלאה, עם hash קריפטוגרפי של כל גרסה שאושרה, כדי שניתן יהיה לזהות מיידית אם server שרץ בפועל סוטה מהגרסה שעברה אישור. פרקטיקה טובה היא לדרוש אישור מחדש (ולו מקוצר) בכל שינוי גרסת minor, ואישור מלא בכל שינוי major או בכל שינוי שמוסיף tool חדש לרשימת החשיפה.

הקשר ההכרחי בין Registry ל-Gateway: החלטה מול אכיפה

כפי שצוין במאמר על MCP Gateway Architecture, יש הבחנה ברורה שחייבת להתקיים: ה-registry הוא שכבת ההחלטה - מקור האמת שקובע מה מותר. ה-gateway הוא שכבת האכיפה - הרכיב שבודק בכל קריאה בזמן ריצה האם היא תואמת את מה שה-registry אישר. registry בלי gateway הוא בעצם רשימת תיוג בגיליון - אין דבר שמונע מ-agent להתחבר ישירות ל-server לא מאושר. gateway בלי registry נאלץ להגדיר מדיניות אד-הוק בקוד עצמו, שהופך לבלתי ניתן לתחזוקה ברגע שיש עשרות servers. השילוב הנכון: ה-gateway שולף את רשימת ה-servers המאושרים מה-registry בזמן אמת (או כמעט-זמן-אמת דרך cache קצר-טווח), וחוסם אוטומטית כל קריאה ל-server שלא נמצא ברשימה או שהגרסה שלו לא תואמת את מה שאושר.

מי כותב את הבקשה - ולמה טופס חופשי לא מספיק

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

Trade-offs: מרכזיות מול מהירות אימוץ

תהליך אישור מרכזי ומוקפד מגן על הארגון, אבל מאט את קצב האימוץ - צוות שרוצה לנסות server חדש לצורך פרוטוטייפ לא יכול לחכות שבועיים לאישור מלא. הפתרון המעשי הוא מסלול כפול: sandbox tier שמאפשר לצוותים לנסות servers חדשים בסביבת בדיקה מבודדת, בלי גישה לנתוני פרודקשן, כמעט ללא תהליך אישור; ו-production tier עם תהליך האישור המלא שתואר למעלה, שנדרש רק כשה-server עומד לגעת בנתונים או תשתית אמיתיים. הפרדה כזו נותנת לצוותים חופש ניסוי בלי לפגוע בבקרה על מה שבאמת מגיע לפרודקשן.

שיקול נוסף הוא ריכוזיות מול בעלות מבוזרת על תהליך האישור עצמו: צוות אבטחה מרכזי יחיד שמאשר כל server בארגון גדול הופך לצוואר בקבוק; מודל מבוזר יותר, שבו כל domain מוסמך לאשר servers בסיכון נמוך-בינוני בעצמו לפי מדיניות שהוגדרה מרכזית, וצוות האבטחה המרכזי מתערב רק בסיכון גבוה, מאזן בין מהירות לבקרה - אך דורש הכשרה של "approvers" מבוזרים ומנגנון ביקורת (audit) שמוודא שהם אכן פועלים לפי המדיניות.

טעויות נפוצות בפרודקשן

הטעות הראשונה: לבנות registry שמכסה רק servers פנימיים ולהתעלם מספקים חיצוניים - בעוד שהסיכון הגבוה ביותר נמצא לרוב דווקא ב-servers של צד שלישי, שהארגון לא שולט בקוד שלהם ולא יכול לוודא שהם לא ישתנו בלי הודעה. הטעות השנייה: לאשר server פעם אחת ולא לבדוק שוב לעולם - כפי שתואר בסעיף על ניהול גרסאות, server שהשתנה בלי אישור מחדש הוא בדיוק תרחיש ה-rug pull שהמנגנון כולו נועד למנוע. הטעות השלישית: להפריד לחלוטין בין ה-registry ל-gateway כך שאישור ב-registry לא מתורגם אוטומטית לאכיפה בפועל - מה שיוצר פער מסוכן בין "מה שרשום כמאושר" לבין "מה שבאמת רץ".

מדדים לבשלות תוכנית ה-Registry

שלושה מדדים מעשיים מצביעים על בשלות: Time to Approval - כמה זמן עובר מהגשת בקשה לאישור, שכאשר הוא ארוך מדי דוחף צוותים לעקוף את התהליך; Registry-Gateway Drift - האם יש servers שרצים בפועל (כפי שמזוהה ב-discovery, ראו מאמר AI Asset Inventory) אך לא רשומים ב-registry, שהוא האינדיקטור הישיר ביותר ל-shadow MCP; ו-Stale Approval Rate - אחוז ה-servers שלא עברו סקירה מחדש מעבר לתקופה שהוגדרה במדיניות (למשל שנה), שמעיד עד כמה האישורים עדיין רלוונטיים למציאות הנוכחית.

שילוב עם Discovery אוטומטי - כדי שהקטלוג לא יישאר תיאורטי

הבעיה המעשית הגדולה ביותר של רוב הרישומים הארגוניים - לא רק ב-MCP - היא הפער בין "מה שרשום" לבין "מה שבאמת רץ". registry שמתעדכן רק כשצוות טורח להגיש בקשה באופן יזום ייתקע תמיד מאחורי המציאות, כי תמיד יהיה מפתח שמחבר server חדש לצורך בדיקה ושוכח - או לא יודע - שהוא צריך לרשום אותו. הפתרון הוא לחבר את ה-registry למנגנון discovery פסיבי, בדומה למה שתואר במאמר על AI Asset Inventory: proxy או sidecar ברמת ה-egress traffic שמזהה קריאות ל-endpoints של MCP servers לא מוכרים, ומייצר אוטומטית "בקשת רישום ממתינה" ברגע שהוא תופס תעבורה למקור שלא קיים בקטלוג. זה הופך את תהליך הרישום מ-push טהור (תלוי במשמעת הצוותים) לשילוב של push ו-pull, שבו גם server שלא דווח באופן יזום נתפס תוך זמן קצר יחסית.

המדד המעשי שממחיש את זה בפועל הוא "Registry Coverage Ratio" - היחס בין servers שהתגלו בפועל בתעבורה לבין servers שרשומים כמאושרים בקטלוג. פער גדול בין השניים הוא האינדיקטור החד ביותר לכך שיש MCP servers פעילים שאף אחד לא בדק ולא אישר - למעשה shadow MCP, הגרסה הספציפית של Shadow AI שרלוונטית לעולם ה-tool-calling.

ניהול Namespace ומניעת התנגשויות שמות

כשארגון גדל ליותר מכמה עשרות MCP servers רשומים, מתגלה בעיה מעשית שקל להזניח בתכנון ראשוני: התנגשויות שמות. שני צוותים שונים יכולים לבנות servers עם tool בשם search או get_status, וברגע שה-gateway או ה-agent צריכים לבחור ביניהם - בלי namespace ברור - נוצרת עמימות שעלולה לגרום ל-agent לקרוא לכלי הלא נכון. registry בשל אוכף מוסכמת שמות עם namespace מפורש (למשל sales-eng.crm-readonly.search_contact במקום סתם search), ודוחה בקשות רישום ששמן מתנגש עם server קיים. זו לא רק נוחות טכנית - זו דרישת אבטחה, כי בלבול בין שני tools בעלי שם דומה יכול להוביל agent להפעיל את הפעולה הלא נכונה בלי שאף אחד יזהה זאת מיד.

מתי כן ומתי לא

ארגון עם agent בודד ו-server אחד או שניים, שכולם פנימיים ונבנו על ידי אותו צוות, לא צריך registry ייעודי - תיעוד ידני מספיק. ברגע שיש יותר מצוות אחד שמחבר servers, כשמעורבים ספקים חיצוניים, או כשיש דרישת תאימות רגולטורית שמחייבת הוכחת בקרה על תלויות תוכנה - כולל AI - registry הופך להכרחי. הסימן הברור ביותר: אם אין דרך לענות תוך דקות על "אילו MCP servers מאושרים לשימוש בייצור כרגע ומי אישר אותם", התהליך הידני כבר לא מספיק.

איך אנחנו ניגשים לזה

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

סיכום

Enterprise MCP Registry הוא מקור האמת שקובע אילו servers מותר להשתמש בהם ובאילו תנאים, ומשלים את ה-gateway שאוכף את ההחלטה הזו בזמן ריצה. הארכיטקטורה הנכונה כוללת סכימת נתונים עשירה ברמת ה-tool הבודד, תהליך אישור בשני מסלולים (sandbox ופרודקשן), ניהול גרסאות שמונע rug pull, ושילוב עם discovery פסיבי כדי שהקטלוג ישקף את המציאות בפועל - לא רק החלטה חד-פעמית שנרקבת עם הזמן.

תגיות: Enterprise MCP Registry · MCP servers · AI governance · rug pull · MCP Gateway · versioning · vendor risk

← חזרה לבלוג · צור קשר