סקירה כללית של Model Context Protocol‏ (MCP) ב-Apigee

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לצפייה במאמרי העזרה של Apigee Edge.

בדף הזה מוסבר איך להשתמש ב-Apigee כדי לחשוף את ממשקי ה-API שלכם ככלי MCP לאפליקציות מבוססות-סוכנים. ‫MCP ב-Apigee זמין לארגונים עם מינוי, עם תשלום לפי שימוש ועם גרסת הערכה, כולל ארגונים עם מיקום אחסון נתונים מוגדר. החל מגרסה 1.17.0 של Apigee Hybrid, אפשר להשתמש ב-MCP גם ב-Apigee Hybrid – מישור הנתונים של זמן הריצה פועל בתוך אשכול Kubernetes שלכם, ולא בתשתית שמנוהלת על ידי Google. במאמר הפעלת MCP ב-Apigee hybrid מוסבר איך להתקין ולהגדיר את MCP ב-Apigee hybrid.

מה זה MCP?

‫Model Context Protocol‏ (MCP) הוא פרוטוקול קוד פתוח שפותח על ידי Anthropic, והוא יוצר סטנדרט לדרך שבה אפליקציות AI מתחברות למקורות נתונים, לתהליכי עבודה ולכלים.

אפליקציות AI יכולות להשתמש ב-MCP כדי לגשת לשירותי Google Cloud ו-Apigee ככלים. בהקשר הזה, כדאי להבין את המונחים הבאים שקשורים ל-MCP:

  • מארח MCP: אפליקציית ה-AI או הסביבה שמתקשרת עם המשתמש. מארח ה-MCP משתמש במודלים גדולים של שפה (LLM) כדי לעבד בקשות שעשויות לדרוש נתונים או כלים חיצוניים.
  • לקוח MCP: רכיב בתוך מארח ה-MCP שעוזר ל-LLM ולשרת ה-MCP לתקשר זה עם זה. הוא מתרגם את הבקשות של ה-LLM לשרת ה-MCP, וממיר את התשובות של שרת ה-MCP ל-LLM. הוא גם מוצא שרתי MCP זמינים ומשתמש בהם.
  • שרת MCP: השירות החיצוני שמספק הקשר, נתונים או יכולות ל-LLM, ומשמש כשרת proxy בין ה-LLM ללקוח ה-MCP.

איך MCP פועל ב-Apigee

נקודות הקצה של MCP ל-Google, ל- Google Cloudול-Apigee מטמיעות את מפרט שרת ה-MCP. כך לקוחות MCP תואמים יכולים לגשת אליהם כדי:

  • לגלות נקודות קצה (endpoints) זמינות.
  • רשימת הכלים שזמינים בנקודת קצה.
  • אימות לנקודת קצה.
  • להפעיל כלים בהתאם למדיניות הגישה שהוגדרה.

כל לקוח MCP שתומך בנקודות קצה מרוחקות של MCP דרך HTTP/S יכול לגשת לכלים האלה. מכיוון שנקודות הקצה מנוהלות, אתם לא צריכים להתקין או לנהל שרתי MCP מקומיים, שרתי MCP מרוחקים או תשתית נוספת כדי לאפשר לאפליקציות מבוססות-סוכנים לגשת לשירותים שלכם.

‫MCP ב-Apigee תומך ב-JSON-RPC ל-methods של tools/list ו-tools/call. אתם יכולים להתאים אישית את נקודת הקצה של ה-MCP באמצעות פרמטרים של גילוי, אבטחה, זמינות ברשת וניטור.

מודלים של פריסה

התכונה MCP זמינה בשני מודלים של פריסת Apigee:

  • ‫Apigee ‏ (SaaS): מישור הנתונים של MCP מתארח בתשתית שמנוהלת על ידי Google. אתם פורסים את שרת ה-proxy של MCP Discovery ונקודת הקצה זמינה באופן מיידי.
  • ‫Apigee Hybrid (אירוח עצמי, החל מגרסה 1.17.0 של Apigee Hybrid): מישור הנתונים של MCP פועל בתוך אשכול Kubernetes שלכם. מישור הבקרה של Apigee יוצר הגדרות של כלי MCP ממפרט OpenAPI, והאשכול מאחזר את ההגדרות האלה לפי לוח הזמנים שלו. תנועת הבקשות של MCP אף פעם לא יוצאת מהאשכול. הפעלת MCP ב-Apigee Hybrid

ארכיטקטורת מישור הנתונים של MCP ב-Apigee Hybrid

בתרשים הבא מוצג איך רכיבי ה-MCP מופצים בין מישור הבקרה של Apigee לבין אשכול Apigee hybrid.

‫MCP בארכיטקטורה של Apigee Hybrid: לקוחות MCP קוראים ל-Ingress הקיים של Apigee דרך HTTPS, שמנתב למעבד הבקשות שלכם ואז למישור הנתונים החדש של MCP באשכול. הגדרת הכלי MCP נוצרת על ידי מישור הבקרה של Apigee ונשלפת על ידי האשכול. מישור הבקרה של Apigee אף פעם לא קורא לאשכול.

שני מאפיינים של הארכיטקטורה הזו חשובים לתכנון ולבדיקת האבטחה:

  • תנועת הבקשות של MCP נשארת בתוך האשכול. לקוחות MCP פונים ל-Ingress הקיים של Apigee באותה כתובת URL שבה הם משתמשים לכל שרת proxy אחר של Apigee. מעבד הבקשות מנתב את הבקשה למישור הנתונים של MCP באותו אשכול. אף בקשה או תגובה של MCP לא חוצה את הגבול אל Google Cloud בזמן הבקשה.
  • ההגדרות נשלפות, לא נדחפות. ההגדרות של כלי ה-MCP נוצרות על ידי מישור הבקרה של Apigee, ורכיב באשכול שלכם מאחזר אותן לפי לוח זמנים. מישור הבקרה של Apigee אף פעם לא יוזם חיבור לאשכול. במאמר דרישות הרשת לתעבורת נתונים יוצאת מפורטות נקודות הקצה המדויקות שצריך לאפשר לתעבורת הנתונים היוצאת של האשכול.

התכונות העיקריות של MCP ב-Apigee

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

חיפוש כלים פשוט יותר באמצעות API Hub

אתם יכולים לגלות נקודות קצה זמינות של MCP לשירותי Apigee באמצעות שירות ספריות שנגיש דרך ממשק REST. כל נקודת קצה של MCP תומכת גם ב-method‏ tools/list של MCP, שמאפשר ללקוחות MCP לגלות את הכלים שזמינים בנקודת הקצה הזו.

בנוסף, MCP משתלב עם Apigee API hub. כשפורסים שרת פרוקסי ל-MCP Discovery, ‏API Hub מטמיע באופן אוטומטי את מפרט ה-OpenAPI שלו, מקצה לו את סגנון ה-API של MCP וממפה את פעולות ה-API לכלים ספציפיים של MCP. כך המפתחים יכולים לסנן בקלות ממשקי API שתומכים ב-MCP ב-API Hub, ולהשתמש בחיפוש סמנטי עם שאילתות בשפה טבעית כדי למצוא כלים רלוונטיים לאפליקציות מבוססות-הסוכנים שלהם.

מיקום הארגומנט של הכלי בבקשה לקצה העורפי

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

ערך in של OpenAPI המקום שבו הארגומנט נשלח בבקשה לקצה העורפי
header כ-request header. שם הפרמטר משמש כשם הכותרת, בדיוק כמו שהוא כתוב במפרט.
cookie בכותרת הבקשה Cookie, כצמד name=value. אם בפעולה מסוימת מוגדרים כמה פרמטרים של קובצי Cookie, הם נשלחים בכותרת Cookie אחת, ומופרדים באמצעות ;  (נקודה-פסיק ורווח).
query במחרוזת השאילתה.
path מוחלף בנתיב כתובת ה-URL של הבקשה.

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

לדוגמה, הפעולה הבאה מצהירה על פרמטר אחד בכל אחד משלושה מיקומים:

paths:
  /orders:
    get:
      operationId: listOrders
      parameters:
        - name: X-Session-Id
          in: header
          schema:
            type: string
        - name: tenantId
          in: cookie
          schema:
            type: string
        - name: limit
          in: query
          schema:
            type: integer

בקשת tools/call שמספקת את כל שלושת הארגומנטים יוצרת בקשת קצה עורפי בצורה הבאה:

GET /orders?limit=25
X-Session-Id: sess-abc-123
Cookie: tenantId=tenant-xyz-789

שימו לב להתנהגות הבאה:

  • ארגומנט שקשור לכותרת או לקובץ Cookie לא מצורף גם למחרוזת השאילתה, ולא נכלל בגוף הבקשה.
  • המערכת מדלגת על ארגומנט שהלקוח לא מספק. לא נשלחים במקומם כותרת, קובץ Cookie או פרמטר של שאילתה ריקים.
  • כותרת מקושרת מחליפה כל כותרת עם אותו שם שכבר קיימת בבקשה לקצה העורפי. כותרות אחרות בבקשה לקצה העורפי מועברות ללא שינוי.
  • הערכים מקודדים באחוזים (RFC 3986) כשהם ממוקמים בבקשה לקצה העורפי, כך שערך שמכיל רווח או תו שמור מגיע לקצה העורפי בצורה המקודדת שלו. אפשר לפענח אותו שם אם צריך את המקור.
  • אם בפעולה ובנתיב שלה מוגדר פרמטר עם אותו שם ואותו ערך in, ההגדרה ברמת הפעולה חלה, כפי שנדרש במפרט של OpenAPI.
  • תנו שמות שונים לפרמטרים באותה פעולה, גם אם הם מצהירים על ערכי in שונים. ב-OpenAPI, פרמטר מזוהה לפי צמד של שם ומיקום, אבל כלי MCP מקבל ערך אחד לכל שם של ארגומנט. אם במפרט מוגדרים שני פרמטרים עם אותו שם וערכי in שונים, הלקוח מספק ערך אחד והערך הזה נשלח לשני המיקומים שהוגדרו בבקשה לקצה העורפי: פרמטר sessionId שהוגדר גם כ-in: cookie וגם כ-in: query מגיע בכותרת Cookie ובמחרוזת השאילתה. כדאי לבדוק את זה אם בקצה העורפי יש לוגיקה שתלויה במקור של הערך.
  • שמות הארגומנטים תלויי אותיות רישיות, כך ש-UserID ו-userid הם שני ארגומנטים שונים. בפרמטרים מסוג header, צריך לוודא שהשמות שונים לא רק באותיות רישיות: שמות של כותרות HTTP לא תלויים באותיות רישיות, ולכן שני פרמטרים של כותרות שהשמות שלהם שונים רק באותיות רישיות יפנו לאותה כותרת בבקשה לקצה העורפי, ורק אחד משני הערכים יישמר.

קובצי Cookie הם המקרה היחיד שבו הקישור יכול להסיר משהו מהבקשה, ולא רק להוסיף לה. בניגוד לכותרות HTTP אחרות, שכוללות צמדים נפרדים של שם/ערך שאפשר להגדיר כל אחד מהם בנפרד, כל קובצי ה-Cookie חולקים כותרת Cookie אחת. ‫Apigee לא ממזגת את קובצי ה-Cookie שאתם מקשרים עם קובצי ה-Cookie שהגיעו בבקשה של לקוח ה-MCP: כשקריאה מספקת ארגומנט כלשהו של קובץ Cookie, הכותרת Cookie מוחלפת כולה בקובצי ה-Cookie המקושרים בלבד.

לכן, אם קובץ Cookie שהגיע עם בקשת ה-HTTP של לקוח ה-MCP עצמו מגיע לקצה העורפי, זה תלוי בקריאה הספציפית לכלי:

  • אם הפעולה לא מצהירה על פרמטרים של cookie, הכותרת Cookie מועברת ל-backend ללא שינוי.
  • אם הפעולה מצהירה על פרמטרים של cookie אבל הקריאה לא מספקת אף אחד מהם, הכותרת Cookie מועברת שוב לקצה העורפי ללא שינוי.
  • ברגע שהקריאה מספקת לפחות ארגומנט אחד של קובץ Cookie, הכותרת Cookie מוחלפת בקובצי ה-Cookie המקושרים בלבד. כל קובץ Cookie שהגיע בבקשה של הלקוח ולא הוגדר כפרמטר cookie נמחק.

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

אבטחה

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

אימות

נקודות הקצה של MCP שמתארחות ב-Apigee תומכות ב-OAuth 2.1 וב-OpenID Connect (‏OIDC) לאימות. ככה רק סוכנים, לקוחות MCP ומשתמשי קצה עם זהויות מאומתות יכולים לגשת לנקודות הקצה של ה-MCP ולהפעיל את הכלים של ה-MCP. מטא-נתונים של משאבים מוגנים מאפשרים ללקוחות לגלות את שרתי ההרשאות של OAuth.

כללי מדיניות פרטניים של הרשאות

אתם יכולים להגביל את הגישה לכלי ה-MCP שלכם על סמך זהויות של לקוחות OAuth. לדוגמה, אתם יכולים להגדיר מדיניות בשרת ה-proxy של MCP Discovery, ולקבוע שרק סוכנים ייעודיים עם זהויות לקוח ידועות יכולים לגשת לכלי MCP של שירות תשלומים.

אחריות הלקוח על הפעלת כלים

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

ניראות וניתוח נתונים

בנקודות קצה (endpoints) שמתארחות ב-Apigee, אתם יכולים להשתמש ב-Apigee Analytics כדי לראות מידע מפורט על השימוש בכלים שלכם ב-MCP. ב-Analytics אפשר לפלח תנועה ספציפית ל-MCP מתנועת API רגילה ולראות מדדים ברמת הכלי הספציפי, כמו נפח הבקשות של tools/list (גילוי) לעומת tools/call (ביצוע). מדדי הביצועים גם עוזרים להבחין בין התקורה של שרת ה-proxy לבין זמן התגובה של היעד, וכך לאתר צווארי בקבוק בצורה יעילה יותר.

אמינות ופתרון בעיות

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

שימוש ב-MCP עם Apigee

אתם יכולים לחשוף את ממשקי ה-API הקיימים של Apigee ככלים של MCP ולהפוך אותם לנגישים דרך נקודות קצה של MCP. אפשר להגדיר את נקודות הקצה האלה ברמת המארח או ברמת קבוצת הסביבות. לדוגמה, אם לארגון שלכם ב-cymbal יש שמונה שמות מארחים (למשל, api.cymbal.com, ‏ partners.cymbal.com), וכל אחד מהם משויך לקבוצת סביבות אחרת, אתם יכולים לארח שרת MCP ייעודי לכל שם מארח.

נקודת קצה מנוהלת (ORG_NAME.mcp.apigee.internal) נפרסת באמצעות שרת proxy ייעודי של MCP Discovery בארגון Apigee, שבו שרתי ה-MCP זמינים.

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

לקוח/ה שם המארח ונתיב הבסיס של ה-MCP נקודת הקצה של שרת ה-MCP proxy ל-API סביבה או קבוצת סביבות
מצילה api.cymbal.com/mcp cymbal.mcp.apigee.internal
(פרויקט של דייר (tenant) בארגון cymbal)		 mcp-api-proxy1 prod / prod-env-group
api-internal.cymbal.com/mcp cymbal.mcp.apigee.internal
(פרויקט של דייר (tenant) בארגון cymbal)		 mcp-api-proxy2 internal / internal-env-group
api-service.cymbal.com/mcp cymbal.mcp.apigee.internal
(פרויקט של דייר (tenant) בארגון cymbal)		 mcp-api-proxy3 dev / dev-env-group

מגבלות

המגבלות הבאות חלות על MCP ב-Apigee:

  • מספר כלי ה-MCP בארגון ב-Apigee מוגבל ל-1,000.
  • יכול להיות שפריסת התשתית של MCP תהיה כפופה למגבלות קיבולת באזורים הבאים:
    • europe-central2
    • europe-southwest1
    • europe-west9
    • me-central2

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

  • ‫MCP ב-Apigee תומך בגרסאות הבאות של OpenAPI: ‏ 3.0.0, ‏ 3.0.1, ‏ 3.0.2, 3.0.3.
  • תובנות לגבי ממשקי API ב-Apigee API hub לא זמינות לממשקי API ולכלים של MCP שנפרסו בארגונים ב-Apigee שבהם מופעל VPC-SC.
  • קריאות GET בתגובות לשגיאות של MCP יחזירו שגיאת 405, כי שרת ה-MCP לא תומך כרגע בסטרימינג של אירועים שנשלחים מהשרת (SSE).
  • התובנות של Apigee API hub לגבי ממשקי API לא יציגו ממשקי API בסגנון MCP או תנועה למשאבי MCP עד ש-Apigee בגרסה 1-17-0-apigee-6 תושק באופן מלא בכל האזורים הזמינים.
  • אי אפשר לשנות את מאפיין הסגנון של ה-API ל-MCP במשאב API שיש לו פעולות API קיימות.

מגבלות ספציפיות ל-Apigee Hybrid

המגבלות הבאות חלות על MCP ב-Apigee hybrid:

  • הארגומנטים של הכלי שהוגדרו כ-in: header או כ-in: cookie נשלחים במחרוזת השאילתה. הניתוב לפי מיקום שמתואר בקטע מיקום הארגומנט של הכלי בבקשה לקצה העורפי עדיין לא זמין ב-Apigee Hybrid. עד שהתכונה תהיה זמינה, פרמטר שמצהיר על אחד מהמיקומים האלה יגיע לקצה העורפי כפרמטר של שאילתה, וזו ההתנהגות שהייתה לפני התכונה הזו. השורות in: query ו-in: path בטבלה הזו רלוונטיות ל-Apigee Hybrid כפי שהן כתובות.
  • מספר הכלים של MCP מוגבל לפי הגודל, ולא לפי מספר קבוע. בניגוד ל-Apigee (שמגביל את מספר כלי ה-MCP לכל ארגון), ב-Apigee Hybrid קיבולת הכלים מוגבלת על ידי ארבע מגבלות גודל: גודל קובץ המפרט של OpenAPI, גודל חבילת ה-proxy של MCP, גודל התגובה של tools/list לכל שם מארח ומספר שמות המארחים לכל קבוצת סביבות. ברוב המפרטים של OpenAPI, בדרך כלל אפשר להכניס 10,000 כלי MCP לכל ארגון במגבלת ברירת המחדל של גודל התגובה. הקיבולת בפועל משתנה בהתאם למבנה הספציפי של המפרט (היא מושפעת בעיקר ממספר הפרמטרים והמאפיינים של גוף הבקשה, וגם מאורך התיאור). סכמות התשובה לא נכללות במגבלה. כדי להעריך את הקיבולת של מפרטי OpenAPI ספציפיים ולראות את ארבע המגבלות הקשיחות ואת מצבי הכשל שלהן, קראו את המאמר הערכת הקיבולת של כלי MCP.
  • הפעלה או השבתה של MCP מפעילה גרסה איטרטיבית לקהל מצומצם (canary release) בשלבים של פודים של מעבד בקשות. כשמפעילים או משביתים את MCP, מפעיל Apigee מעדכן את מפרט ה-pod של מעבד הבקשות, והבקר של מעבד הבקשות ApigeeDeployment מריץ את השינוי באמצעות גרסה איטרטיבית לקהל מצומצם (canary release) בשלבים, ולא כהפעלה מחדש הדרגתית רגילה של Kubernetes. הגרסה מופעלת רק במעברים של הפעלה והשבתה, ולא בפעילות מתמשכת של פריסת MCP או בתנועת MCP במצב יציב. תזמנו את ההפעלה הראשונית ואת כל פעולות ההשבתה הבאות במהלך חלון זמן לתחזוקה מאושר.
  • הלקוח מנהל את גודל המשאבים של פוד ה-MCP. הפודים של MCP פועלים עם בקשות המשאבים והמגבלות שמוגדרות כברירות מחדל מובנות בתרשימי Helm של Apigee Hybrid. אם עומס העבודה דורש קיבולת גדולה יותר, צריך לשנות את המעבד (CPU) והזיכרון ב-overrides.yaml. overrides.yaml – השדות הזמינים.
  • מישור נתונים אחד של MCP לכל ארגון ב-Apigee, לכל אשכול. בגרסה 1.17.0, מפעיל Apigee מקצה מישור נתונים אחד של MCP לכל ארגון Apigee שמותקן באשכול. באשכול שמארח כמה ארגונים ב-Apigee פועל מישור נתונים אחד של MCP לכל ארגון. מישורי הנתונים הם עצמאיים ולא חולקים הגדרות.
  • צריך להפעיל את התכונה באופן אחיד בכל קבוצת הסביבות. מפעילים את MCP באופן אחיד בכל האשכולות שמשרתים את אותה קבוצת סביבות של Apigee. אם פרוטוקול MCP מופעל בחלק מהאשכולות ולא באחרים בתוך קבוצה, בקשות MCP שמופנות לאשכול שבו פרוטוקול MCP לא מופעל יקבלו תגובה 503 Service Unavailable.
  • ‫TLS חד-כיווני בין מעבד הבקשות לבין מישור הנתונים של MCP. בגרסה 1.17.0 נעשה שימוש ב-TLS חד-כיווני בין מעבד הבקשות לבין מישור הנתונים של MCP.
  • מישור הנתונים של MCP מסתמך על מעבד הבקשות כדי לזהות את מבצע הקריאה החוזרת. מישור הנתונים של MCP באשכול לא מאמת באופן עצמאי את מבצעי הקריאות ב-1.17.0, אלא מסתמך על כך שהבקשות שמגיעות אליו כבר אומתו על ידי שרת proxy של Apigee שפועל במעבד הבקשות. כל בקשת MCP שצריך לאמת חייבת להגיע דרך שרת proxy של Apigee MCP שאוכף מדיניות אימות (ראו ניהול הגישה לכלי MCP). לקוחות בסביבת ייצור צריכים להחיל אמצעי בקרה על תעבורת הנתונים הנכנסת (ingress) של האשכול, כדי שרק פודים של מעבד בקשות (תווית Kubernetes‏ app=apigee-runtime באותו מרחב שמות של Kubernetes שבו מותקן Apigee hybrid) יוכלו להגיע לשירות ה-MCP ב-TCP‏ 443. כדי לאכוף את ההגבלה הזו, צריך להשתמש במנוע המדיניות שנתמך בפלטפורמה (Kubernetes NetworkPolicy,‏ Cilium,‏ Calico,‏ Istio AuthorizationPolicy).

המאמרים הבאים