MCP Reference: geminicloudassist.googleapis.com

Ein Model Context Protocol (MCP)-Server fungiert als Proxy zwischen einem externen Dienst, der einem Large Language Model (LLM) oder einer KI-Anwendung Kontext, Daten oder Funktionen bereitstellt. MCP-Server verbinden KI-Anwendungen mit externen Systemen wie Datenbanken und Webdiensten und übersetzen deren Antworten in ein Format, das die KI-Anwendung versteht.

Server einrichten

Sie müssen MCP-Server aktivieren und die Authentifizierung einrichten, bevor Sie sie verwenden können. Weitere Informationen zur Verwendung von Remote-MCP-Servern von Google und Google Cloud finden Sie unter Google Cloud-MCP-Server – Übersicht.

Der Gemini Cloud Assist MCP-Server bietet automatisierte Unterstützung für die Google Cloud Platform und ermöglicht intelligente Fehlerbehebung, Kostenoptimierung, Infrastrukturdesign und ‑bereitstellung sowie Cloud-Vorgänge. Voraussetzungen:

  • Erforderliche APIs:
    • geminicloudassist.googleapis.com
    • designcenter.googleapis.com
    • apphub.googleapis.com
    • cloudasset.googleapis.com
    • appoptimize.googleapis.com
  • Empfohlene APIs (optional für die volle Funktionalität):
    • logging.googleapis.com
    • monitoring.googleapis.com
    • apptopology.googleapis.com
    • recommender.googleapis.com
  • Erforderliche Rollen:
    • roles/geminicloudassist.viewer (für schreibgeschützte Aufgaben)
    • roles/geminicloudassist.user (für die allgemeine Nutzung)
    • roles/geminicloudassist.admin (für Änderungen an den Administratoreinstellungen)

Serverendpunkte

Ein MCP-Dienstendpunkt ist die Netzwerkadresse und Kommunikationsschnittstelle (in der Regel eine URL) des MCP-Servers, über die eine KI-Anwendung (der Host für den MCP-Client) eine sichere, standardisierte Verbindung herstellt. Es ist der Ansprechpartner für das LLM, um Kontext anzufordern, ein Tool aufzurufen oder auf eine Ressource zuzugreifen. Google MCP-Endpunkte können global oder regional sein.

Der MCP-Server geminicloudassist.googleapis.com hat den folgenden MCP-Endpunkt:

  • https://geminicloudassist.googleapis.com/mcp

MCP-Tools

Ein MCP-Tool ist eine Funktion oder ausführbare Funktion, die ein MCP-Server einem LLM oder einer KI-Anwendung zur Ausführung einer Aktion in der realen Welt zur Verfügung stellt.

Der MCP-Server geminicloudassist.googleapis.com hat die folgenden Tools:

MCP-Tools
ask_cloud_assist

Die primäre Schnittstelle für Google Cloud Platform-Support. Mit diesem Tool können Sie mit dem GCA Root Agent interagieren, um allgemeine Fehlerbehebungen, Loganalysen oder allgemeine Cloud-Anfragen durchzuführen. Er fungiert als zentraler Orchestrierungs-Agent, der Nutzeranfragen an spezialisierte Sub-Agents weiterleitet oder sie direkt mit Tools für allgemeine Zwecke bearbeitet.

Funktionen:

  • Allgemeine Anfragen:Antworten auf allgemeine Fragen zu Google Cloud-Diensten, -Konzepten und -Dokumentation.
  • Estate-Abfragen:Ruft den aktuellen Ressourcenstatus und das Inventar ab (z.B. „List my active VMs“ (Liste meiner aktiven VMs), „Show me the config for this pod“ (Zeige mir die Konfiguration für diesen Pod)).
  • Direktiven:Führt bestimmte Direktiven mit geringer Komplexität oder Statusprüfungen aus.
  • Triage und Weiterleitung:Behandelt komplexe oder mehrdeutige Intentionen (z.B. „Etwas stimmt mit meiner App nicht“), um den Umfang des Problems zu ermitteln, bevor die Anfrage möglicherweise an spezialisierte Kundenservicemitarbeiter weitergeleitet wird.
  • Sichere Ausführung:Orchestriert mutative Aktionen (z.B. „Diese VM neu starten“, „Diesen Cluster skalieren“) mithilfe eines sicheren HITL-Workflows (Human-in-the-Loop). Sie prüft die Nutzereinwilligung, bevor gcloud-Befehle ausgeführt werden.

Nutzungsrichtlinien:

  • Standardauswahl:Wählen Sie dieses Tool aus, wenn die Intention des Nutzers allgemein, mehrdeutig, explorativ, rein informativ ist oder eine Planung beinhaltet.
  • Erste Sichtung:Verwenden Sie dieses Tool für die erste Meldung von Problemen, bei denen die spezifische Domain noch nicht klar ist.
  • Direkte Ausführung:Verwenden Sie dieses Tool, wenn der Nutzer eine bestimmte, beabsichtigte Änderung an seiner Umgebung anfordert (z.B. „Starte Instanz X neu“, „Skaliere diesen Cluster“, „Aktualisiere die Firewallregel“).
  • Ausschlüsse:
    • Wenn der Nutzer explizit darum bittet, Infrastruktur zu entwerfen, zu konzipieren oder bereitzustellen, verwenden Sie design_infra.
    • Wenn der Nutzer explizit nach einer detaillierten Ursachenanalyse, Fehlerbehebung oder Abhilfe für einen bekannten Fehler fragt, verwenden Sie investigate_issue.
    • Wenn der Nutzer ausdrücklich nach Kosten, Abrechnung oder inaktiven Ressourcen fragt, verwende optimize_costs.

Sitzungsverwaltung:

  • Dieses Tool gibt in seiner Ausgabe eine contextId zurück.
  • Wenn Sie eine Unterhaltung (mit mehreren Turns) fortsetzen möchten, MÜSSEN Sie contextId einfügen.
  • Lassen Sie contextId weg, um eine neue, unabhängige Aufgabe zu starten.
investigate_issue

Der Investigation Orchestrator-Agent ist der Haupt-Agent für Fehlerbehebung und Diagnose für Google Cloud. Es fungiert als spezialisiertes „SRE in a box“, das in der Lage ist, komplexe Infrastruktur, Anwendungscode und Observability-Daten zu analysieren, um Vorfälle zu beheben.

Hauptfunktionen und Architektur:

  • Erweiterte Argumentation und interaktive Untersuchungen:Hier werden ausgefeilte Planungsalgorithmen verwendet, um parallelisierte Hypothesenbewertungen durchzuführen. So können mehrere Fehlerszenarien gleichzeitig und nicht sequenziell geprüft werden.
  • Strategie für schnelle vs. detaillierte Untersuchung:
    • Express-Modus:Für schnelle Statistiken, die Erkennung von Log- und Messwertanomalien und Echtzeit-Statusprüfungen.
    • Recherchenmodus: Für komplexe Ursachenanalysen. Es nutzt Domain-Expertise, indem es über den Cloud Assist Planner-Agent in spezialisierte Datenbank- und Analyse-Agents eingebunden wird.
  • Diagnose-Runbooks:Vordefinierte Diagnose-Playbooks können automatisch ausgewählt und ausgeführt werden, um standardisierte Fehlerbehebungen durchzuführen.
  • Trace-basierte Topologie:Erstellt dynamische Architekturkarten, die aus echten Traffic-Traces abgeleitet werden, nicht nur aus statischer Konfiguration.
  • Source Code Insights:Analysiert die Anwendungslogik, um Ursachen im Code selbst zu finden (z.B. Verbindungspools, Abfragen).
  • KI-basierte Erklärungen:Bietet Erklärungen in einfacher Sprache für unklare Fehlerlogs und Anomalien bei Messwerten.

Wann Anfragen an diesen Agenten weitergeleitet werden:

  • Nutzeranfragen zur Ursachenanalyse oder Hilfe bei einem Ausfall/Absturz.
  • Der Nutzer bittet darum, Logs, Messwerte oder Traces auf Anomalien zu analysieren.
  • Der Nutzer muss Abhängigkeiten verstehen oder den Topologiegraphen analysieren.
  • Ein Nutzer fragt nach Problemen mit dem Quellcode, die zu Infrastrukturfehlern führen.
  • Der Nutzer möchte bestimmte Diagnosen oder Systemdiagnosen ausführen.

Detaillierte Funktionen und Kompetenzen:

  • Deep Research &Ursachenanalyse (RCA): Startet eine umfassende, mehrstufige Untersuchung mit erweitertem logischem Schlussfolgern und Planen. Es werden parallelisierte Hypothesenbewertungen ausgeführt, bei denen domänenspezifische Agents (Database, Analytics) verwendet werden, um die endgültigen Ursachen zu ermitteln. Verwenden Sie diese Option für komplexe, offene Probleme.

    • Beispiele: „Die Latenz meiner Anwendung ist auf 5 Sekunden gestiegen. Finde die Ursache.“ „Untersuche, warum der Chatter-Dienst während des Lastentests 503-Fehler ausgibt.“ „Warum sind die Pods in ClusterABC nicht planbar?“ Analysiere die Engpässe in meinem Bezahlvorgang. „Führe eine detaillierte Analyse des Konflikts durch Datenbanksperre durch.“
  • Diagnose-Runbooks und ‑Playbooks:Führt deterministische Diagnose-Runbooks und Standardverfahren (Standard Operating Procedures, SOPs) aus. Dieser Skill wird in den Cloud Assist Planner-Agent eingebunden, um validierte Prüfungen auf bekannte Probleme und häufige Fehlermodi auszuführen.

    • Beispiele: „Führe die Konnektivitätsdiagnose für den Frontend-Dienst aus.“ „Führen Sie das Standard-Runbook für Systemdiagnosen aus.“, „Check for known configuration issues using the diagnostic playbook.“ (Prüfen Sie mit dem Diagnose-Playbook auf bekannte Konfigurationsprobleme.) „Gibt es ein Runbook, um die Erreichbarkeit des Netzwerks zu prüfen?“
  • Express Diagnostics & Anomaly Detection (Schnelldiagnose und Anomalieerkennung): Führt schnelle „Quick Checks“ durch und erkennt Anomalien in Logs und Messwerten automatisch. So können Sie sofort Ausreißer, Spitzen oder Fehlermuster erkennen, ohne auf eine vollständige Untersuchung warten zu müssen.

    • Beispiele: „Detect any metric anomalies for the checkout-service.“ (Erkenne alle Messwertanomalien für den Checkout-Dienst.) „Show me the traffic level and latency for the chatter-frontend service.“ (Zeig mir das Verkehrsaufkommen und die Latenz für den Dienst „chatter-frontend“.) „Gibt es Ausreißer bei der CPU-Auslastung?“ „What are the top errors for the store-processing service right now?“ (Was sind derzeit die häufigsten Fehler beim Dienst zur Verarbeitung von Geschäften?) „Suche in den Logs nach aktuellen Fehlerhäufungen.“
  • KI-basierte Log- und Fehleranalyse:Hier wird KI verwendet, um komplexe Fehlerlogs, Stacktraces und Messwertmuster zu analysieren und zu interpretieren. Neben einer einfachen Erklärung leitet es die technische Bedeutung und die potenziellen Auswirkungen von Observability-Daten ab.

    • Beispiele: „Analysiere diesen Stacktrace und erkläre, warum der Absturz auftritt.“ „Erkläre den Fehler ‚Connection Reset‘ im Kontext hoher Last.“ „Interpretiere diesen unklaren Datenbankfehlercode.“ „Warum wird mir dieses bestimmte Fehlerlog immer wieder angezeigt?“
  • Trace-Based Topology Graph (auf Traces basierendes Topologiediagramm): Generiert ein dynamisches Topologiediagramm, das aus echten Anwendungstraces (OneGraph) abgeleitet wird. Es visualisiert und begründet tatsächliche Traffic-Pfade und ‑Abhängigkeiten und legt Latenz- und Fehlersignale auf die Diagrammknoten.

    • Beispiele: „Zeige mir die auf Traces basierende Topologie für den Zahlungsdienst.“ „Stelle den tatsächlichen Trafficfluss zwischen Mikrodiensten dar.“, „Stelle die Abhängigkeiten anhand der letzten Anfragetraces dar.“ „Erstelle ein Diagramm, das zeigt, wo die Latenz im Stack auftritt.“
  • Source Code Insights:Analysiert Anwendungsquellcode und Konfigurationsdateien (über DevConnect) eingehend. Es werden Infrastruktursymptome mit bestimmten Codezeilen verknüpft und Probleme wie fehlerhafte Abfragen, aggressive Zeitüberschreitungen oder Logikfehler identifiziert.

    • Beispiele: „Analysiere den Quellcode auf ineffiziente Datenbankabfragen.“ „Did a recent commit change the connection pool settings?“ (Hat sich durch einen kürzlich erfolgten Commit etwas an den Einstellungen für den Verbindungspool geändert?) „Prüfen Sie die Anwendungslogik auf mögliche Race Conditions.“, „Überprüfe die Konfigurationsdateien im Repository auf Fehler.“
  • Ursachenanalyse und ‑behebung:Die Ergebnisse der Untersuchung werden zusammengefasst, um die endgültige Ursache zu ermitteln. Anschließend wird ein entsprechender umsetzbarer Plan zur Behebung des Problems erstellt, z. B. CLI-Befehle oder Code-Patches.

    • Beispiele: „Finde die Ursache für das Datenbank-Timeout und erstelle einen Plan, um das Problem zu beheben.“ „Finde heraus, warum die Instanz abstürzt, und erstelle einen gcloud-Befehl, um die Größe der Instanz zu ändern.“ „Ermittle die Ursache der Verbindungsfehler und schlage Codeänderungen vor.“ „Welche Lösung wird für diesen Fehler empfohlen?“
  • Interaktive Fehlerbehebung in mehreren Schritten:Unterstützt zustandsorientierte Interaktivität in mehreren Schritten. Der Nutzer kann die Untersuchung steuern, Rückfragen stellen, den Umfang eingrenzen und die Ergebnisse in einer Art Dialog durchgehen.

    • Beispiele: „Das hat das Problem nicht behoben. Was sollen wir als Nächstes überprüfen?“ „Kannst du dir stattdessen die Datenbanklogs ansehen?“, „Let's focus on the frontend service now.“ (Konzentrieren wir uns jetzt auf den Frontend-Dienst.) „Go deeper into that second hypothesis.“ (Gehe genauer auf die zweite Hypothese ein.)

Sitzungsverwaltung:

  • Dieses Tool gibt in seiner Ausgabe eine contextId zurück.
  • Wenn Sie eine Unterhaltung (mit mehreren Turns) fortsetzen möchten, MÜSSEN Sie contextId einfügen.
  • Lassen Sie contextId weg, um eine neue, unabhängige Aufgabe zu starten.
optimize_costs

Der Optimize-Agent hilft Nutzern, ihre Google Cloud-Kosten zu analysieren, zu verfolgen und zu optimieren. Es bietet detaillierte Aufschlüsselungen der Ausgaben und identifiziert Möglichkeiten zur Kosteneffizienz, indem es inaktive oder unterausgelastete Ressourcen findet.

Hauptfunktionen:

  • Kostenanalyse:Hier werden Ausgaben nach Projekt, Anwendung, Produkt, Ressource oder Standort aufgeschlüsselt, um Fragen wie „Wie viel habe ich ausgegeben?“ zu beantworten.
  • Wichtigste Kostentreiber:Hier werden die teuersten Ressourcen oder Dienste aufgeführt, die die Rechnung beeinflussen.
  • Kostentrends:Hier wird analysiert, wie sich die Kosten im Laufe der Zeit verändert haben (z.B. monatliche Steigerungen).
  • Effizienz und Anpassung der Größe: Identifiziert inaktive, überdimensionierte oder unterausgelastete Ressourcen speziell, um Möglichkeiten zur Kostensenkung aufzuzeigen.

Wichtige Einschränkungen für das Routing:

  • LEITEN SIE Fragen zu „unterausgelasteten“ oder „inaktiven“ Ressourcen weiter, wenn es im Kontext darum geht, Geld zu sparen (z.B. „Zeige mir die Kosten meiner am meisten unterausgelasteten Ressourcen“).
  • Leiten Sie allgemeine Fragen zur Nutzung, die nicht mit Kosten zusammenhängen (z.B. „Wie viele vCPUs hat Ressource X verwendet?“), NICHT weiter.
  • Dieser KI-Agent sagt keine zukünftigen Kosten voraus.
  • Dieser Agent ergreift keine Maßnahmen zur Kostensenkung (schreibgeschützte Analyse).

Wann Anfragen an diesen Agenten weitergeleitet werden:

  • Der Nutzer fragt: „Wie viel habe ich letzten Monat für die Compute Engine ausgegeben?“
  • Der Nutzer fragt: „Welche Ressourcen sind am teuersten?“
  • Der Nutzer fragt: „Welche Ressourcen sind inaktiv und kosten mich Geld?“
  • Der Nutzer fragt: „Warum ist meine Rechnung im Vergleich zum letzten Monat höher?“

Sitzungsverwaltung:

  • Dieses Tool gibt in seiner Ausgabe eine contextId zurück.
  • Wenn Sie eine Unterhaltung (mit mehreren Turns) fortsetzen möchten, MÜSSEN Sie contextId einfügen.
  • Lassen Sie contextId weg, um eine neue, unabhängige Aufgabe zu starten.
invoke_operation

Ruft den Operations-Agent für Cloud Operations-Aufgaben auf.

Der Operations-Agent kann verschiedene Cloud-Vorgänge, Untersuchungen und Verwaltungsaufgaben ausführen.

user_query ist ein JSON-Objekt in Stringform, das den genauen Vorgang definiert. Das JSON-Objekt MUSS einen operation_type-Schlüssel mit einem der beiden Werte GKE_APPLY oder GKE_PATCH enthalten. Geben Sie basierend auf dem operation_type genau eines der entsprechenden Objekte an:

  • Wenn GKE_APPLY:Geben Sie ein gke_apply-Objekt mit Folgendem an:

    • target_cluster (String, erforderlich): Vollständiger Ressourcenname, z.B. projects/{p}/locations/{l}/clusters/{c}.
    • yaml_manifest (String, erforderlich): Der Roh-YAML-String. Achten Sie darauf, dass Zeilenumbrüche mit Escape-Sequenzen versehen werden.
    • namespace (String, optional): Überschreibt den Namespace.
    • force_conflicts (boolesch, optional): Wenn „true“, wird die Konfliktlösung beim Anwenden erzwungen. Dies entspricht „kubectl apply --serverseitig --force-conflicts“. Damit wird sichergestellt, dass der beabsichtigte Status angewendet wird, auch wenn ein anderer Feldmanager derzeit die Zielfelder besitzt.
  • Wenn GKE_PATCH:Geben Sie ein gke_patch-Objekt mit Folgendem an:

    • target_cluster (String, erforderlich): Vollständiger Ressourcenname.
    • resource_type (String, erforderlich): z.B. deployments.
    • resource_name (String, erforderlich): Name der K8s-Ressource.
    • patch_json (String, erforderlich): Der JSON-Patch-String. Korrekt maskiert.
    • namespace (String, optional): Der Namespace der Ressource.

Beispiele:

  • Beispiel 1 (GKE_APPLY):

    {
      "operation_type": "GKE_APPLY",
      "gke_apply": {
        "target_cluster": "projects/my-company/locations/us-central1/clusters/my-cluster",
        "yaml_manifest": "apiVersion: v1 | kind: ConfigMap | metadata: name: my-config | data: key: value",
        "namespace": "default"
      }
    }
    
  • Beispiel 2 (GKE_PATCH):

    {
      "operation_type": "GKE_PATCH",
      "gke_patch": {
        "target_cluster": "projects/my-company/locations/us-central1/clusters/my-cluster",
        "resource_type": "deployments",
        "resource_name": "my-app",
        "patch_json": "{'spec': {'replicas': 5}}",
        "namespace": "default"
      }
    }
    
  • Beispiel 3 (GKE_APPLY mit force_conflicts zum Überschreiben vorhandener Feldmanager):

    {
      "operation_type": "GKE_APPLY",
      "gke_apply": {
        "target_cluster": "projects/my-company/locations/us-central1/clusters/my-cluster",
        "yaml_manifest": "apiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: web-backend\nspec:\n  replicas: 5\n  template:\n    spec:\n      containers:\n      - name: app\n        image: my-repo/web-backend:v2.0.1",
        "namespace": "default",
        "force_conflicts": true
      }
    }
    

Argumente:

  • project: Das Google Cloud-Projekt im Format projects/{project_id}.
  • userQuery: Ein in einen String umgewandeltes JSON-Objekt, das den genauen Vorgang definiert.
  • contextId: Kontext-ID aus der vorherigen Antwort des Agenten.

Sitzungsverwaltung:

  • Dieses Tool gibt in seiner Ausgabe eine contextId zurück.
  • Wenn Sie eine Unterhaltung (Mehrfachabfrage) fortsetzen möchten, MÜSSEN Sie contextId in die nächste Anfrage einfügen.
  • Lassen Sie contextId weg, um eine neue, unabhängige Aufgabe zu starten.
design_infra

Design Agent unterstützt Nutzer bei der Verwaltung des gesamten Lebenszyklus der Anwendungsinfrastruktur in der Google Cloud Platform. Es bietet eine Reihe von spezialisierten untergeordneten Agents, die sich um verschiedene Aspekte des Infrastrukturdesigns und der Infrastrukturgenerierung kümmern.

Unterstützte Befehle und erforderliche Informationen:

  • manage_app_design: Infrastruktur in der Google Cloud Platform entwerfen und planen, die für die Designabsichten der Anwendungsinfrastruktur erforderlich ist.

    • Beschreibung:
      • Mit diesem Befehl kann die Google Cloud-Architektur generiert, das Mermaid-Diagramm gerendert und der Terraform-Code generiert werden.
      • Dieser Befehl kann auch Infrastruktur als Code (Infrastructure as Code, IaC) akzeptieren, wenn ein Design iterativ bearbeitet wird (z.B. wenn Terraform-Code in eine vorhandene Anwendungsvorlage importiert wird).
      • Mit diesem Befehl kann auch der Terraform-Code für eine vorhandene Anwendungsvorlage oder ein App-Design abgerufen werden.
    • Design-Sitzung:
      • Jede Design-Sitzung ist mit einer App Design Center (ADC)-Anwendungsvorlage verknüpft, die durch applicationTemplateURI identifiziert wird.
      • Der Agent verwaltet den Status von Anwendungsdesigns und zugehörigen Terraform-Artefakten.
      • Wenn Sie ein Design iterieren möchten, MÜSSEN Sie die Anwendungs-Vorlagen-ID im Format projects/{projectid}/locations/{region}/spaces/{spaceid}/applicationTemplates/{templateid} angeben.
      • Wenn Sie ein neues Design erstellen möchten, geben Sie die ID der Anwendungsvorlage nicht an.
    • Nutzeranfrage:Hier sollten die allgemeine Anwendungsarchitektur, die Anforderungen und die Einschränkungen beschrieben werden. Sie können Umgebungsvariablen, Ports usw. angeben oder eine bestimmte Anfrage für den IaC-Import oder den Terraform-Codeabruf stellen.
      • Beispiel: „Entwirf eine dreistufige Webanwendung mit einem Load Balancer, einem Frontend, einem Backend und einer Datenbank.“
      • Beispiel: „Importiere das Anwendungsdesign aus IaC. Hier sind meine Terraform-Dateien: - main.tf terraform\n<main.tf file content>\n, - variables.tf terraform\n<variables file content>\n …“
      • Beispiel: „Zeige mir den Terraform-Code für die Anwendungsvorlage projects/.../applicationTemplates/test-app.“
    • Wichtige Richtlinien
      • Design-Iteration: Wenn der Nutzer ein vorhandenes Design ändern oder aktualisieren möchte, MUSS er die application_template_id in der Anfrage angeben.
        • Beispiel: „Aktualisiere das Design projects/{projectid}/locations/{region}/spaces/{spaceid}/applicationTemplates/{templateid}: Füge eine Cloud SQL-Instanz hinzu.“
      • Die project-Eingabe muss als projects/{projectid} formatiert sein.
    • Ziel:Erstellt ein umfassendes Design mit App Design Center-Konzepten (ADC) oder importiert ein Anwendungsdesign aus IaC.
    • Rückgabe: Ein XML-formatierter String mit einem oder mehreren der folgenden Elemente: Message, serializedDesign, applicationTemplateURI, terraformCode, mermaidCode und Instructions.
  • generate_terraform: Generieren Sie Terraform-Konfigurationen für eine einzelne Ressource.

    • Nutzeranfrage:Eine spezifische Anfrage für Terraform-Code.
      • Beispiel: „Generate Terraform for a GKE cluster with a spot node pool.“ (Generiere Terraform für einen GKE-Cluster mit einem Spot-Knotenpool.)
    • Hinweis: Wenn ein Nutzer Terraform für eine ADC-Anwendungsvorlage generieren möchte, MUSS er stattdessen manage_app_design verwenden.
      • Beispiel: „Generate Terraform for application template tmpl_12345“ (Generiere Terraform für die Anwendungsvorlage tmpl_12345) sollte an manage_app_design weitergeleitet werden.
    • Ziel:Es wird gültiger, bereitstellbarer Terraform-HCL-Code generiert.
  • generate_gcloud: gcloud-Befehle generieren.

    • Nutzeranfrage:Eine Anfrage zum Ausführen einer Aktion mit der Google Cloud CLI.
      • Beispiel: „Gib mir den gcloud-Befehl zum Erstellen eines Pub/Sub-Themas.“
    • Ziel:Generiert eine Sequenz ausführbarer gcloud-Befehle.
  • generate_bigquery: BigQuery-Befehle generieren.

    • Nutzeranfrage:Eine Anfrage für BigQuery-Befehle.
      • Beispiel: „Gib mir den bq-Befehl zum Erstellen eines Datasets.“
    • Ziel:Generiert eine Sequenz ausführbarer bq-Befehle.
  • generate_kubernetes_yaml: Kubernetes-YAML generieren.

    • Nutzeranfrage:Eine Anfrage für Kubernetes-Manifeste.
      • Beispiel: „Erstelle ein Kubernetes-Deployment für Nginx mit 3 Replikaten.“
    • Ziel:Erstellt gültige Kubernetes-YAML-Manifeste.
  • debug_deployment: Debugging von Bereitstellungsfehlern in ADC-Anwendungen.

    • Nutzeranfrage:Eine Anfrage zur Fehlerbehebung bei einem Bereitstellungsfehler in einer ADC-Anwendung. Sie muss eine Hilfsphrase wie „Hilf mir, diese Anwendung zu debuggen“ und nur den application_uri und keine anderen Informationen enthalten.
      • Beispiel: „Help me debug this application - projects/test-project/locations/us-central1/spaces/test-space/applicationTemplates/test-app“
    • Ziel:Bereitstellungsprobleme diagnostizieren und Anweisungen zur Behebung des Problems zurückgeben.
    • Nachfassaktionen:
      • Wenn die Ausgabe gcloud-Befehle enthält, folgen Sie der Anleitung und führen Sie den gcloud-Befehl aus, um das Problem zu beheben.
      • Wenn in der Ausgabe eine Änderung des Infrastrukturdesigns beschrieben wird, rufen Sie das Tool manage_app_design auf, um die empfohlenen Änderungen an der Infrastruktur vorzunehmen.

Verwendung:

Um dieses Tool zu verwenden, muss der Aufrufer das command-Argument für den gewünschten Sub-Agenten angeben und user_query mit dem spezifischen Intent bereitstellen.

Spezifikationen für MCP-Tools abrufen

Wenn Sie die MCP-Tool-Spezifikationen für alle Tools auf einem MCP-Server abrufen möchten, verwenden Sie die Methode tools/list. Im folgenden Beispiel wird gezeigt, wie Sie mit curl alle Tools und ihre Spezifikationen auflisten, die derzeit auf dem MCP-Server verfügbar sind.

Curl-Anfrage
curl --location 'https://geminicloudassist.googleapis.com/mcp' \
--header 'content-type: application/json' \
--header 'accept: application/json, text/event-stream' \
--data '{
    "method": "tools/list",
    "jsonrpc": "2.0",
    "id": 1
}'