Wie wird Google Antigravity MCP bereitgestellt? 2026 Berechtigungskonfiguration und Abnahme für Cloud-Macs

Der Agent startet, aber der erste MCP-Aufruf endet mit „unauthorized“, einer leeren Werkzeugliste oder einem nicht erreichbaren Remote-Server.

Die schnellste Lösung: Google Antigravity MCP zunächst in einer isolierten Cloud-Mac-Umgebung mit einer eindeutig erreichbaren Remote-Adresse, genau einem erlaubten Read-only-Tool und einer manuellen Bestätigung für Schreib- und Kommandoaktionen bereitstellen.

Zeitplan für die Umsetzung: Vor dem Start werden Netzwerk, Zugangsdaten und Arbeitsverzeichnis geprüft; danach folgen die minimale MCP-Registrierung, ein schrittweiser Aufruf-Test, die Erweiterung der Rechte und erst anschließend die Team-Abnahme. Für diese Woche empfiehlt sich, keinen globalen MCP-Platzhalter zu aktivieren, sondern einen einzelnen Server mit einer einzelnen Funktion zu verifizieren.

Diese Anleitung richtet sich an Entwickler, die Google Antigravity aus einer lokalen Umgebung auf einen Cloud-Mac verlagern möchten. Auch technische Verantwortliche, die MCP-Server, Zugangsdaten und Agent-Rechte für ein Team standardisieren müssen, erhalten hier eine prüfbare Abnahmestruktur. Wer zwischen einem lokalen Mac und einer entfernten Entwicklungsumgebung abwägt, kann anhand der Kontroll- und Wartungsanforderungen entscheiden, ob ein gemieteter Mac sinnvoll ist.

Vor dem Start: Ausführungsgrenze und MCP-Typ festlegen

Google Antigravity, der Gemini API Agent und ein MCP-Server erfüllen unterschiedliche Aufgaben. Antigravity steuert den Agent-Arbeitsablauf; der Agent entscheidet anhand seiner Instruktionen, welches Werkzeug benötigt wird; MCP stellt die standardisierte Verbindung zu einem externen Werkzeugdienst her. Der Remote-Mac ist dabei nicht automatisch der MCP-Server. Er kann den Agent ausführen, einen lokalen MCP-Prozess starten oder über das Netzwerk einen getrennten MCP-Dienst erreichen.

Die wichtigste erste Entscheidung betrifft deshalb die Transportart:

Variante	Typischer Ort	Stärken	Kritische Grenze
Lokaler MCP	Prozess auf demselben Mac	Kurzer Weg, einfache Entwicklung, kein öffentlicher MCP-Endpunkt erforderlich	Dateisystem- und Kommandozugriff liegen schnell im selben Vertrauensbereich wie der Agent
Streamable-HTTP-MCP	Separater Remote-Server mit URL	Klare Trennung, zentrale Protokollierung und kontrollierbarer Netzwerkzugriff	URL, Authentifizierungs-Header, TLS, Ausgehende Verbindung und Server-Verfügbarkeit müssen stimmen

Die offizielle Dokumentation beschreibt die Antigravity-Agent-Anbindung und die MCP-Konfiguration; die konkreten Felder und das Verhalten können sich mit einer neuen Agent-Version ändern. Vor einer produktiven Einrichtung sollte daher die offizielle Dokumentation zum Antigravity Agent gegen die tatsächlich installierte Version geprüft werden.

Was muss vor dem Hinzufügen eines MCP-Servers auf dem Cloud-Mac vorhanden sein?

Mindestens diese Punkte müssen geklärt sein:

Der Mac kann den vorgesehenen Remote-Host über den erlaubten Netzwerk-Ausgang erreichen.
Die MCP-URL ist vollständig, verwendet das erwartete Protokoll und verweist nicht nur auf eine allgemeine Startseite.
Authentifizierungsdaten liegen in Umgebungsvariablen oder einem geeigneten Geheimnisspeicher, nicht im Quellcode und nicht in einer gemeinsam geteilten Konfigurationsdatei.
Das Arbeitsverzeichnis enthält nur die für den Test benötigten Dateien.
Der Agent-Prozess und der MCP-Prozess sind anhand ihrer Logs getrennt erkennbar.
Für den ersten Test ist klar, ob lediglich gelesen, ein Kommando ausgeführt oder ein externes System verändert werden darf.

Für Testaufgaben eignen sich strukturierte Abfragen, das Lesen einer ausdrücklich freigegebenen Beispieldatei und die Extraktion definierter Felder aus einer kontrollierten Antwort. Nicht direkt an den Agent delegiert werden sollten Zugriffe auf private Schlüssel, Produktionsdatenbanken, Zahlungsdienste, nicht versionierte Geheimnisse, beliebige Shell-Kommandos oder externe Schreibaktionen. Ein Cloud-Mac ist eine isolierte Arbeitsumgebung, aber keine automatische Sicherheitsgrenze gegen Fehlkonfigurationen.

Erster Einrichtungsschritt: Google Antigravity MCP registrieren

Wie lässt sich Google Antigravity um einen MCP-Server erweitern?

Die Registrierung sollte mit einem einzigen Remote-Server beginnen. Nach der Prüfung des Konfigurationsschemas werden ein verständlicher Name, die Remote-URL, die erforderlichen Header und eine eng gefasste Liste erlaubter Werkzeuge hinterlegt. Die Google-Dokumentation zu MCP-Konfiguration und Server-Zugriff ist dabei die maßgebliche Referenz für Feldnamen und das erwartete Format.

Ein vereinfachtes Muster sieht inhaltlich so aus:

{
  "name": "team-readonly",
  "url": "https://mcp.example.invalid/stream",
  "headers": {
    "Authorization": "Bearer ${MCP_READ_TOKEN}"
  },
  "allowed_tools": [
    "read_record"
  ]
}

Die Adresse und der Werkzeugname in diesem Beispiel sind Platzhalter und dürfen nicht ungeprüft übernommen werden. Entscheidend sind vier Eigenschaften:

name beschreibt den Server eindeutig und darf nicht mit einem zweiten Eintrag verwechselt werden.
url zeigt auf den tatsächlichen Streamable-HTTP-Endpunkt, nicht auf die Dokumentationsseite des Dienstes.
headers werden aus der Laufzeitumgebung befüllt; ein Token gehört nicht als Klartext in ein Git-Repository.
allowed_tools enthält zunächst exakt die Funktion, die für den Lesetest gebraucht wird.

Für den ersten Verbindungsversuch wird kein globaler Stern-Platzhalter verwendet. Eine Freigabe wie *, die sämtliche verfügbaren Werkzeuge eines Servers einschließt, macht den Test zwar scheinbar bequem, erschwert aber die spätere Ursachenanalyse und vergrößert die Wirkung eines kompromittierten oder falsch implementierten Tools.

Warum erscheint der Server, obwohl kein Werkzeug aufrufbar ist?

Eine erfolgreiche Registrierung bedeutet nicht zwingend, dass der Werkzeugkatalog korrekt geladen wurde. URL, Authentifizierungs-Header, MCP-Protokollantwort und Netzwerkausgang müssen getrennt geprüft werden. Ein Server kann erreichbar sein, aber wegen eines fehlenden Headers keine Werkzeuge liefern; ebenso kann ein gültiger Token an einem falschen Endpunkt abgewiesen werden.

Für die Erstdiagnose werden vier Antwortgruppen getrennt betrachtet: 200 steht typischerweise für eine erfolgreiche HTTP-Antwort, 401 für fehlende oder ungültige Authentifizierung, 403 für eine erkannte Identität ohne ausreichende Berechtigung und 404 für einen nicht vorhandenen Pfad. Diese Interpretation muss mit dem jeweiligen Dienstprotokoll abgeglichen werden; die offiziellen MCP-Zugriffskontrollen von Google Cloud erläutern die zugrunde liegende Trennung von Zugriff und Berechtigung.

Zweiter Einrichtungsschritt: Den kleinsten Verbindungstest durchführen

Der minimale Ablauf besteht aus fünf kontrollierten Handlungen:

Erstellen Sie auf dem Cloud-Mac ein frisches Arbeitsverzeichnis ohne Produktionsdaten.
Hinterlegen Sie den MCP-Token als Umgebungsvariable mit den Rechten, die ausschließlich für eine Leseaktion erforderlich sind.
Registrieren Sie nur den Remote-Server und nur ein bekanntes Read-only-Tool.
Starten Sie Antigravity und prüfen Sie, ob der Server erreichbar sowie das erlaubte Werkzeug sichtbar ist.
Führen Sie eine Anfrage mit einem festen, nicht vertraulichen Datensatz aus und speichern Sie die Antwort sowie den Fehlerstatus.

Der erste Prompt sollte keine freie Agent-Aufgabe sein. Besser ist eine Anweisung mit eindeutigem Ergebnis, etwa die Abfrage eines Testobjekts und die Rückgabe von drei vorher festgelegten Feldern. So lässt sich unterscheiden, ob das Modell die Anfrage falsch interpretiert, das MCP-Tool einen Fehler zurückgibt oder der Cloud-Mac den Dienst nicht erreicht.

Wie werden fehlgeschlagene MCP-Aufrufe auf einem Cloud-Mac untersucht?

Die Fehlersuche erfolgt in dieser Reihenfolge:

Prüfen Sie zunächst die DNS-Auflösung und den ausgehenden Netzwerkpfad des Mac.
Vergleichen Sie die konfigurierte URL mit dem tatsächlichen Streamable-HTTP-Endpunkt.
Kontrollieren Sie, ob der Header im Prozess ankommt, ohne seinen geheimen Wert in ein Log zu schreiben.
Prüfen Sie die Protokollantwort und den vom Server gemeldeten Werkzeugnamen.
Entfernen Sie vorübergehend alle Werkzeuge außer der einen Read-only-Funktion.
Wiederholen Sie den Aufruf mit derselben Eingabe, damit der Fehler reproduzierbar bleibt.
Ordnen Sie den Fehler anschließend dem Agent, dem MCP-Dienst oder der entfernten Mac-Umgebung zu.

Ein Modellfehler zeigt sich beispielsweise durch eine unpassende Werkzeugauswahl oder falsch strukturierte Argumente, obwohl der Dienst erreichbar ist. Ein MCP-Fehler liegt eher bei einer ungültigen Eingabe, einem Serverfehler oder einer verweigerten Berechtigung. Ein Umgebungsfehler betrifft dagegen Netzwerk, Prozessstart, Umgebungsvariable, Arbeitsverzeichnis oder Sitzungserhalt. Diese Trennung verhindert, dass ein Netzwerkproblem durch eine unnötige Änderung am Agent-Prompt „behoben“ werden soll.

Dritter Einrichtungsschritt: Berechtigungen in einer Matrix begrenzen

Wie sollten die Antigravity-MCP-Berechtigungen konfiguriert werden?

read_file, command und mcp müssen als getrennte Risikoklassen behandelt werden. Ein Agent, der eine Datei lesen darf, besitzt dadurch nicht automatisch das Recht, ein Kommando auszuführen oder einen externen MCP-Dienst aufzurufen. Umgekehrt kann ein scheinbar harmloses MCP-Tool intern Schreibaktionen auslösen. Die Dokumentation zu Antigravity-Agent-Hooks sollte zusätzlich geprüft werden, wenn vor oder nach einem Agent-Aufruf kontrollierende Aktionen ausgeführt werden sollen.

Berechtigung	Engste sinnvolle Freigabe	Risiko bei globaler Freigabe	Geeignete Bestätigung
`read_file`	Einzelne Testdatei oder klar abgegrenztes Verzeichnis	Geheimnisse, Quellcode und Konfigurationsdateien können unbeabsichtigt offengelegt werden	Keine automatische Freigabe für private Schlüssel und Produktionsdaten
`command`	Ein fest definiertes, nicht destruktives Kommando	Beliebige Shell-Befehle, Datenverlust, Installation und Seiteneffekte	Vor jedem neuen Kommando eine manuelle Bestätigung
`mcp`	Ein Server mit einem einzelnen Werkzeug	Externe Systeme können gelesen oder verändert werden	Bestätigung für Schreib-, Zahlungs- und Identitätsaktionen

Für die interne Betriebsplanung kann die folgende dreistufige Matrix verwendet werden. Die drei Stufen sind eine empfohlene Organisationsregel, keine Zusicherung eines bestimmten Produkttarifs oder einer bestimmten Antigravity-Version.

Betriebsstufe	Erlaubte Aktionen	Nicht automatisch erlauben	Abnahmekriterium
Entwicklung	Read-only-Dateien, ein Test-MCP-Tool, begrenzte strukturierte Abfragen	Produktionsgeheimnisse, freie Shell-Befehle, externe Schreibvorgänge	Reproduzierbare Antwort und vollständige, aber secret-freie Logs
Test	Definierte Build- oder Prüfkommandos, ausgewählte MCP-Tools, kontrollierte Schreibprobe	Unbegrenzte Dateipfade, globale Tool-Muster, reale Zahlungs- oder Kundendaten	Fehler lässt sich absichtlich auslösen und korrekt klassifizieren
Produktion	Nur freigegebene Server und exakt dokumentierte Werkzeuge	Globale Wildcards, unbestätigte Änderungen und nicht protokollierte Tokens	Verantwortlicher bestätigt Rechte, Rücknahme und Wiederherstellung

Die offizielle MCP-IAM-Dokumentation hilft bei der Zuordnung von Identitäten und Berechtigungen. Sie ersetzt jedoch keine lokale Rechteprüfung auf dem Cloud-Mac. Ein zu weit gefasstes IAM-Recht kann durch eine enge lokale Tool-Liste begrenzt werden, aber ein falsch konfigurierter Agent kann eine globale lokale Freigabe nicht durch gute Absichten kompensieren.

Vierter Einrichtungsschritt: Erstaufruf und Schreibaktion kontrolliert abnehmen

Nach dem Read-only-Test folgt keine komplexe autonome Aufgabe, sondern eine feste Abnahmereihenfolge:

Verbindung: Der registrierte MCP-Server ist erreichbar, und die Antwort wird dem richtigen Server zugeordnet.
Werkzeugliste: Nur das ausdrücklich erlaubte Werkzeug ist sichtbar.
Strukturierte Extraktion: Eine bekannte Antwort wird in ein vorgegebenes Schema überführt.
Fehlerfall: Ein absichtlich ungültiger Parameter erzeugt einen erwarteten, protokollierten Fehler.
Kontrollierte Schreibaktion: Eine ungefährliche Teständerung wird erst nach manueller Bestätigung ausgeführt.
Sitzung: Nach einem kontrollierten Neustart bleibt die Konfiguration nachvollziehbar und der Token wird nicht in Klartext ausgegeben.

Die kontrollierte Schreibaktion sollte nicht auf Produktionsdaten zielen. Geeignet ist beispielsweise ein eigens angelegter Testdatensatz, eine temporäre Datei in einem isolierten Verzeichnis oder eine nicht veröffentlichte Entwurfsänderung. Vor der Ausführung müssen Ziel, Umfang und Rücknahmeweg sichtbar sein. Eine Agent-Antwort wie „Änderung erfolgreich“ reicht als Nachweis nicht; der externe Dienst muss den neuen Zustand separat bestätigen.

Für die Dokumentation werden mindestens diese Informationen aufgezeichnet:

Zeitpunkt und verwendete Konfigurationsversion;
Servername und Werkzeugname;
Ergebnis der Verbindung;
Rückgabestruktur des Tools ohne geheime Werte;
Fehler und Wiederholungsversuche;
manuelle Bestätigung vor der Schreibaktion;
Verhalten nach Beendigung und Wiederaufnahme der Sitzung.

Ein Einsteiger-Codelab zu Google Antigravity kann den grundsätzlichen Agent-Ablauf ergänzen. Für eine Teamfreigabe muss jedoch die eigene MCP-Konfiguration maßgeblich bleiben, weil ein Codelab keine Aussage über die Rechte, Netzwerkregeln und Geheimnisse einer konkreten Cloud-Mac-Umgebung trifft.

Fünfter Einrichtungsschritt: Wartung vor dem Team-Rollout vorbereiten

Vor der gemeinsamen Nutzung wird aus der funktionierenden Einzelverbindung eine verwaltbare Arbeitsumgebung. Dazu gehört zunächst die Geheimnisrotation. Der alte Token wird nach dem Wechsel widerrufen, die neue Variable wird außerhalb des Quellcodes verteilt und ein Read-only-Aufruf bestätigt, bevor weitere Rechte wieder aktiviert werden. Ein Token, der in einem Terminal-Transkript, einer Agent-Konversation oder einem Debug-Log auftaucht, gilt als offengelegt und muss ersetzt werden.

Neue MCP-Server sollten einem Review unterliegen. Der technische Verantwortliche prüft Quelle, URL, erwartete Werkzeuge, Datenfluss, Protokollierung, Löschverhalten und Rücknahme. Besonders kritisch sind Werkzeuge, die Dateiinhalte an externe Systeme übertragen, Kommandos ausführen oder Schreibaktionen ohne separate Bestätigung kombinieren. Die Bezeichnung „read-only“ darf nicht ungeprüft übernommen werden; sie muss aus dem Verhalten des Dienstes und der Berechtigungsbeschreibung hervorgehen.

Für den laufenden Cloud-Mac-Betrieb gehören folgende Punkte in die Checkliste:

[ ] Für jede Umgebung existiert eine versionierte Konfiguration mit nachvollziehbarer Änderungshistorie.
[ ] Nicht mehr benötigte MCP-Server und Werkzeuge sind deaktiviert oder widerrufen.
[ ] Authentifizierungsdaten werden regelmäßig ersetzt und nicht in Logs übernommen.
[ ] Agent-, MCP- und Betriebssystem-Logs sind zeitlich einander zuordenbar.
[ ] Freier Speicher, Prozessstatus und Sitzungsabbruch werden überwacht.
[ ] Parallel laufende Sitzungen verwenden getrennte Arbeitsverzeichnisse und Identitäten.
[ ] Einträge mit Quellcode, personenbezogenen Daten oder Geheimnissen werden nach den internen DSGVO-Regeln behandelt.
[ ] Nicht mehr benötigte Cloud-Mac-Sitzungen werden beendet, statt unbegrenzt im Hintergrund zu laufen.
[ ] Für jede Schreibaktion ist ein Rücknahme- oder Wiederherstellungsweg dokumentiert.
[ ] Ein Fehler kann einem Modell, einem MCP-Server oder der Remote-Umgebung zugeordnet werden.

Wann reicht ein einzelner Cloud-Mac nicht mehr aus?

Eine einzelne Umgebung ist für Entwicklung, kontrollierte Tests und kleine, klar abgegrenzte Agent-Aufgaben geeignet. Eine zentralisierte Agent-Umgebung wird sinnvoll, wenn mehrere Teams dieselben Server nutzen, Identitäten getrennt verwaltet werden müssen, Sitzungen parallel laufen oder Freigaben, Audit-Protokolle und Richtlinien nicht mehr zuverlässig manuell gepflegt werden können. Der Wechsel sollte nicht durch die bloße Anzahl der Werkzeuge ausgelöst werden, sondern durch die Anforderungen an Nachvollziehbarkeit, Isolation und Wiederherstellung.

Für die Auswahl einer passenden Mac-Umgebung kann die Übersicht der Cloud-Mac-Angebote von Vuncloud als Ausgangspunkt dienen. Bei Fragen zu Zugang, Bereitstellung oder einer spezifischen Umgebung steht außerdem das deutsche Hilfezentrum von Vuncloud zur Verfügung. Beide Verweise ersetzen keine technische Rechteprüfung, helfen aber dabei, die benötigte Remote-Arbeitsumgebung vor dem MCP-Rollout einzugrenzen.

Die Abnahme in fünf Minuten nachvollziehbar dokumentieren

Eine kompakte Abnahme sollte nicht nur „Verbindung erfolgreich“ enthalten. Sie muss die erlaubte Grenze sichtbar machen. Der verantwortliche Entwickler kann dafür folgende Reihenfolge verwenden:

[ ] Der Cloud-Mac startet mit einem isolierten Arbeitsverzeichnis.
[ ] Die MCP-URL ist erreichbar, und der ausgehende Netzwerkpfad ist dokumentiert.
[ ] Der Authentifizierungs-Header wird aus einer Laufzeitvariable geladen.
[ ] Genau ein Read-only-Werkzeug ist zugelassen.
[ ] Eine definierte Anfrage liefert ein erwartetes strukturiertes Ergebnis.
[ ] Ein ungültiger Parameter wird als Fehler protokolliert und nicht stillschweigend wiederholt.
[ ] read_file, command und mcp sind getrennt bewertet.
[ ] Eine kontrollierte Schreibaktion erfordert eine sichtbare manuelle Bestätigung.
[ ] Geheimnisse erscheinen weder in Agent-Ausgaben noch in Debug-Logs.
[ ] Die Konfiguration kann auf einen vorherigen geprüften Stand zurückgesetzt werden.

Wer diesen Ablauf nicht reproduzieren kann, sollte die Berechtigungen nicht erweitern. Insbesondere ein funktionierender erster Aufruf beweist weder, dass der Server vertrauenswürdig ist, noch dass alle nachgelagerten Werkzeuge denselben Sicherheitsumfang besitzen.

Cloud-Mac oder lokaler Mac: die Entscheidung nach dem ersten Test

Ein lokaler Mac ist häufig bequemer, wenn physische Geräte, lokale Dateien oder eine direkte Benutzerinteraktion benötigt werden. Für wiederholbare Agent-Tests entstehen dort jedoch schnell versteckte Abhängigkeiten: persönliche Zugangsdaten bleiben in der Umgebung, Arbeitsverzeichnisse vermischen sich, mehrere Teammitglieder verwenden unterschiedliche Konfigurationen und eine beschädigte lokale Installation lässt sich schwer identisch reproduzieren.

Ein Cloud-Mac bietet dagegen eine getrennte Arbeitsumgebung, einen klareren Übergabepunkt und eine leichtere Trennung zwischen Test- und Alltagsgerät. Nachteile bleiben bestehen: Netzwerkzugriff kann ausfallen, Sitzungen müssen überwacht werden, zusätzliche Zugriffskontrollen sind nötig und langfristige, dauerhaft hohe Auslastung kann gegenüber einem eigenen Gerät wirtschaftlich unpassend sein. Wer physische USB-Geräte, lokale Spezialhardware oder konstant laufende Produktionslast benötigt, sollte den Cloud-Mac nicht als automatische Dauerlösung einplanen.

Für temporäre Agent-Tests, reproduzierbare MCP-Abnahmen und die kurzfristige Einrichtung einer separaten Entwicklungsumgebung ist die Miete eines Mac von Vuncloud häufig der kontrollierbarere Weg als ein ungeprüfter Remote-Zugriff auf einen persönlichen Rechner. Entscheidend bleibt, die Umgebung mit minimalen Rechten zu starten und erst nach erfolgreicher Abnahme zu erweitern. Die Kontaktseite von Vuncloud ist der passende nächste Schritt, wenn für den Test eine konkrete Remote-Mac-Umgebung benötigt wird.