Webflow Developers Updates & Release Notes

New tools

MCP v2.1 introduces three new tools that open up areas of Webflow the MCP server couldn't reach before: Interactions with GSAP, Webflow Cloud, and Campaigns.

Interactions with GSAP

Agents can now bring pages to life with motion and interactivity. Interactions with GSAP is Webflow's visual animation tool, built on GSAP, the popular open source animation library, and MCP v2.1 opens it to agents for the first time. You keep complete authoring control over the result: an agent makes the first pass, and you tweak the details on the timeline and in the visual editor. Agents can now:

• Create an interaction from a complete definition, its triggers and its timelines, in a single call.
• Animate on click, hover, page load, scroll, mouse move, and custom events.
• Update an existing interaction, or remove one.
• List a site's interactions and read one with its timelines resolved.

Webflow Cloud

Agents can now take a broken deployment from error to fix without leaving the editor you work in. Webflow Cloud is Webflow's platform for building and hosting full-stack applications, and MCP v2.1 brings its apps, environments, and deployments into reach. An agent can read a failing build's logs, make the change, and redeploy, instead of you moving between the command line and the dashboard. Agents can now:

• Create, list, and inspect apps built from a GitHub repository, change an app's name, description, or source, and archive or permanently delete one.
• Set up environments that map a Git branch to a mount point on the app, then list, update, or delete them.
• Deploy the connected branch's latest commit, or redeploy an earlier deployment's exact commit to retry a failure or roll back.
• Track deployments by status, commit, build timings, build size, and framework, listed newest first.
• Read build and runtime logs to find out why a deploy failed or what an app is doing in production.
• List environment variables, which return values for non-secret entries only, and delete one by key.
• List the custom domains the app's site serves on.
• Preview a destructive or deploy action with a dry run before committing to it, and pass an idempotency key so a retried call does not deploy twice.

Campaigns

Agents can now help marketers get a campaign out the door. Campaigns is Webflow's new standalone tool for demand gen and performance marketers to create, launch, and measure on-brand campaigns with fewer handoffs, and MCP v2.1 opens it to agents from the start. An agent can turn a brief into a landing page, build personalized variations for each audience, and report on what the campaign did. Agents can now:

• Find the sites in a workspace that have Campaigns enabled, and list the campaigns on one.
• Create a campaign and its landing page from a markdown brief. The page generates in the background, and a task status action reports when it is finished.
• Read and update a campaign's name and brief, which does not regenerate the landing page, or delete a campaign along with its landing page record and generated assets.
• Create page variations from suggested audiences or from your own name, slug, and summary, then update up to 30 of them in a single call.
• Personalize an element setting or a component instance prop by creating a campaign field bound to it, then rename that field or remove it across every variation.
• Measure a campaign by daily sessions, users, or pageviews, form submission counts, the companies that engaged, and CRM opportunity totals for open and closed-won deals.

Updates on existing tools

Two tools already in the server gained new actions or capabilities in v2.1:

• data_pages_tool adds the rest of the branch lifecycle. Alongside creating, listing, reading, and deleting branches, agents can now pull the latest changes from a site's main pages into a branch (update_branch), merge a branch back into main (merge_branch), publish a branch's preview to its staging domain (publish_branch), and read a branch's unresolved conflicts without attempting a merge (get_branch_conflicts). Branch actions require the site's workspace to be on an Enterprise plan, and the mutations run asynchronously, returning a task ID to poll with get_branch_task_status.
• data_cms_tool adds field groups and richer item queries. Agents can now read a collection's field groups along with the fields eligible for grouping (get_collection_field_groups), and replace the full ordered set (update_collection_field_groups) — a collection holds up to 50 groups, and field groups are not available on Ecommerce collections. list_collection_items can also filter and sort on custom fields: filter with bracket notation (filter[price][gte]=10), with operators that vary by field type (eq, ne, in, nin, gt/gte/lt/lte on numbers and dates, contains/ncontains on text, and exists everywhere), and sort with sort[price]=desc on sortable field types. A request allows up to 10 filter terms and 3 sort fields.

Agent instructions

Agents can now write the guidance they work from. In v2.0, agents could search, read, create, update, move, and delete a site's rules and skills. MCP v2.1 adds generation, so an agent can produce an instruction from the site itself.

Four types can be generated: brand guidelines, design system, asset guidelines, and CMS guidelines. The first three read the current Webflow site by default and can take one public URL as supplementary evidence, which helps when the brand lives on a marketing site hosted elsewhere. CMS guidelines read a specific collection instead, and take no supplementary source.

Generation runs asynchronously: the first call returns a task ID, and the same action polls it until the job finishes or fails, at which point the result carries the draft's path and resource URI. Starting a generation needs agent_instructions:write, while polling needs only agent_instructions:read. Every generated instruction is saved as a draft, so review it before treating it as durable site guidance, since once in place it becomes context that every agent working on that site reads.

Generating an instruction consumes AI credits; polling does not. The credits are spent by the Webflow agents that analyze the site or collection and draft the instruction — the task status check is a plain read.

Migrating from an earlier version

Nothing to do if you are already on v2.0.1. No tool or action names changed in v2.1, so skills, prompts, and automations written against 2.0.1 keep resolving, and everything in this release is additive.

Known limitations

A few limitations to be aware of in this release:

• Interactions with GSAP only. Agents cannot see or edit Classic interactions. On a site that uses Classic, asking an agent for a site's interactions returns an empty result, which looks the same as a site that has none. An agent can still add an interaction there, which leaves the site running both versions but carries a performance cost. The Interactions panel shows one version at a time, so switch the version dropdown at the bottom of the panel to Interactions with GSAP to see what an agent created.
• Webflow Cloud keeps secrets out of MCP. Environment variable values cannot be set through MCP, and listing variables returns values for non-secret entries only. Set variables with the Webflow CLI. Deployment through MCP works only on apps connected to a GitHub repository. Build and runtime logs are returned unsanitized and may contain secrets.
• Campaigns is in Early Access. The Campaigns tool works only on sites in the Early Access program. It covers building and measuring rather than launching: connecting marketing forms and pushing assets to ad platforms stay in the Campaigns interface. A published page variation cannot be deleted, and deleting a campaign permanently removes its landing page record and its generated assets.
• Element snapshots still require the bridge app.element_snapshot_tool captures a visual snapshot of an element, letting an agent understand the current state of a site and verify its own changes without publishing. This still depends on a live Designer session via the Webflow MCP Bridge App. We're working to make it headless, and until then we recommend letting the agent publish to a staging domain, which unlocks full agent loops that can run independently of the Designer.
• Custom fonts don't cover remotely hosted Google or Adobe Fonts.data_fonts_tool manages a site's uploaded font files only. Remotely hosted Google and Adobe Fonts must still be managed manually in site settings. For Google Fonts, you can download the font files locally and then upload and manage them through the MCP server.
• Some uploads require direct access to Amazon S3. Uploading an asset (data_assets_tool.create_asset) and uploading or replacing a custom font file (data_fonts_tool.create_font and replace_font_file) use a two-step flow: the tool returns a presigned Amazon S3 URL, and the client is expected to send the file's bytes directly to that URL. If the client's environment or network blocks outbound requests to S3, that second step cannot complete and the upload fails. When that happens, upload the file manually in Webflow (for example, the Designer's asset panel for assets, or site settings for fonts) rather than through the MCP server.
• One workspace per authorization. When you authorize the MCP server, you choose which workspace it can access, and only a single workspace can be selected. To use the MCP server with a different workspace, you will need to reauthenticate. In the case of Claude, OpenAI and others, this means removing the connector/app and reinstalling it.

v2.8.0 introduces webflow apps, the new canonical command namespace for managing Webflow Cloud apps.

It replaces the piecemeal webflow cloud commands with one consistent surface across the whole app lifecycle, designed so a CI job or an AI agent can drive it end-to-end without scraping human-oriented output: structured --json on read commands, --dry-run previews on every write, and predictable exit codes throughout. Reads also retry transient rate limits (429) automatically with bounded backoff, so a busy CI runner doesn't need its own retry loop.

webflow cloud init and webflow cloud deploy keep working unchanged — they now print a one-time deprecation notice pointing at the apps equivalents.

An app is standalone by default — it gets its own subdomain and isn't tied to a Webflow site. Attaching to an existing site (mounted at a path, alongside a Designer-built site) is fully supported too; it's just one additional flag away.

App lifecycle: apps init / apps deploy

Standalone — the default. Owns its own subdomain, no Webflow site involved.

webflow apps init -n my-app -f astro --new -w <workspaceId>
webflow apps deploy -e main

Once webflow.json has an app_id, subsequent apps deploy calls need no flags at all — it's the standalone path that gets simpler over time, since there's no site or mount path to keep in sync.

apps deploy also takes --dry-run and --json, same as every other write in this namespace:

webflow apps deploy -e main --dry-run
webflow apps deploy -e main --json

--dry-run resolves everything from flags, WEBFLOW_APP_ID, and webflow.json — no network calls, no prompts, no changes — and reports which of create / deploy / select the real run would take. --json suppresses the build/upload progress output and emits a single document: {appId, environmentId, deploymentId, deployUrl} on success, an error document on failure, or the dry-run plan when combined with --dry-run.

Attaching to an existing Webflow site instead just adds --site-id and a --mount path at init:

Site-attached — mounted at a path on an existing Webflow site.

webflow apps init -n my-app -f astro -s <siteId> -m /app
webflow apps deploy -e main --site-id <siteId> --mount /app

apps init also supports creating an app directly from an existing GitHub repository, either standalone or attached to a site:

webflow apps init --import https://github.com/<owner>/<repo> --new --dry-run
webflow apps init --import https://github.com/<owner>/<repo> --site-id <siteId> --mount /app --dry-run
webflow apps init --import https://github.com/<owner>/<repo> --new --skip-clone
webflow apps init --import https://github.com/<owner>/<repo> --branch staging --new --idempotency-key $GITHUB_RUN_ID-$REPOSITORY

The Webflow GitHub App must be installed on the repository and connected to your workspace. --dry-run previews the app that would be created; --branch picks which branch to build (defaults to the repository's default branch); --skip-clone creates the app from the remote repository without cloning it into a local directory. --idempotency-key is required for non-interactive runs (CI, --no-input) — reuse a retry-stable key unique to the repository and target so a retry replays the original app instead of creating a second one.

Link an existing app: apps link

webflow apps link <appId> --workspace-id <workspaceId> --dry-run

Points the current directory at an app and environment that already exist by writing the resolved IDs into webflow.json. It only verifies the app — it doesn't create or deploy anything, so it's the fastest way to get a checked-out repo working with apps deploy / apps env-vars / apps logs against an app someone else created. A workspace ID is persisted only when --workspace-id is passed explicitly, since it can't be derived or verified from the app itself. Use --dry-run to preview.

Inspect apps: apps list / apps get / apps domains

webflow apps list --json
webflow apps get <appId> --fields id,name,siteId,sourceUrl --json
webflow apps domains <appId>

list returns every app the token can see — standalone and site-attached alike — and optionally narrows with an exact --site or --name, or a case-insensitive substring --q; combine --site and --name to resolve to at most one app. All three support --fields to project columns and --json for machine-readable output.

Manage apps: apps update / apps delete

webflow apps update <appId> --name "New name" --description "Internal tools dashboard" --dry-run --json
webflow apps update <appId> --github-source https://github.com/<owner>/<repo> --json
webflow apps delete <appId> --dry-run --json
webflow apps delete <appId> --yes --json

Update an app's name, description, and/or GitHub source (at least one of --name / --description / --github-source is required). --github-source attaches a repository to an app that has none, or repoints one that already has a different repo — it doesn't deploy on its own, so follow it with apps deployments trigger. apps delete deletes (archives) an app outright; it refuses to run non-interactively without --yes (a safe --dry-run preview is exempt).

Both commands preview with --dry-run before making any change, and both support --json on every path:

update --json prints the plan (only the keys actually being changed, plus dryRun: true) on a dry run, and the full updated app object on a real run.

delete --json prints one document shape on both the dry run and the real run — { appId, name, action: "archive" | "hard_delete", siteId, siteName, permanent, dryRun, message } — so a caller can parse the same fields either way; message is null until the delete actually happens.

Environments: apps environments list/create/update/delete

webflow apps environments list <appId> --branch main --json
webflow apps environments create <appId> --branch feature/checkout --mount /checkout --dry-run
webflow apps environments update <appId> <envId> --branch main --dry-run
webflow apps environments delete <appId> <envId> --dry-run

list filters by an exact --branch or a substring --q on branch name. create provisions a new environment bound to a branch and served at a mount path — it starts empty; run apps deployments trigger to build it. update changes an environment's branch and/or mount (at least one is required) but doesn't deploy the change itself. delete removes an environment. All three writes support --dry-run, and resolve the app/environment from positional args, WEBFLOW_APP_ID / WEBFLOW_APP_ENVIRONMENT_ID, webflow.json, or an interactive picker.

Deployments: apps deployments list/get/redeploy/trigger

webflow apps deployments list --status failed --json
webflow apps deployments get <deploymentId> --wait --interval 10 --timeout 300 --json
webflow apps deployments trigger --wait --json
webflow apps deployments redeploy <deploymentId> --idempotency-key $GITHUB_RUN_ID --wait --json

list --status filters on an exact status (success, failed, starting, building, deploying, canceled, unstaged). get --wait polls until the deployment reaches a terminal status and exits 0/1 accordingly — built for CI gating; --interval and --timeout tune the poll (floored at 5s, capped at 30min).

trigger builds a GitHub-connected environment's current HEAD on demand; redeploy re-runs a past deployment at the same commit, the rollback path. Both require a GitHub-connected app (not eligible for apps deployed from local files via apps deploy) and now also take --wait (with the same --interval/--timeout): since enqueuing a build only returns a 202 with no deployment ID to poll, --wait identifies the new deployment itself and then blocks on it exactly like deployments get --wait — so a CI job can trigger a build and gate on its outcome in one command. All three writes support --dry-run.

Logs: apps logs build / apps logs runtime

webflow apps logs build <deploymentId> --since <iso> --q <text>
webflow apps logs runtime [envId] --limit 200 --json

Both support --fields, --json, and cursor-based pagination via --cursor.

Environment variables: apps env-vars list/set/delete/import

The headline addition this release: full, non-interactive management of Cloud app environment variables, so secrets no longer require a trip to the dashboard.

webflow apps env-vars list --fields key,isSecret --json
webflow apps env-vars list --q API --json
printf %s "$VALUE" | webflow apps env-vars set API_KEY --secret
webflow apps env-vars delete OLD_KEY --dry-run
webflow apps env-vars import .env --secret --dry-run

--app-id / --environment-id default from webflow.json (cloud.app_id / cloud.environment_id) when present — as shown above — so most invocations inside a project directory need neither flag. Pass them explicitly (--app-id <id> --environment-id <id>) to target a different app, for example from a shared CI runner.

list also takes an exact --key or a case-insensitive substring --q, same filtering pattern as apps list and apps environments list.

set <key> [value] takes the value three ways, safest first: piped stdin (shown above — works in CI with no TTY), an interactive prompt (masked for secrets) if you omit the value entirely, or a positional argument. A positional secret still works but prints a warning, since it lands in your shell history and process list — stdin or the prompt avoid that.

--secret marks a variable encrypted. Secret values are never echoed back — set on a secret confirms only that it was written, and list never returns a secret's value — it comes back masked. Non-secret values are hidden from the default output too, and shown only if you ask for them with --fields value or --json.

import <file> bulk-loads a .env (or any KEY=value) file in one call instead of setting variables one by one. --dry-run parses and previews the resulting key set — secret values shown redacted — without making any API calls or writing anything.

Every write command (set, delete, import) supports --dry-run and --json.

Also in this release

apps init --site-id <id> --no-input now correctly attaches the new app to the existing site and runs the DevLink export, instead of silently falling back to a standalone app without one.

The publicUrl field on an environment (apps environments list/create/update) replaces the old deployUrl field name.

Upgrading

npm install -g @webflow/webflow-cli@latest

The Branch API (beta) is now documented for Enterprise sites with page branching enabled.

Branches

• Overview — lifecycle, async tasks, conflicts, and entitlement requirements
• List Branches — paginated branch list with computed status and nextActions
• Create Branch — enqueue branch creation from a page
• Get Branch — single branch with status
• Delete Branch — enqueue branch deletion (202 + task poll)
• Get Branch Conflicts — unresolved style and component conflicts
• Update Branch — pull main changes into a branch
• Merge Branch — merge a branch into main
• Publish Branch — publish a branch preview to its staging domain
• Get Branch Task Status — poll async branch tasks

Webhooks

branch_created, branch_merged, and branch_deleted event schemas are documented under All Events. Successful merges fire branch_merged only — not branch_deleted.

Get page content's translatable parameter previously only checked whether a page's entire canvas was excluded from translation. A component instance's overridden property values were always returned as-is, even when the specific property was excluded — inconsistent with get component properties, which already filtered properties individually.

translatable now filters component property overrides the same way: an overridden value is omitted from a component instance's propertyOverrides if that property is excluded from translation for the requested locale. If a component instance's overrides are all excluded, the instance is omitted from the response entirely. A component instance with no overrides at all is unaffected.

Behavior that hasn't changed: only exclusion rules scoped to manual translation are respected, and omitting translatable returns the same response as before this parameter existed.

Global telemetry configuration

v2.5.0 changes where telemetry preferences are stored and fixes a crash affecting sites that combine code components from different sources.

webflow auth telemetry --enable/--disable now writes to a global config file (~/.config/webflow/telemetry.json on macOS/Linux, %APPDATA%\webflow\telemetry.json on Windows) instead of the current project's webflow.json. Bare CLI invocations in a project without a manifest no longer create one just to record a telemetry preference.

A new --local flag opts back into the previous behavior for teams that want a per-project override:

webflow auth telemetry --disable --local

A webflow.json that already has a telemetry setting continues to be read and takes precedence over the global config for commands run in that directory. DO_NOT_TRACK continues to override everything.

Fix: crash when combining code components from different sources

Fixed a crash — Element type is invalid: expected a string ... but got: object — that could occur when a published page loaded code components built against different React major versions. Upgrade @webflow/react to 2.1.1 and re-bundle libraries to pick up the fix.

Also in this release

Patched transitive brace-expansion and PostCSS dependencies addressing known vulnerabilities.

webflow cloud deploy can now resolve its framework builder from a shared @webflow/app package when enabled server-side; the local COSMIC_BUILD_ENGINE=v2|legacy environment variable can override the selection for a single run.

Upgrading

npm install -g @webflow/webflow-cli@latest

A clearer review scope

Over the past several weeks we've updated the Marketplace Guidelines, the app review process, and the tools available to you before you submit. Here's what changed and what to expect next.

App review now focuses on the surfaces Webflow is responsible for: code that runs in the Webflow Designer, your app's interactions with Webflow's APIs, and how your app handles Webflow credentials and Webflow user data. How your app's code behaves on your customer's published site is part of your service relationship with your customer. The new Review scope section in the guidelines states this directly.

What this means in practice:

Published-site code practices are now recommendations, not review gates. Subresource integrity, immutable script URLs, page-scoped injection, additive-only page changes, and similar practices moved to Recommended practices for published-site code. We still recommend all of them — your customers will hold you to them — but review won't reject your app over them.

Three gates remain for code you deliver to customer sites: deliver it through the Custom Code API, disclose what it does in your listing and submission, and remove your registered Custom Code on uninstall.

One consolidated backend rule: no untrusted origin may read or mutate a Webflow-authenticated response or state. Review verifies this by probing your live endpoints — not by auditing your backend source.

Data Client apps attest instead of being audited: provide three written attestations at submission — your app's Webflow OAuth token is encrypted at rest, stored server-side only, and deleted on uninstall or revocation.

Updated docs and guidelines

We revised the Marketplace Guidelines and app submission docs, including:

• Expanded review criteria in the Marketplace Guidelines, organized into linkable rule groups
• Corrected guidance on installation scopes — configured scopes your app doesn't use should be removed
• Reworked guidance for app-delivered code — the three gates above, plus recommended practices for published-site code; Designer Extensions still interact with the user's site exclusively through the Designer APIs
• Documented submission artifacts — a published testing site, source maps with the package manifest and lockfile for compiled bundles, production bundles free of debug routes and staging residue, and the optional preflight receipt
• Listing language requirements — English listings, with disclosure for non-English product experiences

Reviews check exactly what's published here

Our internal review checklist was rewritten to mirror the public docs. If a requirement isn't published on developers.webflow.com, we don't hold your submission to it. The docs you can read are the same standard we review against.

Every submission is reviewed against current guidelines — including updates

When you submit an update to an already-published app (including bug-fix releases), it's reviewed against the guidelines as they stand today, not as they stood when your app was first approved. If your app was approved before a guideline existed, an update may surface findings that are new to you. Published apps are not being retroactively delisted — your live listing is unaffected until you submit an update, and when findings come up, the review feedback will tell you exactly what to fix.

Clearer review feedback

Review outcome emails now list each required change explicitly, with links to the relevant docs, and distinguish required changes from suggestions.

Pre-submission checks you can run yourself

The app submission form now offers a downloadable skill toolkit — two agent skills for the app lifecycle:

• webflow-app-preflight checks your app and bundle against the review gates and the recommended practices — development builds, custom-code cleanup, scope mismatches, backend authorization, and listing assets — and ends in a clear go/no-go before you submit.
• webflow-app-review-remediation helps you work through review findings and prepare a resubmission after you've received feedback.

A skill is a folder with a SKILL.md instruction file that AI coding agents load as step-by-step expert guidance. It's an open, plain-Markdown format — you can also just read it. To use the skills:

• Claude Code: unzip and copy each skill folder into .claude/skills/ in your project (or ~/.claude/skills/ to use them everywhere), then run /webflow-app-preflight or ask Claude to preflight your app.
• Claude apps (claude.ai and desktop): upload a skill as a zip under Settings → Capabilities → Skills, then ask Claude to run it.
• Codex CLI: copy the skill folders into ~/.codex/skills, then ask Codex to run the preflight.
• Other agents: any agent that supports the open SKILL.md format can load them — or paste the SKILL.md contents directly into your agent's chat.

What's coming

In the coming weeks we're adding automated guideline checks at submission. Submissions with guideline failures can be rejected on that basis. The preflight skill isn't required — but it checks for the same kinds of issues, so running it before you submit is the easiest way to avoid a rejection. If your app has been live for a while, we recommend reviewing the current guidelines before your next update so nothing catches you by surprise.

Questions

Open a ticket at support.webflow.com — support tickets are the reliable path to the Marketplace team.

Get page metadata now accepts translatable, alongside the endpoints that already supported it:

• Get page content
• Get component content and get component properties
• List and get collection items, including their live counterparts

Pass the id of the secondary locale you're translating into to omit page-level fields (title, slug, SEO title/description, Open Graph title/description) excluded from translation for that locale — they're left out of the response entirely rather than returned as null. Behavior matches the other endpoints: the value must be a secondary locale id (400 otherwise), and the request returns a 403 if translation exclusions aren't enabled for the site.

The translatable parameter introduced on July 27 couldn't express the workflow it was built for, so its shape has changed.

Why it changed

A translation integration reads the primary locale to get the source text, translates it, then writes the result to a secondary locale. As originally shipped, translatable=true resolved exclusion rules against the same localeId used to select the content, which left no way to do that first step correctly:

Requesting the primary locale returned the right content, but only matched exclusion rules scoped to "all languages" — rules scoped to a specific language were silently ignored, so you could receive content the site owner had excluded for the language you were translating into.

Requesting a secondary locale scoped the rules correctly, but returned content that was already translated rather than the source text.

What changed

translatable now takes the id of the secondary locale you're translating into, independent of localeId:

?localeId={primary locale id}&translatable={target locale id}

translatable=true and translatable=false now return a 400. Pass a locale id, or omit the parameter entirely.

The value must be the id of one of the site's secondary locales. The primary locale id, or any other value, returns a 400.

localeId is optional. Omitting it returns the primary locale's content, filtered for the target locale — the common case for a translation integration.

The parameter requires translation exclusions to be enabled for the site. If they aren't, the request returns a 403.

If the exclusion rules can't be resolved, the request returns a 500 instead of unfiltered content. Retry the request.

Required action: if you're passing translatable=true, replace it with the id of the locale you're translating into. If you're passing translatable=false, remove the parameter.

Affected endpoints

• Get page content
• Get component content and get component properties
• List and get collection items, including their live counterparts

Behavior that hasn't changed: only exclusion rules scoped to manual translation are respected, and omitting translatable returns the same response as if the parameter didn't exist.

Site owners can exclude specific fields, properties, or canvas content from AI translation using the Localization panel in the Designer.

These endpoints now expose those exclusion rules through a new translatable query parameter.

Translation pipeline integrations can fetch exactly the content that should be translated, without tracking exclusion rules themselves.

New parameter

Pass translatable=true along with a secondary locale to return only content that hasn't been excluded from translation for that locale:

• Get page content: returns only page fields not excluded for the requested locale.
• Get component content and get component properties: return only canvas content and properties not excluded for the requested locale.
• List and get collection items, including their live counterparts: return only collection fields not excluded for the requested locale.

Only exclusion rules scoped to manual translation are respected — rules scoped only to automatic translation don't affect the response. Omitting translatable returns the same response as before this parameter existed. Setting translatable=true without also specifying a secondary locale returns a 400 error, since exclusions are resolved per locale.

A minor (maintenance) release to improve how the Webflow MCP works with Claude. Three groups of actions moved out of two large tools into focused tools of their own. The actions themselves are unchanged (same inputs, same behavior).

Element settings

data_element_settings_tool takes over element settings and data bindings from data_element_tool: reading and writing settings, discovering bindable sources, and setting an element's tag, visibility, and DOM id (static or bound).

Component props

data_component_props_tool takes over prop work from data_component_tool: creating, updating, and removing prop definitions, reading an instance's props, setting prop values, and resetting all props to their defaults.

Component variants

data_component_variants_tool takes over variant work from data_component_tool: creating, duplicating, deleting, reordering, and renaming variants, and reading or setting per-variant styles.

Skills based on earlier versions of Webflow MCP may need to be updated. The skill migration guide covers the updated tools and actions.

Build without a Designer session

In earlier versions, working with elements, components, styles, and variables required an active Designer session through the Webflow MCP Bridge App. In 2.0, those capabilities work on their own:

• Query and edit the element tree: text, styles, links, images, attributes, tags, settings, visibility, and display names, plus moving and removing elements.
• Create, transform, and manage components, including instances, props, and variants.
• Create, update, rename, and remove styles (classes and combo classes), and manage per-style variable modes.
• Create, update, rename, and delete variables (color, font family, number, percentage, size), and build and reorder collections and modes.
• Build elements on a page from a schema, insert component instances (including nested trees), and insert elements from HTML and CSS.
• None of these need a Designer session anymore.

New capabilities

MCP 2.0 opens up five areas of Webflow that agents couldn't reach before. Each works without a Designer session.

Analyze reporting

Agents can work with Webflow Analyze data: pull traffic over a chosen window (sessions, users, or pageviews), rank a site's top pages, break down leading values for a dimension like country, browser, or traffic source, surface the most frequent engagement events with page context, and read time on page as an aggregate or over time. Available for sites with Webflow Analyze.

Forms and submissions

Agents can read a site's forms and their schemas, list and retrieve submissions (with optional element and locale filters), update the hidden fields on a submission, and delete submissions.

Custom fonts

Agents can list and inspect a site's uploaded custom fonts, register and upload new font files, replace the file behind an existing font, update font metadata, and remove fonts individually or in batches.

Sitemap indexing

Agents can read, list, update, and bulk-update sitemap inclusion for CMS collection items and static pages.

Agent instructions

Agent instructions are markdown-based skills and rules that give agents custom guidance for working on a site. They can reference Webflow primitives like variables, styles, components, pages, CMS collections and items, and locales, and those references resolve against the site's own data. In 2.0, these instructions are provided automatically to external agents, and agents can manage them directly: searching a site's rules and skills, reading them (with referenced instructions resolved inline), and creating, updating, moving, renaming, and deleting them.

Expanded existing tools

Several existing capabilities gained new actions in 2.0:

• Pages: create a page, update settings across many pages at once, and read and bulk-update page schema markup and structured data.
• Assets: full asset and folder management (list, get, update, delete, and organize into folders), plus asset compression jobs with task tracking.
• Custom code: read and write the freeform custom code embedded at the site and page level, alongside existing registered-script management.

Still requires a Designer session

A few capabilities still depend on an active Designer session (through the Webflow MCP Bridge App):

• Element snapshots. Capturing a visual snapshot of an element, so an agent can read the current state of a site and verify its own changes before publishing.
• Selection and canvas navigation. Selecting and reading the selected element, navigating the canvas between pages and component views, reading the current page, mode, and branch, reading a site's breakpoints, and creating page folders.
• Uploading an image from a URL. Adding an image to a site directly from a public URL.

Governance

MCP enforces your workspace's permissions and roles, including custom roles: if a user can or cannot do something in the Designer, the same applies through MCP. Changes made by agents are recorded to the site audit log. This means you can give external agents site access while keeping the same permissions and audit trail as the rest of Webflow.

Migrating from an earlier version

Several tools and actions were renamed or relocated in 2.0, so skills, prompts, and automations written against an earlier version may call names that no longer resolve. A few examples:

• set_id is now set_dom_id, and add_or_update_attribute is now set_attributes.
• Element selection and canvas navigation moved to the dedicated Designer-session capabilities described above.
• Full asset and folder management moved off the image-upload tool, which now handles uploading an image from a URL only.
• The skill migration guide lists every name that changed and what to replace it with. You can also point an agent at that page and have it update a skill on its own.

Known limitations

A few things to be aware of in this release:

• Element snapshots require a Designer session. Capturing a visual snapshot still depends on an active Designer session through the Webflow MCP Bridge App. If you want an agent to run independently, let it publish to a staging domain, which supports full agent loops without the Designer.
• One workspace per authorization. When you authorize the MCP server, you choose a single workspace it can access. To use a different workspace, reauthorize. In clients like Claude and ChatGPT, that means removing the connector and reinstalling it.
• Interactions (IX3) aren't supported. Agents can't create or apply Webflow Interactions through the MCP server. Build and edit interactions manually in the Designer.
• Custom fonts cover uploaded files only. The custom font capabilities manage font files you upload. Remotely hosted Google and Adobe Fonts are still managed manually in site settings. For Google Fonts, you can download the files and upload them through the MCP server.
• Some uploads require sending a file to a presigned upload URL. Uploading an asset, or uploading or replacing a custom font file, is a two-step flow: the tool returns a presigned upload URL, and the client sends the file's bytes directly to that URL. If the client's environment or network blocks that outbound request, the upload can't complete. In that case, upload the file manually in Webflow instead.

DevLink Export supports a new opt-in camelCaseVariantNames setting in webflow.json that converts Style Variant names into camelCase values for the exported variant prop.

What changed

New camelCaseVariantNames option under devlink-export in webflow.json. It's off by default, so existing exports are unaffected.

When turned on, a Style Variant named Papaya With Whip exports as papayaWithWhip instead of the raw display name. Names that would collide, or that would otherwise produce an invalid value (a number-only name, or a JavaScript reserved word), fall back to safe, deduplicated values.

To use

Set "camelCaseVariantNames": true under devlink-export in webflow.json, then re-run webflow devlink export.

For more information, see Configuration options.

The base variable mode

The base variable mode — the default set of values that variables fall back to — is now first-class in the Designer API. It has the reserved ID "base" and, by default, the name "Base mode".

You can now work with the base mode like any other mode:

Rename it with mode.setName(). Its ID stays "base" even after it's renamed.

Retrieve it by ID with collection.getVariableModeById("base"), or by its (default or renamed) name with collection.getVariableModeByName().

// Get the default variable collection
const collection = await webflow.getDefaultVariableCollection()
// Get the base mode by its reserved ID and rename it
const baseMode = await collection.getVariableModeById("base")
console.log(await baseMode?.getName()) // "Base mode"
await baseMode?.setName("Light")

Behavior change: getAllVariableModes includes the base mode

collection.getAllVariableModes() now includes the base mode in the returned array (as the first entry). If your integration iterates over the result, it will now encounter the base mode — for example, when listing or counting a collection's modes.

const collection = await webflow.getDefaultVariableCollection()
const modes = await collection.getAllVariableModes()
// The base mode is now part of this list
for (const mode of modes) {
console.log(await mode.getName())
}

For more information, see Variable Modes.