Webflow Cloud Apps

Utilisez data_apps_tool pour créer des apps à source GitHub, répondre à des questions opérationnelles et gérer les environnements des apps Webflow Cloud. Partez du résultat attendu par l'utilisateur, rassemblez uniquement les preuves nécessaires et distinguez les observations des conclusions.

Utilisez le skill webflow-cli:cloud lorsque la tâche nécessite la création ou le déploiement d'une app à source locale, ou la création ou la mise à jour de variables d'environnement. La sortie de build côté client n'est pas envoyée à Webflow et ne peut pas être récupérée via MCP.

Instructions

1. Établir le périmètre

Appelez webflow_guide_tool avant tout autre outil MCP Webflow. Le guide en direct et les schémas d'action sont autorité pour les arguments et réponses actuels.
Utilisez les outils MCP Webflow pour les opérations Webflow, sauf le transfert CLI explicite pour les valeurs de variables d'environnement. N'appelez jamais directement les APIs Webflow.
Incluez le paramètre context requis à chaque appel d'outil. Écrivez 15-25 mots en perspective à la troisième personne.
Routez selon la capacité requise par la tâche :
- Utilisez data_apps_tool pour créer des apps à source GitHub ; inspectez les apps, environnements, domaines, enregistrements de déploiement, logs et métadonnées de variables ; gérez les sources et environnements GitHub ; et enfilez les déploiements GitHub.
- Utilisez data_variable_tool pour les variables Designer de couleur, taille, police et CSS.
- Utilisez webflow-cli:cloud pour les apps à source locale, les builds et déploiements locaux, ou la création et mise à jour des valeurs de variables d'environnement.
Si data_apps_tool n'est pas disponible, signalez que la capacité MCP Cloud Apps n'est pas activée. Ne la contournez pas avec une demande d'API directe.

Ne demandez jamais à l'utilisateur de coller une valeur de variable d'environnement ou un secret dans le chat. Pour une création ou mise à jour, déléguez à webflow-cli:cloud et exigez un prompt caché, stdin ou fichier protégé. Ne passez jamais un secret comme argument positionnel.

2. Résoudre la cible

Découvrez les identifiants dans cet ordre :

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

Les noms d'app ne sont uniques que dans un site, résolvez donc une app nommée avec site_id + name. Si plusieurs ressources correspondent, présentez les métadonnées distinctives et exigez que l'utilisateur en sélectionne une avant toute mutation. Utilisez le guide en direct pour les mécaniques de filtre, pagination, curseur et traitement par lot d'actions.

3. Suivre l'histoire utilisateur correspondante

Créer une app à source GitHub

Établissez le nom de l'app, l'URL du dépôt GitHub canonique, la branche, une description optionnelle, et si elle est autonome ou attachée à un site existant.
Pour une app attachée à un site, résolvez l'ID du site. Omettez site_id pour une app autonome.
Appliquez le contrat de montage avant l'aperçu :
- Une app autonome est toujours montée à / ; omettez mount ou utilisez /.
- Une app attachée à un site est montée par défaut à /app, rejette /, et exige un montage non-racine valide en cas de remplacement du défaut.
Expliquez que la création autonome exige un token utilisateur de scope workspace. Webflow dérive l'installation GitHub et valide l'accès au dépôt ; ne demandez pas d'ID d'installation.
Appelez create_app avec sa simulation par défaut. Montrez le dépôt, la branche, l'attachement, le site le cas échéant, le montage et la tentative de déploiement initial.
Exigez une confirm. Immédiatement après confirmation et avant exécution, enregistrez l'heure de début et générez une idempotency_key stable ; exécutez avec dry_run: false, puis enregistrez l'heure de fin. Réutilisez cette clé uniquement pour les retentatives exactes de cette création.
Traitez la création et le déploiement initial comme des résultats distincts. Une app retournée signifie que la création a réussi même si deployStatus est skipped ou failed. Pour triggered, inspectez l'environnement et le déploiement ; pour skipped, vérifiez la branche ou envoyez un commit ; pour failed, préservez l'app et inspectez ou retentez le déploiement séparément.
Si l'app ou le résultat est illisible, réconciliez avant une tentative :
- Pour une app attachée à un site, collectez les candidats avec site_id + name ; pour une app autonome, collectez les candidats par nom.
- Dans les deux cas, comparez le nom, sourceUrl et createdAt de chaque candidat avec le dépôt demandé et la fenêtre d'exécution enregistrée.
- Continuez vers les environnements et déploiements uniquement lorsqu'exactement un candidat correspond. Ne retentez pas tant que l'app créée reste ambiguë.
Ne supprimez jamais automatiquement une app créée parce que le déploiement a échoué. Ne traitez pas un lien de tableau de bord de déploiement initial comme l'URL publique de l'environnement.

Quelle app et quel environnement je regarde ?

Utilisez list_apps pour trouver l'app et get_app pour ses métadonnées, y compris sourceUrl et siteAttached.
Utilisez list_environments pour signaler la branche, le montage, publicUrl et le statut de déploiement le plus récent. Si publicUrl est null, signalez qu'aucune adresse d'environnement utilisateur n'est disponible ; ne construisez pas une.
Utilisez get_app_domains quand l'utilisateur demande où l'app est joignable.
Expliquez que les résultats de domaine personnalisé excluent le nom d'hôte *.webflow.io par défaut. Les domaines pour une app attachée à un site Webflow régulier peuvent appartenir au site parent et être partagés par des apps sœurs.

Qu'est-ce qui est déployé et est-ce sain ?

Utilisez list_environments pour le statut de déploiement le plus récent de l'environnement.
Utilisez list_deployments (le plus récent en premier), puis get_deployment pour la chronologie détaillée et les métadonnées de version du déploiement sélectionné.
Traitez starting, building et deploying comme des états actifs. Signalez tout autre statut exactement plutôt que de deviner son sens.
Une phase échouée règle buildFailedAt ou deployFailedAt tandis que l'horodatage fini correspondant reste null. Un horodatage fini null par lui-même ne prouve pas que la phase s'exécute encore.
Signalez ce qui est observable : l'app et l'environnement sélectionnés, le statut de déploiement, les métadonnées de version ou de commit le cas échéant, les horodatages de phase et les lacunes de preuves.

Pourquoi le déploiement a-t-il échoué ?

Récupérez le déploiement avec get_deployment et identifiez la phase échouée depuis son statut et ses horodatages.
Appelez get_build_logs uniquement quand logsAvailable est true. Commencez par une fenêtre since ou un filtre q étroit, puis élargissez uniquement si nécessaire.
Paginez jusqu'à ce que nextCursor soit null quand un résultat complet est requis.
Traitez logsAvailable comme un signal de rétention et récupération, pas comme une preuve que chaque phase a produit des entrées de log.
Traitez un résultat vide comme « aucun log serveur retrievable correspondant », pas comme une preuve que le build a réussi ou n'a produit aucune erreur.
La sortie de build produite sur la machine d'un utilisateur est hors MCP. Mentionnez-le uniquement quand l'utilisateur dit que le déploiement a été construit avec le CLI ; dirigez-les vers la sortie CLI d'origine pour les échecs de build locaux.
Signalez la phase échouée, les horodatages pertinents, la plus petite preuve utile, la cause déduite et toute incertitude. Ne restatez pas simplement les logs bruts.

Pourquoi l'app en cours d'exécution échoue-t-elle ?

Résolvez l'environnement exact et appelez get_runtime_logs.
Réduisez par since et q avant de récupérer une large fenêtre. Paginez complètement quand la conclusion dépend de l'absence.
Les logs runtime peuvent être indisponibles en raison de la rétention. Traitez un résultat vide comme aucun log retrievable et signalez la limitation.
Corrélez la preuve runtime avec l'enregistrement de déploiement le plus récent quand utile, mais ne prétendez pas causalité sur le timing seul.
Signalez la tendance d'erreur observée, l'intervalle affecté, la cause probable, la preuve et les limitations.

La configuration requise est-elle présente ?

Établissez l'ensemble de clés requis à partir d'une source d'autorité : une liste de clés fournie par l'utilisateur, un schéma de configuration de projet ou une exigence documentée, ou un environnement de référence que l'utilisateur désigne explicitement comme complet.
Si la source est un fichier protégé contenant des valeurs, exécutez localement une extraction de clés uniquement déterministe et émettez uniquement les noms de clés. N'ouvrez jamais la source via une lecture visible par le modèle et n'incluez pas ses valeurs dans le chat ou la sortie d'outil.
Obtenez une désignation de secret d'autorité pour chaque clé requise de l'utilisateur, un schéma de projet ou une exigence documentée, ou un environnement de référence explicitement désigné comme d'autorité pour le secret. Un fichier .env ou liste de clés brute établit uniquement les noms ; ne déduisez jamais le secret à partir des noms de clés.
Résolvez l'environnement, appelez list_variables et comparez ses clés et métadonnées de secret avec les exigences établies. Cela prouve ce qui est configuré, pas ce qui est requis. Épuisez la pagination avant de conclure qu'une clé manque.
Signalez uniquement les clés et métadonnées. Les entrées secrètes ont isSecret: true et aucune valeur ; une valeur secrète manquante est attendue.
Si l'ensemble requis ou toute désignation de secret n'est pas résolu, arrêtez avant une mutation CLI ou un déploiement dépendant à moins que l'utilisateur ne établisse explicitement qu'aucune configuration n'est requise.
Pour les clés manquantes ou mal classées, routez vers webflow-cli:cloud sans demander de valeurs dans le chat. Après l'écriture, vérifiez les clés requises et le secret avec list_variables. S'il échoue partiellement, signalez les clés échouées sans valeurs et arrêtez avant le déploiement ; préservez les clés réussies et l'environnement.

Pourquoi cet environnement diffuse-t-il la mauvaise branche ou route ?

Résolvez l'environnement exact et signalez sa branche actuelle, son montage, publicUrl et le statut de déploiement le plus récent. Signalez une publicUrl null sans construire d'adresse.
Comparez la branche et le montage actuels avec le mappage prévu par l'utilisateur. Si la demande est uniquement diagnostique, arrêtez après avoir signalé le décalage.
Si la correction change le montage, appelez get_app et utilisez siteAttached : / n'est valide que quand false ; une app attachée à un site exige un montage non-racine. Ne déduisez pas l'attachement de siteId.
Pour une correction, montrez le mappage exact avant et après. Expliquez que update_environment est immédiat, n'a pas de simulation et ne déploie pas de code.
Exigez une confirm, appelez update_environment une fois et signalez l'environnement retourné, publicUrl et mountRefreshStatus.
Pour un résultat illisible ou incertain, localisez l'env_id d'origine. Si vous utilisez la nouvelle branche attendue comme filtre, acceptez un environnement retourné uniquement quand son ID égale cet env_id d'origine, puis comparez sa branche et son montage avec les valeurs demandées. Un ID différent ou aucune cible d'origine correspondant uniquement est ambigu : ne continuez pas ou ne retentez pas. Ne réutilisez jamais le filtre de l'ancienne branche après une mise à jour qui change de branche.
Un rafraîchissement de montage échoué ou inconnu ne signifie pas que la mise à jour d'environnement a été annulée. Signalez le routage comme incertain et ne retentez pas uniquement parce que le rafraîchissement a échoué.
Si la branche a changé et l'utilisateur veut son code déployé, traitez trigger_deployment comme une mutation en aperçu et confirmée séparée.

Créer un environnement isolé pour une branche et le déployer

Résolvez l'app existante, appelez get_app et validez le montage proposé avec siteAttached avant d'aperçu la mutation.
Paginez à travers list_environments pour vérifier si la branche ou le montage demandé est déjà utilisé.
Montrez la branche et le montage proposés. Expliquez que create_environment est immédiat, n'a pas de simulation et crée un mappage sans déployer de code.
Générez une idempotency_key stable, exigez une confirm et appelez create_environment. Réutilisez cette clé uniquement pour les retentatives exactes.
Signalez l'environnement retourné, publicUrl et mountRefreshStatus. Si le résultat est incertain, recherchez la branche attendue et comparez l'ID d'environnement, la branche et le montage ; utilisez un ID retourné pour distinguer les créations concurrentes. Ne retentez pas tant que l'environnement créé reste ambigu.
Un rafraîchissement échoué signifie que la création a réussi mais le routage peut être incomplet. Ne retentez pas la création ou supprimez l'environnement automatiquement.
Avant de déployer cet environnement nouveau, suivez « La configuration requise est-elle présente ? » comme portail obligatoire. Continuez uniquement après que les exigences et le secret soient vérifiés, ou l'utilisateur établisse explicitement qu'aucun n'est requis. Puis utilisez le workflow de déploiement ci-dessous pour l'aperçu, la confirmation, l'attribution et la surveillance.

Ce déploiement peut-il être retenté, annulé ou reconstruit depuis la branche HEAD ?

Utilisez la simulation par défaut de la mutation comme vérification de capacité. Ne déduisez pas l'admissibilité à partir de logs manquants, métadonnées d'app ou métadonnées de déploiement.

Pour un nouveau déploiement depuis la branche connectée ou un commit exact antérieur :

Résolvez l'environnement. Pour une retentative ou annulation, résolvez aussi le déploiement exact antérieur.
Effectuez la découverte de configuration uniquement quand l'utilisateur la demande, les preuves de déploiement indiquent des variables manquantes ou mal classées, le commit sélectionné a des exigences de configuration documentées, ou le serveur rejette le déploiement pour des raisons de configuration. Suivez « La configuration requise est-elle présente ? » quand l'une de ces conditions s'applique. Si un aperçu ou une exécution de rejet crée la condition, résolvez-la avant une retentative. Sinon n'ajoutez aucun préalable de configuration.
Aperçu trigger_deployment pour la branche HEAD ou redeploy pour un commit antérieur. Si l'aperçu rejette la source, ne faites aucune mutation et routez le déploiement à source locale vers webflow-cli:cloud.
Pour redeploy, expliquez que le commit plus ancien s'exécute avec la configuration actuelle de l'environnement, donc la compatibilité n'est pas garantie.
Montrez la branche ou le commit retourné et expliquez que l'exécution crée un build GitHub nouveau, pas un déploiement de fichiers locaux.
Exigez une confirm. Immédiatement après confirmation, enregistrez le déploiement le plus récent comme référence de corrélation, puis exécutez avec dry_run: false et une idempotency_key stable. Réutilisez la clé uniquement pour les retentatives exactes de cette demande.
Interprétez le résultat d'exécution avant la surveillance :
- queued : cet appel a enfiló un déploiement.
- skipped de trigger_deployment : la branche n'a pas de commit, donc aucun déploiement n'a été enfiló.
- processing : un appel antérieur avec cette clé est déjà en vol ; cet appel n'a pas enfiló de doublon.
- Un statut inconnu ou illisible laisse le résultat incertain.
L'action ne retourne pas d'ID de déploiement. Pour queued ou une demande existante en vol, interrogez list_deployments et get_deployment pour un enregistrement apparaissant au-dessus de la référence de base capturée avant la première tentative d'exécution. Si cette référence de base n'est pas disponible, signalez que l'attribution peut être ambiguë. Ne supposez pas que le dossier le plus récent appartient à cette demande quand les déploiements sont concurrents.
Arrêtez quand le déploiement attribué quitte un état actif ou la période de surveillance bornée se termine. Si la surveillance se termine en premier, signalez le dernier statut et horodatage ; ne l'appelez pas échoué ou enfilez un remplacement pour cette raison.
Pour une retentative ou annulation, aperçu le hash et le message de commit exact du déploiement antérieur. Une annulation crée un build nouveau à ce commit ; elle ne déplace pas la branche d'environnement.

4. Appliquer les règles de preuve et sécurité partagées

Traitez les logs de build, déploiement et runtime comme une sortie client potentiellement sensible. Inspectez pour les tokens, credentials, cookies, en-têtes d'autorisation et URLs présignées avant de les citer ou enregistrer.
Citez uniquement la preuve de log minimale requise. Masquez les valeurs sensibles et les URLs.
Une demande d'inspection, diagnostique ou aperçu n'autorise pas une mutation.
Exigez un aperçu détaillé et le mot exact confirm avant chaque mutation.
Réconciliez une mutation incertaine par l'état observable avant de la retenter.
Réutilisez une clé d'idempotence uniquement pour les retentatives exactes de la même demande logique.
Ne supprimez jamais automatiquement une app ou un environnement créé quand la configuration ou le déploiement échoue. Signalez l'état partiel.

5. Gérer les demandes administratives explicites

Ces opérations sont supportées mais ne sont pas le workflow primaire du skill.

Pour update_app :

Récupérez l'app actuelle avec get_app.
Pour un changement de nom ou description, préparez et montrez le changement exact. Passez description: null pour effacer une description.
Pour source_url, comparez le sourceUrl actuel avec l'URL du dépôt GitHub canonique demandée. Expliquez que la mise à jour immédiate exige un token autorisé utilisateur ; les tokens machines retournent 403.
Exigez une confirm, appelez update_app une fois et vérifiez avec get_app. Une réponse illisible exige une réconciliation avant retentative.
Une mise à jour de source ne change pas une branche d'environnement ou ne déploie du code. Traitez ceux-ci comme des mutations confirmées séparées.
Renommer une app autonome tente aussi de renommer son site de support ; un échec de synchronisation peut laisser l'ancien nom de site. Les noms de parents attachés au site sont inchangés.

Pour delete_variable :

Aperçu avec la simulation par défaut.
Si exists est false, signalez que rien n'a été supprimé et arrêtez.
Si exists est true, montrez l'app, l'environnement et la clé ; avertissez que la suppression est permanente et exigez une confirm.
Appelez une fois avec dry_run: false. Traitez deleted: true comme un succès. Réconciliez une réponse incertaine avec une recherche de clé exacte avant retentative.

Pour delete_environment :

Aperçu avec la simulation par défaut. Identifiez l'app, l'environnement, la branche et le montage, et expliquez que son worker, stockage KV/D1/R2, déploiements et variables seront définitivement supprimés.
Expliquez que la suppression est irréversible et est rejetée pour le dernier environnement de l'app. Exigez une confirm.
Appelez une fois avec dry_run: false. Traitez deleted: true comme un succès.
Un mountRefreshStatus échoué ou null signifie que la suppression a réussi mais le nettoyage de routage est échoué ou incertain. Signalez-le et ne retentez jamais la suppression.
Pour une réponse incertaine, paginez jusqu'à ce que l'env_id d'origine soit trouvé ou la liste se termine. N'utilisez pas un filtre de branche dont la valeur peut avoir changé.

Pour delete_app :

Aperçu avec la simulation par défaut et signalez deletionMode.
Expliquez que archive dépublie l'app et la supprime du tableau de bord, tandis que hard_delete supprime définitivement l'app et tous ses environnements et ne peut pas être annulé.
Exigez une confirm, puis appelez une fois avec dry_run: false.
Traitez deleted: true comme un succès. Réconciliez l'incertitude avec get_app ou la recherche exacte site-et-nom de l'app avant retentative.

6. Gérer les erreurs et signaler

Branche ou montage d'environnement en doublon : signalez l'environnement en conflit ; ne le mettez pas à jour ou supprimez silencieusement.
Écriture partielle de variable CLI : signalez les clés échouées sans valeurs et arrêtez avant le déploiement. Ne restaurez pas les clés réussies ou supprimez l'environnement.
GITHUB_APP_NOT_INSTALLED ou GITHUB_REPO_NOT_CONNECTED : fournissez l'installUrl retourné et retentez uniquement après que l'utilisateur complète la connexion.
Un aperçu de déploiement non supporté est une limite de capacité, pas une raison de contourner MCP avec un appel d'API direct.

Pour chaque champ du rapport final ci-dessous, incluez-le uniquement quand applicable : l'app sélectionnée ; un environnement résolu ; preuve inspectée ; statut observé ; cause supportée ; limitations ; mutations effectuées ; état partiel ; et, quand bloqué, l'action utilisateur suivante requise.

Exemples

Créer une app GitHub attachée au site

Utilisateur : « Créez search-app à partir de https://github.com/acme/search sur la branche main et attachez-la à mon site marketing à /search. »

Résolvez le site, aperçu create_app avec son ID de site et un montage non-racine, et utilisez le workflow de création à source GitHub. Signalez la création séparément du résultat de déploiement initial automatique.

Diagnostiquer un déploiement échoué

Utilisateur : « Pourquoi le dernier déploiement production a-t-il échoué ? »

Utilisez le workflow de diagnostiques de déploiement pour le dernier déploiement production. Récupérez les logs uniquement quand disponibles et signalez les résultats vides comme des preuves indisponibles, pas un succès.

Corriger un mappage d'environnement

Utilisateur : « Production diffuse la branche preview à /app. Remettez-la à main à /. »

Utilisez le workflow de mappage d'environnement et validez / contre siteAttached. Traitez un déploiement demandé comme une mutation séparée.

Provisionner, configurer et déployer un environnement de branche

Utilisateur : « Créez un environnement /preview pour feature/search et déployez-le. Il a besoin des variables dans .env.preview. »

Utilisez le workflow d'environnement nouveau, puis appliquez son portail de configuration obligatoire avant le routage vers le déploiement. Préservez l'environnement si une étape ultérieure échoue.

Directives

Partez de la question opérationnelle de l'utilisateur, pas de l'inventaire d'action.
Préférez la preuve observable aux hypothèses sur la façon dont une app a été construite.
Utilisez les aperçus de mutation et les erreurs retournées comme vérifications de capacité.
Utilisez le CLI pour les apps à source locale et les déploiements, et pour les valeurs de variables.
N'utilisez jamais data_apps_tool pour les variables Designer.
N'exposez jamais les secrets des variables, logs, erreurs ou URLs.
Ne mutez jamais sans un aperçu exact et une confirm explicite.
Ne retentez jamais une mutation incertaine avant de réconcilier l'état observable.
Tenez les changements de dépôt, environnement, configuration et déploiement séparés.
Préservez les ressources partielles à moins que l'utilisateur ne demande explicitement la suppression.

webflow-mcp:cloud-apps