webflow-mcp:cloud-apps

Webflow Cloud アプリ

data_apps_tool を使用して、GitHub ソースのアプリを作成し、運用に関する質問に回答し、Webflow Cloud アプリの環境を管理します。ユーザーが実現したいことを起点に、必要な証拠だけを収集し、観察結果と結論を区別します。

CLI またはローカルソースのアプリの作成やデプロイ、あるいは環境変数の作成や更新が必要な場合は、webflow-cli:cloud スキルを使用します。クライアント側のビルド出力は Webflow に送信されず、MCP 経由で復元することもできません。

手順

1. 対象範囲を確認する

ユーザーのリクエストまたは既存のタスクコンテキストで確立された Webflow MCP 接続を使用します。アクティブな接続が 1 つだけの場合は、ユーザーにリージョンの選択や再確認を求めず、その接続を使用します。複数の接続がアクティブで、意図された対象が依然として不明確な場合は、対象に依存する操作を行う前に、ユーザーに確認を求めます。リソースの不足やアクセスエラーを解消するためにリージョンを切り替えてはいけません。

既存の MCP アプリまたは環境を、設定の書き込みやデプロイのために CLI に引き継ぐ前に、それらに設定されているリージョンを比較します。異なる場合、どちらかが正しいと決めつけたり、いずれかのツールの対象を黙って変更したりしてはいけません。明示されたタスクコンテキストから意図された対象を特定します。それでも競合が解決しない場合は、ユーザーに確認を求めます。競合が解決するまでは、依存する変更を一時停止します。

意図されたリージョンが確定したら、CLI が MCP の正確なアプリ ID と環境 ID を読み取れることを確認し、そのリージョンと ID を後続の変更に明示的に引き継ぎます。ログイン状態やリージョン名だけでは不十分です。確認に失敗した場合は、原因を推測せずに失敗を報告し、依存する変更を一時停止します。対象が確定している、独立した作業は続行します。

1. 他の Webflow MCP ツールを使用する前に、webflow_guide_tool を呼び出します。最新のガイドとアクションのスキーマが、現在の引数と応答についての基準です。
2. 環境変数の値を扱う明示的な CLI への引き継ぎを除き、Webflow の操作には Webflow MCP ツールを使用します。Webflow API を直接呼び出してはいけません。
3. すべてのツール呼び出しに必須の context パラメーターを含めます。三人称で 15〜25 語を記述します。
4. タスクに必要な機能に応じて使い分けます。
   • data_apps_tool は、GitHub ソースのアプリの作成、アプリ、環境、ドメイン、デプロイ記録、ログ、変数メタデータの確認、GitHub ソースと環境の管理、および GitHub デプロイのキュー登録に使用します。
   • data_variable_tool は、Designer のカラー、サイズ、フォント、CSS 変数に使用します。
   • webflow-cli:cloud は、CLI またはローカルソースのアプリ、ローカルビルドとデプロイ、環境変数の値の作成と更新に使用します。
5. data_apps_tool を利用できない場合は、Cloud Apps MCP 機能が有効になっていないことを報告します。直接 API リクエストで代用してはいけません。

環境変数の値やシークレットをチャットに貼り付けるよう、ユーザーに求めてはいけません。値の作成または更新は webflow-cli:cloud に委任し、非表示のプロンプト、標準入力、または保護されたファイルを必須とします。シークレットを位置引数として渡してはいけません。

2. 対象を特定する

次の順序で ID を特定します。

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

アプリ名はサイト内でのみ一意です。そのため、名前付きアプリは site_id + name で特定します。複数のリソースが一致する場合は、識別に役立つメタデータを提示し、変更前にユーザーに選択を求めます。フィルター、ページネーション、カーソル、アクションのバッチ処理の方法には、最新のガイドを使用します。

3. 該当するユーザーストーリーに従う

GitHub ソースのアプリを作成する

1. アプリ名、正規の GitHub リポジトリ URL、ブランチ、任意の説明、およびスタンドアロンにするか既存のサイトにアタッチするかを指定します。
2. サイトにアタッチするアプリの場合は、サイト ID を特定します。スタンドアロンの場合は site_id を省略します。
3. プレビューの前にマウントのルールを適用します。
   • スタンドアロンアプリは常に / にマウントされます。mount を省略するか、/ を指定します。
   • サイトにアタッチするアプリのデフォルトは /app です。/ は拒否され、デフォルトを上書きする場合は有効な非ルートのマウントパスが必要です。
4. スタンドアロンアプリの作成には、ワークスペーススコープのユーザートークンが必要であることを説明します。Webflow が GitHub のインストールを特定し、リポジトリへのアクセスを検証します。インストール ID は要求しないでください。
5. デフォルトのドライランで create_app を呼び出します。リポジトリ、ブランチ、アタッチの有無、該当する場合はサイト、マウント、および初回デプロイの試行を示します。
6. confirm を必須にします。確認の直後、実行の前に開始時刻を記録し、安定した idempotency_key を 1 つ生成します。dry_run: false で実行し、その後に完了時刻を記録します。そのキーは、この作成を正確に再試行する場合にのみ再利用します。
7. 作成と初回デプロイは別々の結果として扱います。アプリが返された場合、deployStatus が skipped または failed でも作成は成功しています。triggered の場合は環境とデプロイを確認します。skipped の場合はブランチを確認するか、コミットをプッシュします。failed の場合はアプリを維持し、デプロイを個別に確認または再試行します。
8. アプリまたは結果を読み取れない場合は、再試行の前に照合します。
   • サイトにアタッチするアプリの場合は site_id + name で候補を収集します。スタンドアロンアプリの場合は、名前で候補を収集します。
   • どちらの場合も、各候補の名前、sourceUrl、createdAt を、要求されたリポジトリおよび記録された実行時間帯と比較します。
   • 一致する候補がちょうど 1 つの場合にのみ、環境とデプロイの確認に進みます。作成されたアプリが曖昧なまま再試行しないでください。
9. デプロイに失敗しても、作成されたアプリを自動的に削除しないでください。初回デプロイのダッシュボードリンクを、環境の公開 URL として扱わないでください。

どのアプリと環境を見ていますか？

1. list_apps でアプリを見つけ、get_app で sourceUrl や siteAttached などのメタデータを取得します。
2. list_environments を使って、ブランチ、マウント、publicUrl、最新のデプロイステータスを報告します。publicUrl が null の場合は、ユーザー向けの環境アドレスが利用できないと報告し、アドレスを組み立てないでください。
3. アプリにアクセスできる場所をユーザーが尋ねた場合は、get_app_domains を使います。
4. カスタムドメインの結果には、デフォルトの *.webflow.io ホスト名が含まれないことを説明します。通常の Webflow サイトにアタッチされたアプリのドメインは、親サイトに属し、兄弟アプリ間で共有されている場合があります。

何がデプロイされ、正常に動作していますか？

1. 環境の最新のデプロイステータスには、list_environments を使います。
2. list_deployments で新しい順に一覧表示し、選択したデプロイの詳細なタイムラインとバージョンメタデータには get_deployment を使います。
3. starting、building、deploying は進行中の状態として扱います。それ以外のステータスは、意味を推測せず、そのまま報告します。
4. フェーズが失敗すると、対応する終了時刻が null のまま buildFailedAt または deployFailedAt が設定されます。終了時刻が null であることだけでは、そのフェーズがまだ実行中だとは証明できません。
5. 確認できる内容を報告します。選択したアプリと環境、デプロイステータス、返された場合はバージョンまたはコミットのメタデータ、フェーズのタイムスタンプ、および証拠の不足点を示します。

デプロイが失敗したのはなぜですか？

1. get_deployment でデプロイを取得し、ステータスとタイムスタンプから失敗したフェーズを特定します。
2. logsAvailable が true の場合にのみ get_build_logs を呼び出します。まず狭い since の範囲または q フィルターを指定し、必要な場合にのみ範囲を広げます。
3. 完全な結果が必要な場合は、nextCursor が null になるまでページを取得します。
4. logsAvailable はログの保持と取得のシグナルとして扱い、すべてのフェーズでログエントリが生成された証拠とは見なしません。
5. 結果が空の場合は、「取得可能なサーバー側ログに一致するものがない」と扱い、ビルドが成功した、またはエラーが発生しなかった証拠とは見なしません。
6. ユーザーのマシンで生成されたビルド出力は MCP の対象外です。デプロイが CLI でビルドされたとユーザーが述べた場合に限り、この点に触れ、ローカルのビルド失敗については元の CLI 出力を確認するよう案内します。
7. 失敗したフェーズ、関連するタイムスタンプ、必要最小限の証拠、推定原因、不確実な点を報告します。生ログをそのまま言い換えるだけにしないでください。

実行中のアプリが失敗するのはなぜですか？

1. 正確な環境を特定し、get_runtime_logs を呼び出します。
2. 広い範囲を取得する前に、since と q で絞り込みます。結論がログの不在に依存する場合は、すべてのページを取得します。
3. 保持期間のため、ランタイムログを取得できないことがあります。結果が空の場合は、取得可能なログがないものとして扱い、その制限を報告します。
4. 役立つ場合は、ランタイムの証拠を最新のデプロイ記録と照合します。ただし、タイミングだけを根拠に因果関係を断定しないでください。
5. 観測されたエラーパターン、該当する期間、考えられる原因、証拠、制限事項を報告します。

必要な設定は存在しますか？

1. ユーザーが提示したキーのリスト、プロジェクトの設定スキーマや文書化された要件、またはユーザーが完全なものとして明示的に指定した参照環境など、信頼できる情報源から必須キーのセットを確定します。
2. 情報源が値を含む保護されたファイルの場合は、キーのみをローカルで決定的に抽出し、キー名だけを出力します。モデルから読み取れる方法で情報源を開いたり、その値をチャットやツール出力に含めたりしないでください。
3. 必須キーごとに、ユーザー、プロジェクトのスキーマや文書化された要件、または秘密性の判定元として明示的に指定された参照環境から、信頼できる秘密情報の指定を取得します。.env ファイルや単なるキーのリストから確認できるのは名前だけです。キー名から秘密情報かどうかを推測しないでください。
4. 環境を特定し、list_variables を呼び出して、キーと秘密性のメタデータを確定した要件と照合します。これにより確認できるのは設定済みの項目であり、必須項目ではありません。キーが欠落していると結論付ける前に、すべてのページを取得します。
5. キーとメタデータのみを報告します。シークレット項目は isSecret: true で値を含みません。シークレットの値がないのは想定どおりです。
6. 必須項目のセットまたは秘密性の指定が未確定の場合、ユーザーが設定は不要だと明示的に確定しない限り、CLI での変更やそれに依存するデプロイを行う前に停止します。
7. キーが欠落している場合や分類が誤っている場合は、チャットで値を求めずに webflow-cli:cloud に引き継ぎます。書き込み後、list_variables で必須キーと秘密性を検証します。一部が失敗した場合は、値を含めずに失敗したキーを報告し、デプロイの前に停止します。成功したキーと環境は維持します。

この環境で誤ったブランチまたはルートが使われているのはなぜですか？

1. 正確な環境を特定し、現在のブランチ、マウント、publicUrl、最新のデプロイ状況を報告します。publicUrl が null の場合は、アドレスを組み立てずに null と報告します。
2. 現在のブランチとマウントを、ユーザーが意図したマッピングと比較します。リクエストが診断のみの場合は、不一致を報告した時点で終了します。
3. 修正によってマウントが変更される場合は、get_app を呼び出し、siteAttached を使用します。/ が有効なのは false の場合のみです。サイトがアタッチされたアプリには、ルート以外のマウントが必要です。siteId からアタッチ状態を推測しないでください。
4. 修正する場合は、変更前と変更後のマッピングを正確に示します。update_environment は即時に反映され、ドライランはなく、コードもデプロイしないことを説明します。
5. confirm を必須とし、update_environment を一度だけ呼び出します。返された環境、publicUrl、mountRefreshStatus を報告します。
6. 結果を読み取れない、または不確かな場合は、元の env_id を特定します。想定される新しいブランチをフィルターとして使用する場合、返された環境の ID が元の env_id と一致する場合に限り、その環境を受け入れ、そのブランチとマウントをリクエストされた値と比較します。ID が異なる場合、または元の対象を一意に特定できない場合は、結果が曖昧です。続行も再試行もしないでください。ブランチ変更を伴う更新の後に、古いブランチフィルターを再利用しないでください。
7. マウントの更新に失敗した場合や状態が不明な場合でも、環境の更新がロールバックされたことを意味するわけではありません。ルーティングは不確かであると報告し、更新失敗だけを理由に再試行しないでください。
8. ブランチが変更され、ユーザーがそのコードのデプロイを希望する場合は、trigger_deployment を個別にプレビューして、確認を得てから行う変更として扱います。

ブランチ用の分離された環境を作成してデプロイする

1. 既存のアプリを特定し、get_app を呼び出して、変更をプレビューする前に siteAttached を使って提案するマウントを検証します。
2. list_environments でページをめくりながら、リクエストされたブランチまたはマウントがすでに使用中かどうかを確認します。
3. 提案するブランチとマウントを示します。create_environment は即時に実行され、ドライランはなく、コードをデプロイせずにマッピングを作成することを説明します。
4. 変更せずに再試行する場合に使う、安定した idempotency_key を1つ生成し、confirm を必須として、create_environment を呼び出します。そのキーは、内容が完全に同一の再試行に限り再利用します。
5. 返された環境、publicUrl、mountRefreshStatus を報告します。結果が不確かな場合は、想定されるブランチを検索し、環境 ID、ブランチ、マウントを比較します。返された ID を使って、同時に行われた作成と区別します。作成された環境の特定が曖昧な間は再試行しないでください。
6. 更新に失敗した場合は、作成自体は成功したものの、ルーティングが未完了の可能性があります。作成を再試行したり、環境を自動的に削除したりしないでください。
7. この新しい環境をデプロイする前に、「必要な設定は揃っていますか？」に従い、必須の確認を行います。必要な設定と機密性が確認されるか、必要な設定がないことをユーザーが明示した場合にのみ続行します。その後、以下のデプロイワークフローに従い、プレビュー、確認、実行者の記録、モニタリングを行います。

このデプロイは、再試行、ロールバック、またはブランチ HEAD からの再ビルドが可能ですか？

ミューテーションのデフォルトのドライランを機能確認に使用してください。ログ、アプリのメタデータ、またはデプロイのメタデータがないことから、実行可能かどうかを推測しないでください。

接続されたブランチまたは以前の特定のコミットから新しいデプロイを行う場合：

1. 環境を特定します。再試行またはロールバックの場合は、以前の特定のデプロイも特定します。
2. ユーザーが要求した場合、デプロイの証拠から変数の不足または分類誤りが示される場合、選択したコミットに文書化された構成要件がある場合、または構成上の理由でサーバーがデプロイを拒否した場合に限り、構成の検出を行います。これらの条件のいずれかに当てはまる場合は、「必須の構成は存在しますか？」に従ってください。プレビューまたは実行時の拒否によって条件が発生した場合は、再試行する前に解決してください。それ以外の場合、構成を前提条件に追加しないでください。
3. ブランチ HEAD に対しては trigger_deployment、以前のコミットに対しては redeploy をプレビューします。プレビューでソースが拒否された場合、ミューテーションは行わず、ローカルソースのデプロイを webflow-cli:cloud に案内してください。
4. redeploy の場合、古いコミットは環境の現在の構成で実行されるため、互換性は保証されないことを説明してください。
5. 返されたブランチまたはコミットを示し、実行によってローカルファイルのデプロイではなく、新しい GitHub ビルドが作成されることを説明してください。
6. confirm を必須とします。確認の直後に、最新のデプロイを相関付けの基準点として記録し、その後 dry_run: false と、一貫した idempotency_key を使って実行します。このキーは、このリクエストを正確に再試行する場合に限り再利用してください。
7. 監視を開始する前に、実行結果を解釈してください：
   • queued：この呼び出しによってデプロイがキューに登録されました。
   • trigger_deployment からの skipped：ブランチにコミットがないため、デプロイはキューに登録されませんでした。
   • processing：このキーを使用した以前の呼び出しがすでに処理中です。この呼び出しによって重複はキューに登録されませんでした。
   • 不明または読み取れないステータスの場合、結果は不確かなままです。
8. このアクションはデプロイ ID を返しません。queued の場合、または既存のリクエストが処理中の場合は、最初の実行試行の前に記録した基準点より後に現れるレコードを list_deployments と get_deployment でポーリングします。その基準点が取得できない場合は、対象の特定が曖昧になる可能性があることを報告してください。デプロイが同時進行している場合、最新のレコードがこのリクエストに属すると決めつけないでください。
9. 対象のデプロイがアクティブ状態を抜けるか、制限付きの監視期間が終了した時点で停止します。監視期間が先に終了した場合は、最後に確認できたステータスとタイムスタンプを報告してください。その理由で失敗と判断したり、代わりのデプロイをキューに登録したりしないでください。
10. 再試行またはロールバックの場合は、以前のデプロイの正確なコミットハッシュとメッセージをプレビューします。ロールバックでは、そのコミットから新しいビルドを作成します。環境のブランチを移動するわけではありません。

4. 共通の証拠と安全性に関するルールを適用する

• ビルド、デプロイ、およびランタイムのログは、機密性の高い顧客出力である可能性があるものとして扱ってください。引用または保存する前に、トークン、認証情報、Cookie、認証ヘッダー、および署名付き URL が含まれていないか確認してください。
• 必要最小限のログ証拠のみを引用してください。機密情報や URL は編集して隠してください。
• 調査、診断、またはプレビューの依頼は、ミューテーションの許可を意味しません。
• すべてのミューテーションの前に、項目別のプレビューを提示し、正確な語句 confirm を求めてください。
• ミューテーションの結果が不確かな場合は、再試行する前に観測可能な状態を確認してください。
• 冪等性キーは、同一の論理リクエストを正確に再試行する場合に限り再利用してください。
• 構成またはデプロイが失敗した場合でも、新しく作成したアプリや環境を自動的に削除しないでください。部分的な状態を報告してください。

5. 明示的な管理リクエストに対応する

これらの操作はサポートされていますが、このスキルの主要なワークフローではありません。

update_app の場合：

1. get_app で現在のアプリを取得します。
2. 名前または説明を変更する場合は、変更内容を正確に用意して提示します。説明をクリアするには description: null を渡します。
3. source_url については、現在の sourceUrl と、指定された正規の GitHub リポジトリ URL を比較します。即時更新にはユーザーが承認したトークンが必要であり、マシントークンでは 403 が返されることを説明します。
4. confirm を必須とし、update_app を一度呼び出してから、get_app で確認します。応答が読み取れない場合は、再試行する前に状態を照合する必要があります。
5. ソースを更新しても、環境ブランチやデプロイされるコードは変更されません。これらは別個の、確認が必要な変更として扱います。
6. スタンドアロンアプリの名前を変更すると、紐付くサイトの名前の変更も試みられます。同期に失敗すると、古いサイト名が残る場合があります。サイトに紐付いた親の名前は変更されません。

delete_variable の場合：

1. デフォルトのドライランでプレビューします。
2. exists が false の場合は、何も削除されなかったことを報告して終了します。
3. exists が true の場合は、アプリ、環境、キーを提示します。削除は取り消せないことを警告し、confirm を必須とします。
4. dry_run: false を指定して一度呼び出します。deleted: true を成功として扱います。応答が不確かな場合は、再試行する前にキーを完全一致で検索して状態を照合します。

delete_environment の場合：

1. デフォルトのドライランでプレビューします。アプリ、環境、ブランチ、マウントを特定し、そのワーカー、KV/D1/R2 ストレージ、デプロイ、変数が完全に削除されることを説明します。
2. 削除は取り消せず、アプリの最後の環境は削除できないことを説明します。confirm を必須とします。
3. dry_run: false を指定して一度呼び出します。deleted: true を成功として扱います。
4. mountRefreshStatus が失敗または null の場合、削除は成功したものの、ルーティングのクリーンアップに失敗したか、状態が不確かであることを意味します。その旨を報告し、削除を再試行してはいけません。
5. 応答が不確かな場合は、元の env_id が見つかるか、一覧の終端に達するまでページネーションで取得します。値が変更されている可能性のあるブランチフィルターは使用しないでください。

delete_app の場合：

1. デフォルトのドライランでプレビューし、deletionMode を報告します。
2. archive はアプリの公開を解除してダッシュボードから削除し、hard_delete はアプリとすべての環境を完全に削除して元に戻せないことを説明します。
3. confirm を必須とし、その後 dry_run: false を指定して一度呼び出します。
4. deleted: true を成功として扱います。不確かな場合は、再試行する前に get_app またはアプリのサイト名と名前を完全一致で検索して状態を照合します。

6. エラーに対応して報告する

• 環境のブランチまたはマウントが重複している場合：競合する環境を報告します。通知なしに更新または削除してはいけません。
• CLI による変数書き込みが一部失敗した場合：値を含めずに失敗したキーを報告し、デプロイする前に停止します。成功したキーをロールバックしたり、環境を削除したりしてはいけません。
• GITHUB_APP_NOT_INSTALLED または GITHUB_REPO_NOT_CONNECTED の場合：返された installUrl を提示し、ユーザーが接続を完了してからのみ再試行します。
• サポートされていないデプロイプレビューは機能上の制約であり、MCP を迂回して直接 API を呼び出す理由にはなりません。

以下の最終報告の各項目は、該当する場合にのみ含めます。選択したアプリ、解決した環境、確認した証拠、観測されたステータス、裏付けのある原因、制約、実行した変更、部分的な状態、そして処理がブロックされた場合はユーザーに必要な次の操作。

例

サイトに紐付いた GitHub アプリを作成する

ユーザー：「main ブランチの https://github.com/acme/search から search-app を作成し、マーケティングサイトの /search に紐付けてください。」

サイトを特定し、そのサイト ID とルート以外のマウントを指定して create_app をプレビューし、GitHub ソースからの作成ワークフローを使用します。作成結果と自動で行われる初回デプロイの結果は、分けて報告します。

失敗したデプロイを診断する

ユーザー：「最新の本番デプロイが失敗した理由は何ですか？」

最新の本番デプロイに対して、デプロイ診断ワークフローを使用します。ログを取得するのは利用可能な場合に限り、結果が空の場合は成功ではなく、証拠を利用できなかったと報告します。

環境マッピングを修正する

ユーザー: 「Production は /app でプレビュー ブランチを配信しています。/ で main に戻してください。」

環境マッピングのワークフローを使用し、siteAttached に対して / を検証します。デプロイのリクエストは、別の変更として扱います。

ブランチ環境をプロビジョニング、設定、デプロイする

ユーザー: 「feature/search 用に /preview 環境を作成してデプロイしてください。.env.preview の変数が必要です。」

新しい環境のワークフローを使用し、デプロイに進む前に必須の設定ゲートを適用します。後続の手順が失敗しても、環境は保持します。

ガイドライン

• アクションの一覧ではなく、ユーザーの運用上の質問から始めます。
• アプリの構築方法を推測するより、観測可能な証拠を優先します。
• 変更のプレビューと返されたエラーを、機能の確認に利用します。
• ローカルソースのアプリとデプロイ、および変数の値には CLI を使用します。
• Designer の変数に data_apps_tool を使用しないでください。
• 変数、ログ、エラー、URL からシークレットを決して公開しないでください。
• 正確なプレビューと明示的な confirm なしに変更を加えないでください。
• 不確実な変更を再試行する前に、観測可能な状態を照合してください。
• リポジトリ、環境、設定、デプロイの変更は分けて扱います。
• ユーザーが明示的に削除を求めない限り、部分的に作成されたリソースを保持します。