שימוש בשרת MCP מרוחק של App Topology

במאמר הזה מוסבר איך משתמשים בשרת Model Context Protocol‏ (MCP) מרוחק של App Topology כדי להתחבר לאפליקציות מבוססות-AI, כולל Antigravity, ‏ ChatGPT, ‏ Claude ואפליקציות בהתאמה אישית שאתם מפתחים. בעזרת App Topology אתם יכולים לקשר בין נתונים של ניראות (observability), DevOps ואבטחה כדי להבין את מצב התאימות ומצב האבטחה של המשאבים הסוכנים שלכם ולפתור בעיות. שרת ה-MCP המרוחק של App Topology מופעל כשמפעילים את App Topology API.

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

מה ההבדל בין שרתי MCP מקומיים לשרתי MCP מרוחקים?

שרתי MCP מקומיים
בדרך כלל פועלים במחשב המקומי ומשתמשים בזרמי הקלט והפלט הרגילים (stdio) כדי לתקשר בין שירותים באותו מכשיר.
שרתי MCP מרוחקים
פועלים בתשתית של השירות ומציעים נקודת קצה (endpoint) מסוג HTTP לאפליקציות AI, כדי לאפשר תקשורת בין לקוח ה-MCP של ה-AI לבין שרת ה-MCP. מידע נוסף על ארכיטקטורת MCP

ליבה ללא שמירת מצב

בגרסת MCP‏ 2026-07-28, פרוטוקול MCP משתנה מפרוטוקול דו-כיווני עם שמירת מצב (stateful) לפרוטוקול ללא שמירת מצב (stateless). כל בקשת MCP מתארת את עצמה ואפשר לנתב אותה באמצעות כותרות. אין צורך בלחיצת היד של initialize/initialized או ב-Mcp-Session-Id כי כל בקשה כוללת את כל המידע הנדרש בכותרות HTTP או בפרמטר _meta. שרתי MCP יכולים לבקש מידע נוסף שנדרש לכלי באמצעות בקשות הלוך ושוב (MRTR).

כדי לנתב ולעבד בקשות בלי לנתח את גוף הבקשה, נדרשות כמה כותרות MCP, כולל:

למידע נוסף על הארכיטקטורה של MCP, קראו את המפרט של MCP בגרסה 2026-07-28 ואת השינויים העיקריים.

שרתי MCP של Google ושרתי MCP מרוחקים של Google Cloud

לשרתי MCP של Google ושל Google Cloud יש את התכונות והיתרונות הבאים:

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

במאמר סקירה כללית על שרתי Google Cloud MCP מוסבר על שרתי MCP אחרים ועל אמצעי הבקרה לאבטחה ולמשילות שזמינים לשרתי Google Cloud MCP.

לפני שמתחילים

הגדרת App Topology

התפקידים הנדרשים

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

תפקידים לשרת ה-MCP

כדי לקבל את ההרשאות שדרושות לשימוש בשרת MCP של App Topology, אתם צריכים לבקש מהאדמין לתת לכם את התפקידים הבאים ב-IAM:

  • להפעיל כלים של MCP: משתמש בכלי MCP (roles/mcp.toolUser) בפרויקטים שבהם רוצים להשתמש ב-App Topology
  • להריץ שאילתות: צפייה ב-App Topology (roles/apptopology.viewer) בפרויקטים שבהם רוצים להשתמש ב-App Topology

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

התפקידים המוגדרים מראש האלה כוללים את ההרשאות שנדרשות כדי להשתמש בשרת ה-MCP של App Topology. כדי לראות בדיוק אילו הרשאות נדרשות, אפשר להרחיב את הקטע ההרשאות הנדרשות:

ההרשאות הנדרשות

כדי להשתמש בשרת MCP של App Topology, נדרשות ההרשאות הבאות:

  • להפעיל כלי MCP: mcp.tools.call
  • קבלת דומיינים:
    • apptopology.domains.get
    • apptopology.domains.list
  • קבלת סכימות: apptopology.schemas.get
  • קבלת נתוני המשאבים שנמצאו: apptopology.discoveredResourcesTopologies.generate
  • קבלת נתונים של דומיין DevOps: apptopology.devOpsDomainTopologies.generate
  • קבלת נתונים של דומיין אבטחה: apptopology.securityDomainTopologies.generate
  • קבלת נתוני דומיין SRE (כל הנתונים הנתמכים): apptopology.sreDomainTopologies.generate

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

אימות והרשאה

שרת ה-MCP המרוחק של App Topology משתמש בפרוטוקול OAuth 2.0 עם ניהול זהויות והרשאות גישה (IAM) לאימות ולהרשאה. כל Google Cloud הזהויות נתמכות לאימות בשרתי MCP.

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

שרת ה-MCP של App Topology דורש חשבון משתמש לצורך בקרת IAM, ולא מקבל מפתחות API לצורך אימות.

היקפי ההרשאות של OAuth ב-App Topology MCP

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

ל-App Topology יש את היקפי ההרשאות הבאים של OAuth לכלי MCP:

URI של היקף ההרשאות ל-CLI של gcloud תיאור
https://www.googleapis.com/auth/apptopology.read-only מאפשר גישה לקריאת נתונים.

יכול להיות שיידרשו היקפי הרשאות נוספים במשאבים שאליהם ניגשים במהלך קריאה לפונקציה. כדי להציג רשימה של היקפי הרשאות שנדרשים ל-App Topology, ראו App Topology API.

הגדרת לקוח MCP לשימוש בשרת App Topology MCP

אפליקציות וסוכני AI, כמו Claude או Antigravity, יכולים ליצור מופע של לקוח MCP שמתחבר לשרת MCP יחיד. לאפליקציית AI יכולים להיות כמה לקוחות שמתחברים לשרתי MCP שונים. אם האפליקציה שלכם לא מופיעה בהנחיות הספציפיות ללקוח, תוכלו להשתמש במידע הבא כדי להתחבר מרוב האפליקציות.

באפליקציית ה-AI, מחפשים דרך להוסיף שרת MCP מרוחק או להתחבר אליו. בשרת ה-MCP של App Topology, מזינים את הפרטים הבאים לפי הצורך:

  • ‫Server name: App Topology שרת MCP
  • כתובת ה-URL של השרת או נקודת הקצה (endpoint): https://apptopology.googleapis.com/mcp
  • תעבורה: HTTP שניתן להעביר בסטרימינג
  • פרטי אימות: בהתאם לשיטת האימות שאתם רוצים להשתמש בה, אתם יכולים להזין את פרטי הכניסה, את מזהה הלקוח והסוד של OAuth או את פרטי הכניסה והזהות של הנציג. Google Cloud מידע נוסף על אימות זמין במאמר אימות בשרתי MCP.
  • ‫OAuth scope: https://www.googleapis.com/auth/apptopology.read-only. מידע נוסף על היקפי ההרשאות של OAuth 2.0 מופיע במאמר סקירה כללית על היקפי ההרשאות של OAuth.

‫URI של הפניה לכתובת אחרת

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

בקטע הנחיות ספציפיות ללקוח מוסבר איך להגדיר את שרת ה-MCP ולהתחבר אליו באפליקציות ספציפיות.

למידע כללי נוסף, אפשר לעיין במקורות המידע הבאים:

באילו כלים אפשר להשתמש

בחומר העזר בנושא App Topology MCP מפורטים כלי ה-MCP שזמינים בשרת App Topology MCP והתיאורים שלהם.

כלים לרשימות

משתמשים ב-MCP inspector כדי להציג רשימה של כלים, או שולחים בקשת HTTP מסוג tools/list ישירות לשרת ה-MCP המרוחק של App Topology. השיטה tools/list לא דורשת אימות.

curl -X POST https://apptopology.googleapis.com/TOOLSET_ENDPOINT \
    -H 'Content-Type: application/json' \
    -H 'Accept: application/json' \
    -H 'MCP-Protocol-Version: MCP_PROTOCOL_VERSION' \
    -H 'Mcp-Method: tools/list' \
    -d '{
      "jsonrpc": "2.0",
      "id": 1,
      "method": "tools/list",
      "params": {
        "_meta": {
          "io.modelcontextprotocol/protocolVersion": "MCP_PROTOCOL_VERSION",
          "io.modelcontextprotocol/clientCapabilities": {
            "extensions": {
              "io.modelcontextprotocol/ui": {
                "mimeTypes": ["text/html;profile=mcp-app"]
              }
            }
          }
        }
      }
    }'

מחליפים את מה שכתוב בשדות הבאים:

  • ‫TOOLSET_ENDPOINT: החלק שנותר בנקודת הקצה של ה-MCP אחרי שם השירות. ב-App Topology, זה mcp.
  • ‫MCP_PROTOCOL_VERSION: גרסת פרוטוקול ה-MCP. לדוגמה, 2026-07-28.

שימוש בכלים של App Topology

כלי ה-MCP של App Topology מיועדים לשימוש ברצף על ידי סוכני AI:

  1. הכלי list_domains מציג את הדומיינים שאפשר לשלוח אליהם שאילתות בפרויקט שצוין. הדומיין SRE כולל את כל נתוני המשאבים שנתמכים ב-App Topology.

  2. הכלים get_schema ו-explore_schema מאפשרים לנציג לקבל את הצמתים, הקצוות והמאפיינים שלהם שנתמכים בדומיין מסוים. כדי שהסוכן יוכל ליצור שאילתה תקינה באמצעות הכלי generate_discovered_resources_topology, הוא צריך לקבל את הסכימה של ההקשר.

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

    במאמר מידע על שאילתות מוסבר על המבנה והמגבלות של השאילתות.

תרחישים לדוגמה

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

  • קבלת תנועה לאפליקציה ב-App Hub: "הצג את כל השירותים ועומסי העבודה ששולחים או מקבלים תנועה משירותים ועומסי עבודה אחרים בפרויקט PROJECT_ID".
  • הצגת תעבורת הנתונים של הסוכנים: "Show me all agents that send or receive traffic from other agents or שרתי MCP in project PROJECT_ID"
  • הצגת רשימה של חשבונות שירות שיכולים להתחזות לחשבון שירות עם הרשאות נרחבות: "הצג לי חשבונות שירות שיש להם תפקיד בעלים/עריכה/צפייה בפרויקט PROJECT_ID, שחשבון שירות עם מפתח יכול להתחזות אליהם".
  • הצגת רשימה של נקודות חולשה בפריסת Kubernetes: "הצג לי נקודות חולשה בפריסות Kubernetes עם מזהה CVE‏ CVE-ID בפרויקט PROJECT_ID".
  • אימות המקור על ידי הצגת פריטי מידע שנוצרו בתהליך הפיתוח (Artifact) עם רמת SLSA ספציפית: "הצג לי את כל עומסי העבודה והשירותים שמשתמשים בפריט מידע שנוצר בתהליך הפיתוח ברמת SLSA‏ SLSA_LEVEL בפרויקט PROJECT_ID".

הגדרות אופציונליות של אבטחה ובטיחות

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

מידע נוסף על אבטחה ופיקוח ב-MCP זמין במאמר אבטחה ובטיחות ב-AI.

שימוש ב-Model Armor

‫Model Armor הוא שירות שלGoogle Cloud שנועד לשפר את האבטחה והבטיחות של אפליקציות ה-AI. הוא פועל באופן יזום כדי לסנן הנחיות ותשובות של מודלי LLM, להגן מפני סיכונים שונים ולתמוך בשיטות לפיתוח אחראי של AI. לא משנה אם אתם פורסים את ה-AI בסביבת הענן שלכם או אצל ספקי שירותי ענן חיצוניים, אתם יכולים להשתמש ב-Model Armor כדי למנוע קלט זדוני, לאמת את בטיחות התוכן, להגן על מידע אישי רגיש, לשמור על תאימות ולאכוף את מדיניות הבטיחות והאבטחה של ה-AI באופן עקבי בכל סביבת ה-AI שלכם.

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

ניתוב בקשות של MCP ל-Model Armor

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

הפעלת Model Armor

כדי להשתמש ב-Model Armor, צריך להפעיל את ממשקי ה-API של Model Armor.

המסוף

  1. מפעילים את Model Armor API, אם הוא עדיין לא מופעל.

    התפקידים שנדרשים כדי להפעיל ממשקי API

    כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

    להפעלת ה-API

  2. בוחרים את הפרויקט שבו רוצים להפעיל את Model Armor.

gcloud

לפני שמתחילים, מבצעים את השלבים הבאים באמצעות Google Cloud CLI עם Model Armor API:

  1. מפעילים את Cloud Shell במסוף Google Cloud .

    הפעלת Cloud Shell

    בחלק התחתון של מסוף Google Cloud יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

  2. מריצים את הפקודה הבאה כדי להגדיר את נקודת הקצה ל-API של שירות Model Armor.

    gcloud config set api_endpoint_overrides/modelarmor "https://modelarmor.LOCATION.rep.googleapis.com/"

    מחליפים את LOCATION באזור שבו רוצים להשתמש ב-Model Armor.

הגדרת הגנה לשרתי MCP של Google ו Google Cloud לשרתי MCP מרוחקים

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

מגדירים את ההגנה המוגברת על המודל עם הסרת תוכן זדוני או רגיש ב-MCP. מידע נוסף זמין במאמר הגדרת רמות הסינון של Model Armor.

דוגמה לפקודה:

gcloud model-armor floorsettings update \
--full-uri='projects/PROJECT_ID/locations/global/floorSetting' \
--enable-floor-setting-enforcement=TRUE \
--add-integrated-services=GOOGLE_MCP_SERVER \
--google-mcp-server-enforcement-type=INSPECT_AND_BLOCK \
--enable-google-mcp-server-cloud-logging \
--malicious-uri-filter-settings-enforcement=ENABLED \
--add-rai-settings-filters='[{"confidenceLevel": "MEDIUM_AND_ABOVE", "filterType": "DANGEROUS"}]'

מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud .

שימו לב להגדרות הבאות:

  • ‫INSPECT_AND_BLOCK: סוג האכיפה שבודק את התוכן בשרת MCP של Google וחוסם הנחיות ותשובות שתואמות למסננים.
  • ‫ENABLED: ההגדרה שמפעילה סינון או אכיפה.
  • ‫MEDIUM_AND_ABOVE: רמת הסמך של הגדרות הסינון של Responsible AI - Dangerous. אפשר לשנות את ההגדרה הזו, אבל ערכים נמוכים יותר עלולים לגרום ליותר תוצאות חיוביות כוזבות. מידע נוסף מופיע במאמר רמות הסמך של Model Armor.

השבתת הסריקה של תנועת MCP באמצעות Model Armor

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

gcloud model-armor floorsettings update \
  --full-uri='projects/PROJECT_ID/locations/global/floorSetting' \
  --remove-integrated-services=GOOGLE_MCP_SERVER

מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud . התכונה "הגנה מוגברת על המודל" לא מחילה באופן אוטומטי את הכללים שמוגדרים בהגדרות המינימום של הפרויקט הזה על תנועה בשרת MCP של Google.

הגדרות הסף וההגדרות הכלליות של Model Armor יכולות להשפיע על יותר מאשר רק MCP. מכיוון שהגנה מוגברת על המודל משתלבת עם שירותים כמו Vertex AI, כל שינוי שתבצעו בהגדרות של רמות הסינון יכול להשפיע על סריקת התנועה ועל התנהגויות הבטיחות בכל השירותים המשולבים, ולא רק ב-MCP.

איך שולטים בשימוש ב-MCP באמצעות כללי מדיניות הדחייה של IAM

כללי מדיניות הדחייה וכללי מדיניות ההרשאה של ניהול זהויות והרשאות גישה (IAM) עוזרים לכם לאבטח את Google Cloud ואת שרתי Google MCP.

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

  • חשבון המשתמש.
  • מאפייני הכלי, כמו המאפיין "לקריאה בלבד".
  • שם השירות או שם הכלי.
  • מזהה הלקוח ב-OAuth של האפליקציה.

מידע נוסף זמין במאמר שליטה בשימוש ב-MCP באמצעות ניהול זהויות והרשאות גישה.

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