Webflow Cloud Apps

Was macht Webflow Cloud Apps?

Verwenden Sie data_apps_tool, um GitHub-basierte Apps zu erstellen, betriebliche Fragen zu beantworten und Umgebungen für Webflow Cloud-Apps zu verwalten. Beginnen Sie mit dem gewünschten Ergebnis des Benutzers, sammeln Sie nur die erforderlichen Beweise und unterscheiden Sie Beobachtungen von Schlussfolgerungen.

Verwenden Sie den Skill webflow-cli:cloud, wenn die Aufgabe die Erstellung oder Bereitstellung einer CLI/lokalen Quelle oder das Erstellen oder Aktualisieren von Umgebungsvariablen erfordert. Die clientseitige Build-Ausgabe wird nicht an Webflow gesendet und kann über MCP nicht wiederhergestellt werden.

Anweisungen

1. Umfang festlegen

Nutzen Sie die vom Benutzer in der Anfrage oder im bestehenden Aufgabenkontext eingerichtete Webflow MCP-Verbindung. Wenn nur eine Verbindung aktiv ist, verwenden Sie diese, ohne den Benutzer zu bitten, eine Region auszuwählen oder zu bestätigen. Wenn mehrere Verbindungen aktiv sind und das beabsichtigte Ziel unklar bleibt, bitten Sie den Benutzer vor zielabhängigen Operationen um eine Klarstellung. Wechseln Sie nicht die Region, um fehlende Ressourcen oder Zugriffsfehler zu beheben.

Bevor Sie eine bestehende MCP-App oder -Umgebung an die CLI zur Konfigurationsänderung oder Bereitstellung übergeben, vergleichen Sie deren konfigurierte Regionen. Wenn diese abweichen, gehen Sie nicht davon aus, dass eine davon korrekt ist, und leiten Sie kein Tool stillschweigend um. Lösen Sie das beabsichtigte Ziel anhand des expliziten Aufgabenkontexts auf; falls dies den Konflikt nicht löst, fragen Sie den Benutzer. Setzen Sie abhängige Mutationen aus, bis der Konflikt gelöst ist.

Sobald die beabsichtigte Region festgelegt ist, stellen Sie sicher, dass die CLI die exakten MCP-App- und Umgebungs-IDs lesen kann, und tragen Sie diese Region und IDs explizit in nachfolgende Mutationen. Der Anmeldestatus oder eine Regionsbezeichnung allein ist nicht ausreichend. Wenn die Überprüfung fehlschlägt, melden Sie den Fehler, ohne seine Ursache zu vermuten, und setzen Sie abhängige Mutationen aus. Fahren Sie mit unabhängigen Arbeiten fort, deren Ziel bereits festgelegt ist.

1. Rufen Sie webflow_guide_tool vor jedem anderen Webflow MCP-Tool auf. Der Live-Guide und die Aktionsschemata sind maßgeblich für aktuelle Argumente und Antworten.
2. Verwenden Sie Webflow MCP-Tools für Webflow-Operationen, mit Ausnahme der expliziten CLI-Übergabe für Umgebungsvariablenwerte. Rufen Sie Webflow-APIs niemals direkt auf.
3. Fügen Sie den erforderlichen Parameter context in jeden Tool-Aufruf ein. Schreiben Sie 15-25 Wörter in der dritten Person.
4. Leiten Sie basierend auf der erforderlichen Fähigkeit:
   • Verwenden Sie data_apps_tool zum Erstellen von GitHub-basierten Apps; zum Inspizieren von Apps, Umgebungen, Domains, Bereitstellungsdatensätzen, Logs und Variablenmetadaten; zum Verwalten von GitHub-Quellen und Umgebungen; und zum Einreihen von GitHub-Bereitstellungen.
   • Verwenden Sie data_variable_tool für Designer-Farb-, Größen-, Schrift- und CSS-Variablen.
   • Verwenden Sie webflow-cli:cloud für CLI/lokale Quellen-Apps, lokale Builds und Bereitstellungen oder zum Erstellen und Aktualisieren von Umgebungsvariablenwerten.
5. Wenn data_apps_tool nicht verfügbar ist, melden Sie, dass die Cloud-Apps MCP-Fähigkeit nicht aktiviert ist. Umgehen Sie dies nicht mit einer direkten API-Anfrage.

Bitten Sie den Benutzer niemals, einen Umgebungsvariablenwert oder ein Geheimnis in den Chat einzufügen. Delegieren Sie bei einer Erstellung oder Aktualisierung an webflow-cli:cloud und fordern Sie eine versteckte Eingabeaufforderung, stdin oder eine geschützte Datei. Übergeben Sie ein Geheimnis niemals als Positionsargument.

2. Das Ziel identifizieren

Identifizieren Sie die IDs in dieser Reihenfolge:

list_apps -> app_id
list_environments(app_id) -> env_id
list_deployments(app_id, env_id) -> deployment_id

App-Namen sind nur innerhalb einer Site eindeutig, daher lösen Sie eine benannte App mit site_id + name auf. Wenn mehrere Ressourcen übereinstimmen, präsentieren Sie unterscheidende Metadaten und fordern Sie den Benutzer auf, eine vor einer Mutation auszuwählen. Verwenden Sie den Live-Guide für Filter-, Paginierungs-, Cursor- und Aktionsbündelungsmechanismen.

3. Der passenden Benutzergeschichte folgen

Eine GitHub-basierte App erstellen

1. Legen Sie den App-Namen, die kanonische GitHub-Repository-URL, den Branch, eine optionale Beschreibung und fest, ob sie standalone oder an eine bestehende Site angebunden ist.
2. Lösen Sie für eine site-attached App die Site-ID auf. Lassen Sie site_id für standalone weg.
3. Wenden Sie den Mount-Vertrag vor der Vorschau an:
   • Eine standalone App mountet immer unter /; lassen Sie mount weg oder verwenden Sie /.
   • Eine site-attached App verwendet standardmäßig /app, lehnt / ab und erfordert einen gültigen, nicht-Root-Mount beim Überschreiben der Vorgabe.
4. Erklären Sie, dass die Erstellung einer standalone App ein Workspace-weites Benutzertoken erfordert. Webflow leitet die GitHub-Installation ab und validiert den Repository-Zugriff; fordern Sie keine Installations-ID an.
5. Rufen Sie create_app mit dessen standardmäßigem Dry-Run auf. Zeigen Sie Repository, Branch, Anbindung, Site (falls zutreffend), Mount und den Versuch der ersten Bereitstellung an.
6. Fordern Sie confirm. Unmittelbar nach der Bestätigung und vor der Ausführung zeichnen Sie die Startzeit auf und generieren einen stabilen idempotency_key; führen Sie mit dry_run: false aus, zeichnen Sie dann die Endzeit auf. Verwenden Sie diesen Schlüssel nur für exakte Wiederholungen dieser Erstellung.
7. Behandeln Sie Erstellung und erstmalige Bereitstellung als separate Ergebnisse. Eine zurückgegebene App bedeutet, dass die Erstellung erfolgreich war, auch wenn deployStatus skipped oder failed ist. Bei triggered inspizieren Sie die Umgebung und Bereitstellung; bei skipped überprüfen Sie den Branch oder pushen einen Commit; bei failed behalten Sie die App bei und inspizieren oder wiederholen die Bereitstellung separat.
8. Wenn die App oder das Ergebnis nicht lesbar ist, gleichen Sie vor dem erneuten Versuch ab:
   • Für eine site-attached App sammeln Sie Kandidaten mit site_id + name; für eine standalone App sammeln Sie Kandidaten nach Namen.
   • Vergleichen Sie in beiden Fällen den Namen, sourceUrl und createdAt jedes Kandidaten mit dem angeforderten Repository und dem aufgezeichneten Ausführungszeitfenster.
   • Fahren Sie nur mit Umgebungen und Bereitstellungen fort, wenn genau ein Kandidat übereinstimmt. Starten Sie keinen erneuten Versuch, solange die erstellte App mehrdeutig bleibt.
9. Löschen Sie eine erstellte App niemals automatisch, weil die Bereitstellung fehlgeschlagen ist. Behandeln Sie einen Dashboard-Link für die erste Bereitstellung nicht als öffentliche URL der Umgebung.

Welche App und Umgebung sehe ich mir an?

1. Verwenden Sie list_apps, um die App zu finden, und get_app für deren Metadaten, einschließlich sourceUrl und siteAttached.
2. Verwenden Sie list_environments, um den Branch, Mount, publicUrl und den neuesten Bereitstellungsstatus zu melden. Wenn publicUrl null ist, melden Sie, dass keine benutzerseitige Umgebungsadresse verfügbar ist; konstruieren Sie keine.
3. Verwenden Sie get_app_domains, wenn der Benutzer fragt, wo die App erreichbar ist.
4. Erklären Sie, dass Ergebnisse für benutzerdefinierte Domains den standardmäßigen *.webflow.io-Hostnamen ausschließen. Domains für eine App, die an eine reguläre Webflow-Site angebunden ist, können zur übergeordneten Site gehören und von Geschwister-Apps gemeinsam genutzt werden.

Was ist bereitgestellt, und ist es gesund?

1. Verwenden Sie list_environments für den neuesten Bereitstellungsstatus der Umgebung.
2. Verwenden Sie list_deployments, neueste zuerst, dann get_deployment für die detaillierte Zeitleiste und Versionsmetadaten der ausgewählten Bereitstellung.
3. Behandeln Sie starting, building und deploying als aktive Status. Melden Sie jeden anderen Status genau, anstatt seine Bedeutung zu erraten.
4. Eine fehlgeschlagene Phase setzt buildFailedAt oder deployFailedAt, während der zugehörige abgeschlossene Zeitstempel null bleibt. Ein null abgeschlossener Zeitstempel allein beweist nicht, dass die Phase noch läuft.
5. Melden Sie, was beobachtbar ist: ausgewählte App und Umgebung, Bereitstellungsstatus, Versions- oder Commit-Metadaten (falls zurückgegeben), Phasenzeitstempel und Beweislücken.

Warum ist die Bereitstellung fehlgeschlagen?

1. Rufen Sie die Bereitstellung mit get_deployment ab und identifizieren Sie die fehlgeschlagene Phase anhand ihres Status und ihrer Zeitstempel.
2. Rufen Sie get_build_logs nur auf, wenn logsAvailable wahr ist. Beginnen Sie mit einem engen since-Fenster oder q-Filter, erweitern Sie dann nur bei Bedarf.
3. Blättern Sie, bis nextCursor null ist, wenn ein vollständiges Ergebnis erforderlich ist.
4. Behandeln Sie logsAvailable als Aufbewahrungs- und Abrufsignal, nicht als Beweis dafür, dass jede Phase Logeinträge erzeugt hat.
5. Behandeln Sie ein leeres Ergebnis als „keine übereinstimmenden abrufbaren serverseitigen Logs“, nicht als Beweis dafür, dass der Build erfolgreich war oder keine Fehler erzeugt hat.
6. Build-Ausgabe, die auf dem Rechner eines Benutzers erzeugt wurde, liegt außerhalb von MCP. Erwähnen Sie dies nur, wenn der Benutzer sagt, dass die Bereitstellung mit der CLI erstellt wurde; leiten Sie ihn bei lokalen Build-Fehlern an die ursprüngliche CLI-Ausgabe weiter.
7. Melden Sie die fehlgeschlagene Phase, relevante Zeitstempel, die kleinsten nützlichen Beweise, die vermutete Ursache und etwaige Unsicherheit. Geben Sie nicht einfach Roh-Logs wieder.

Warum schlägt die laufende App fehl?

1. Identifizieren Sie die genaue Umgebung und rufen Sie get_runtime_logs auf.
2. Eingrenzen durch since und q, bevor Sie ein breites Fenster abrufen. Blättern Sie vollständig, wenn die Schlussfolgerung vom Fehlen abhängt.
3. Laufzeit-Logs können aufgrund der Aufbewahrung nicht verfügbar sein. Behandeln Sie ein leeres Ergebnis als keine abrufbaren Logs und melden Sie die Einschränkung.
4. Korrelieren Sie Laufzeitbeweise mit dem neuesten Bereitstellungsdatensatz, wenn sinnvoll, aber behaupten Sie keine Kausalität allein aus dem Timing.
5. Melden Sie das beobachtete Fehlermuster, das betroffene Intervall, die wahrscheinliche Ursache, Beweise und Einschränkungen.

Ist die erforderliche Konfiguration vorhanden?

1. Legen Sie den erforderlichen Schlüsselsatz aus einer autoritativen Quelle fest: einer vom Benutzer bereitgestellten Schlüsselliste, einem Projektkonfigurationsschema oder dokumentierten Anforderung oder einer Referenzumgebung, die der Benutzer explizit als vollständig bezeichnet.
2. Wenn die Quelle eine geschützte Datei mit Werten ist, führen Sie eine deterministische schlüsselbezogene Extraktion lokal durch und geben Sie nur Schlüsselnamen aus. Öffnen Sie die Quelle niemals durch eine modellsichtbare Leseoperation und schließen Sie ihre Werte nicht in Chat oder Tool-Ausgabe ein.
3. Holen Sie eine autoritative Geheimniszuweisung für jeden erforderlichen Schlüssel vom Benutzer, einem Projektschema oder dokumentierten Anforderung oder einer Referenzumgebung ein, die explizit als maßgeblich für die Geheimniszuweisung bezeichnet wurde. Eine .env-Datei oder eine einfache Schlüsselliste legt nur Namen fest; leiten Sie Geheimnisse niemals aus Schlüsselnamen ab.
4. Identifizieren Sie die Umgebung, rufen Sie list_variables auf und vergleichen Sie deren Schlüssel und Geheimnis-Metadaten mit den festgelegten Anforderungen. Es beweist, was konfiguriert ist, nicht was erforderlich ist. Schöpfen Sie die Paginierung aus, bevor Sie schließen, dass ein Schlüssel fehlt.
5. Melden Sie nur Schlüssel und Metadaten. Geheime Einträge haben isSecret: true und keinen Wert; ein fehlender geheimer Wert ist erwartungsgemäß.
6. Wenn der erforderliche Satz oder eine Geheimniszuweisung ungeklärt ist, stoppen Sie vor einer CLI-Mutation oder abhängigen Bereitstellung, es sei denn, der Benutzer stellt explizit fest, dass keine Konfiguration erforderlich ist.
7. Für fehlende oder falsch klassifizierte Schlüssel leiten Sie an webflow-cli:cloud weiter, ohne Werte im Chat anzufordern. Nach dem Schreiben überprüfen Sie die erforderlichen Schlüssel und die Geheimniszuweisung mit list_variables. Wenn es teilweise fehlschlägt, melden Sie die fehlgeschlagenen Schlüssel ohne Werte und stoppen Sie vor der Bereitstellung; bewahren Sie erfolgreiche Schlüssel und die Umgebung.

Warum bedient diese Umgebung den falschen Branch oder Route?

1. Identifizieren Sie die genaue Umgebung und melden Sie ihren aktuellen Branch, Mount, publicUrl und den neuesten Bereitstellungsstatus. Melden Sie einen null publicUrl, ohne eine Adresse zu konstruieren.
2. Vergleichen Sie den aktuellen Branch und Mount mit der beabsichtigten Zuordnung des Benutzers. Wenn die Anfrage nur diagnostisch ist, stoppen Sie nach der Meldung der Abweichung.
3. Wenn die Korrektur den Mount ändert, rufen Sie get_app auf und verwenden Sie siteAttached: / ist nur gültig, wenn false; eine site-attached App erfordert einen nicht-Root-Mount. Leiten Sie die Anbindung nicht aus siteId ab.
4. Für eine Korrektur zeigen Sie die exakte Vorher-Nachher-Zuordnung. Erklären Sie, dass update_environment sofort erfolgt, keinen Dry-Run hat und keinen Code bereitstellt.
5. Fordern Sie confirm, rufen Sie update_environment einmal auf und melden Sie die zurückgegebene Umgebung, publicUrl und mountRefreshStatus.
6. Für ein unlesbares oder unsicheres Ergebnis lokalisieren Sie die ursprüngliche env_id. Wenn Sie den erwarteten neuen Branch als Filter verwenden, akzeptieren Sie eine zurückgegebene Umgebung nur, wenn ihre ID dieser ursprünglichen env_id entspricht, und vergleichen Sie dann ihren Branch und Mount mit den angeforderten Werten. Eine andere ID oder kein eindeutig übereinstimmendes ursprüngliches Ziel ist mehrdeutig: Fahren Sie nicht fort oder wiederholen Sie es nicht. Verwenden Sie den alten Branch-Filter nach einer Branch-ändernden Aktualisierung niemals erneut.
7. Ein fehlgeschlagener oder unbekannter Mount-Refresh bedeutet nicht, dass die Umgebungsaktualisierung rückgängig gemacht wurde. Melden Sie das Routing als unsicher und wiederholen Sie es nicht allein, weil der Refresh fehlgeschlagen ist.
8. Wenn sich der Branch geändert hat und der Benutzer dessen Code bereitgestellt haben möchte, behandeln Sie trigger_deployment als separate, in der Vorschau angezeigte und bestätigte Mutation.

Eine isolierte Umgebung für einen Branch erstellen und bereitstellen

1. Identifizieren Sie die vorhandene App, rufen Sie get_app auf und validieren Sie den vorgeschlagenen Mount mit siteAttached, bevor Sie die Mutation in der Vorschau anzeigen.
2. Blättern Sie durch list_environments, um zu prüfen, ob der angeforderte Branch oder Mount bereits verwendet wird.
3. Zeigen Sie den vorgeschlagenen Branch und Mount an. Erklären Sie, dass create_environment sofort erfolgt, keinen Dry-Run hat und eine Zuordnung erstellt, ohne Code bereitzustellen.
4. Generieren Sie einen stabilen idempotency_key, fordern Sie confirm und rufen Sie create_environment auf. Verwenden Sie diesen Schlüssel nur für exakte Wiederholungen.
5. Melden Sie die zurückgegebene Umgebung, publicUrl und mountRefreshStatus. Wenn das Ergebnis unsicher ist, suchen Sie nach dem erwarteten Branch und vergleichen Sie die Umgebungs-ID, den Branch und den Mount; verwenden Sie eine zurückgegebene ID, um gleichzeitige Erstellungen zu unterscheiden. Starten Sie keinen erneuten Versuch, solange die erstellte Umgebung mehrdeutig bleibt.
6. Ein fehlgeschlagener Refresh bedeutet, dass die Erstellung erfolgreich war, das Routing jedoch möglicherweise unvollständig ist. Wiederholen Sie die Erstellung nicht oder löschen Sie die Umgebung nicht automatisch.
7. Vor der Bereitstellung dieser neuen Umgebung folgen Sie „Ist die erforderliche Konfiguration vorhanden?“ als obligatorischem Tor. Fahren Sie erst fort, nachdem die Anforderungen und die Geheimniszuweisung überprüft wurden oder der Benutzer explizit feststellt, dass keine erforderlich sind. Verwenden Sie dann den untenstehenden Bereitstellungsworkflow für Vorschau, Bestätigung, Zuordnung und Überwachung.

Kann diese Bereitstellung wiederholt, zurückgesetzt oder vom Branch-HEAD neu erstellt werden?

Verwenden Sie den standardmäßigen Dry-Run der Mutation als Fähigkeitsprüfung. Leiten Sie die Berechtigung nicht aus fehlenden Logs, App-Metadaten oder Bereitstellungsmetadaten ab.

Für eine neue Bereitstellung vom verbundenen Branch oder einem vorherigen exakten Commit:

1. Identifizieren Sie die Umgebung. Für eine Wiederholung oder ein Rollback identifizieren Sie auch die genaue vorherige Bereitstellung.
2. Führen Sie eine Konfigurationsermittlung nur dann durch, wenn der Benutzer sie anfordert, Bereitstellungsbeweise auf fehlende oder falsch klassifizierte Variablen hindeuten, der ausgewählte Commit dokumentierte Konfigurationsanforderungen hat oder der Server die Bereitstellung aus Konfigurationsgründen ablehnt.