/cloud-apps

name: webflow-mcp:cloud-apps
description: Create GitHub-source Webflow Cloud apps and monitor, troubleshoot, or manage existing apps through Webflow MCP. Use when creating a standalone or site-attached app from GitHub; identifying apps or environments; checking public URLs, domains, configuration keys, or deployed versions; diagnosing failures; changing a GitHub source, branch, or mount; provisioning environments; or previewing a deployment, retry, or rollback. Do not use for Designer/CSS variables, CLI/local-source app creation or deployment, or passing environment-variable values through MCP.

Webflow Cloud Apps

Use `data_apps_tool` to create GitHub-source apps, answer operational questions, and manage environments for Webflow Cloud apps. Start from the user's outcome, gather only the evidence needed, and distinguish observations from conclusions.

Use the `webflow-cli:cloud` skill when the task requires CLI/local-source app creation or deployment, or creating or updating environment variables. Client-side build output is not sent to Webflow and cannot be recovered through MCP.

Instructions

1. Establish scope

Use the Webflow MCP connection established by the user's request or existing task context. If only one connection is active, use it without asking the user to choose or reconfirm a region. If multiple connections are active and the intended target remains ambiguous, ask the user to disambiguate before proceeding with target-dependent operations. Do not switch regions to recover from missing resources or access errors.

Before handing an existing MCP app or environment to the CLI for configuration writes or deployment, compare their configured regions. If they differ, do not assume either is correct or silently retarget either tool. Resolve the intended target from explicit task context; if that does not resolve the conflict, ask the user. Pause dependent mutations until the conflict is resolved.

Once the intended region is established, verify that the CLI can read the exact MCP app and environment IDs, and carry that region and those IDs explicitly into subsequent mutations. Login status or a region label alone is insufficient. If verification fails, report the failure without inferring its cause and pause dependent mutations. Continue independent work whose target is established.

1. Call `webflow_guide_tool` before any other Webflow MCP tool. The live guide and action schemas are authoritative for current arguments and responses. 2. Use Webflow MCP tools for Webflow operations except the explicit CLI handoff for environment-variable values. Never call Webflow APIs directly. 3. Include the required `context` parameter in every tool call. Write 15-25 words in third-person perspective. 4. Route by the capability the task requires:

• Use `data_apps_tool` to create GitHub-source apps; inspect apps,

environments, domains, deployment records, logs, and variable metadata; manage GitHub sources and environments; and enqueue GitHub deployments.

• Use `data_variable_tool` for Designer color, size, font, and CSS variables.
• Use `webflow-cli:cloud` for CLI/local-source apps, local builds and

deployments, or creating and updating environment-variable values. 5. If `data_apps_tool` is unavailable, report that the Cloud Apps MCP capability is not enabled. Do not bypass it with a direct API request.

Never ask the user to paste an environment-variable value or secret into chat. For a create or update, delegate to `webflow-cli:cloud` and require a hidden prompt, stdin, or protected file. Never pass a secret as a positional argument.

2. Resolve the target

Discover identifiers in this order:

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

App names are unique only within a site, so resolve a named app with `site_id + name`. If multiple resources match, present distinguishing metadata and require the user to select one before any mutation. Use the live guide for filter, pagination, cursor, and action-batching mechanics.

3. Follow the matching user story

Create a GitHub-source app

1. Establish the app name, canonical GitHub repository URL, branch, optional description, and whether it is standalone or attached to an existing site. 2. For a site-attached app, resolve the site ID. Omit `site_id` for standalone. 3. Apply the mount contract before previewing:

• A standalone app always mounts at `/`; omit `mount` or use `/`.
• A site-attached app defaults to `/app`, rejects `/`, and requires a valid

non-root mount when overriding the default. 4. Explain that standalone creation requires a workspace-scoped user token. Webflow derives the GitHub installation and validates repository access; do not request an installation ID. 5. Call `create_app` with its default dry run. Show the repository, branch, attachment, site when applicable, mount, and initial-deployment attempt. 6. Require `confirm`. Immediately after confirmation and before execution, record the start time and generate one stable `idempotency_key`; execute with `dry_run: false`, then record the completion time. Reuse that key only for exact retries of this creation. 7. Treat creation and initial deployment as separate outcomes. A returned app means creation succeeded even if `deployStatus` is `skipped` or `failed`. For `triggered`, inspect the environment and deployment; for `skipped`, check the branch or push a commit; for `failed`, preserve the app and inspect or retry deployment separately. 8. If the app or outcome is unreadable, reconcile before retrying:

• For a site-attached app, collect candidates with `site_id + name`; for a

standalone app, collect candidates by name.

• In both cases, compare each candidate's name, `sourceUrl`, and `createdAt`

with the requested repository and recorded execution window.

• Continue to environments an