MCP v2.1: Interactions with GSAP, Webflow Cloud, and Campaigns

MCP v2.1 widens what agents can do on the Webflow platform. Three products open to agents for the first time, branch management becomes a complete loop, CMS collections gain field groups, and agents can now generate the instructions that guide their own work. No tool or action names changed, so anything built against v2.0.1 keeps working.

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 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. 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.

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.