Webflow MCP Server: Site Edits From an Agent

Webflow MCP is Webflow’s own Model Context Protocol server. It runs remotely at https://mcp.webflow.com/mcp, you sign in with OAuth and pick the sites it may touch, and it gives an assistant such as Claude, ChatGPT, Codex or Cursor tools built on Webflow’s Data and Designer APIs: create and edit elements, styles, components and variables, manage CMS collections and items, pages, assets, forms and SEO settings, read analytics, and publish. The agent can do only what your own Webflow role allows, and its changes land in the site’s activity log. Most of it works without the Designer open; a few canvas features need Webflow’s MCP Bridge App running in the Designer.

What the official server is

Webflow’s overview of its MCP server↗ (opens in a new tab) describes it as a way to import designs, create pages, analyze site activity and work with the CMS from your preferred AI environment. It is one server with three families of tools:

• Data tools, such as data_cms_tool, data_pages_tool, data_sites_tool and data_style_tool. Each groups several actions, and they run headlessly, without the Designer.
• Designer tools, which act on a live Designer session: the current selection, page, mode, breakpoints and visual snapshots of elements.
• Utility tools: ask_webflow_ai for questions about the Webflow API, webflow_guide_tool for recommended workflows, and get_more_tools when the loaded set does not cover a job.

Webflow also runs two other servers. The Beta server at https://mcp.webflow.com/beta/mcp carries experimental tools and early-access features; Webflow’s Claude connector and Cursor plugin always use the production server, so the beta has to be added by hand. A documentation server answers questions from Webflow’s developer docs and does not touch your sites.

How to connect Webflow MCP to Claude

In Claude on the web or the desktop app, click the plus button in the chat box, choose Add connectors, and search for Webflow (you may need All rather than Featured to see it). Click Connect, sign in to Webflow, select the sites or workspace Claude may use, and click Authorize App. The same authorization installs the MCP Bridge App on those sites; it is not listed on Webflow’s public app marketplace. ChatGPT has an official Webflow app that follows the same pattern.

For Claude Code, Webflow’s Claude Code setup page↗ (opens in a new tab) uses one command, then /mcp to start the browser sign-in. It also suggests a trick worth copying: give each site its own project folder and add the server with project scope, so each folder holds its own authorization. Cursor takes the same address in .cursor/mcp.json, per project, which Webflow recommends to avoid repeated sign-in prompts.

claude mcp add --transport http webflow https://mcp.webflow.com/mcp -s project

{
  "mcpServers": {
    "webflow": {
      "url": "https://mcp.webflow.com/mcp"
    }
  }
}

One disagreement to know about. The docs site describes only the remote server at /mcp. The webflow/mcp-server repository↗ (opens in a new tab) README still shows an older Claude Desktop setup through mcp-remote and an /sse address, and documents a local install started with npx and a WEBFLOW_TOKEN API token, which also requires registering your own copy of the Bridge App. Unless you have a reason to run it yourself, use the remote server and OAuth. How that sign-in works in general is in MCP OAuth, explained.

Who can authorize it, and what the agent may do

• Only site owners and admins can authorize the server; other people see their sites grayed out on the sign-in screen.
• Each authorization covers a single workspace. To switch, remove the connector or server and add it again, then pick the other workspace.
• The agent works inside your existing Webflow permissions and roles, including custom roles, and can do nothing through MCP that you could not do in the Designer.
• It cannot change access settings: no adding users or assigning roles.
• Changes it makes are recorded in the site’s activity log, so you can see what an agent did and when.

Sites can also carry Agent Instructions: Markdown rules and skills stored on the site itself that the server hands to every connected agent. They can reference the site’s own variables, styles, components and collections, so “use the brand color variables, never hex values” can live where the design system does.

When the Designer has to be open

Most work goes through the Data API, and Webflow’s how it works page↗ (opens in a new tab) is explicit that creating and editing elements, components, styles and variables, and managing CMS content, pages, assets and fonts, do not need the Bridge App. You need the Designer open, with the Webflow MCP Bridge App launched from the Apps panel (press E) and connected, only to capture visual snapshots, to read or change the current selection, page, mode or branch, and to navigate the canvas or read breakpoints. If those calls time out, Webflow’s troubleshooting advice is to keep the Designer tab awake, for example by adding webflow.com to Chrome’s “Always keep these sites active” list or pinning the tab. A tool that the current Designer mode does not allow returns a ModeForbidden error.

How to use Webflow MCP well

The server is strongest at repetitive, checkable work across many pages or items. Jobs that suit it:

• SEO metadata: find pages with missing or weak meta titles and descriptions, propose fixes, and apply them after you approve.
• CMS cleanup: fetch a collection’s schema and items, list items missing a featured image or description, and fill gaps with clearly marked placeholders.
• Content audits: broken links, images without alt text, outdated information.
• Design system refactors: replace hard-coded colors, spacing and font sizes with variables.
• Traffic questions: top pages, sources and time on page, which need Webflow Analyze, an optional add-on on paid Site plans.

Prompts that name the scope and the stopping point work best: “In the Blog Posts collection, list every item without alt text on its main image. Propose alt text for each, wait for my OK, then update the items as drafts. Do not publish.”

Drafts, publishing and unpublished sites

The docs do not limit the server to published sites; it works with any site you authorized. What matters is when changes go live. According to Webflow’s data tools reference↗ (opens in a new tab), CMS items are created and updated as drafts, and publishing them is a separate action (publish_collection_items, with unpublish_collection_items to take items back to draft). Pages carry a draft setting, sitemap changes are staged, and publish_site on data_sites_tool publishes the site to its domains, making the latest changes live. Page branches, where you work on a page in isolation and publish a preview to a staging domain, need an Enterprise plan.

The practical rule: let the agent edit, and keep publishing for a person. In clients with per-tool approval, leave data_sites_tool and the CMS tool on “ask every time”. Webflow grants access at the tool level, so approving a tool approves all of its actions, publishing included.

Limits

• Interactions: it builds and edits Interactions with GSAP, not Classic interactions. On a site still using Classic, the agent sees no interactions at all.
• Localization: it can read and update existing CMS items and static content in secondary locales, but cannot create new localized CMS items.
• Fonts: it manages uploaded font files only; Google and Adobe fonts stay in site settings.
• Webflow Cloud: deployments work only for apps connected to a GitHub repository, and secret environment variables never pass through the server.
• Campaigns: only for sites in Webflow’s Early Access program, and launching still happens in the Campaigns interface.
• Coverage: the server exposes a focused set of Data and Designer API tools, not every endpoint in the Webflow API.

Review before anything ships

A site is public by definition, so a bad edit is visible to customers the moment someone publishes. Four habits help. Authorize the fewest sites you can, one workspace per connection, in a project folder per site. Ask for a plan before a bulk change, and a list of what changed after it. Check the activity log against that list. And treat content the agent reads as untrusted: CMS items written by other editors and, above all, form submissions, which the forms tool can list, are text strangers wrote. Instructions hidden in them are indirect prompt injection, and an agent with publish rights is exactly what that attack looks for. The wider checklist is in MCP security best practices.

Webflow or WordPress

Webflow has one hosted server with OAuth and a fixed tool set. WordPress is split: WordPress.com runs a hosted server, while a self-hosted site exposes only what its plugins register through the MCP Adapter. If you run both, WordPress MCP covers the other side.

Keeping site work on a board

An agent that audits a site finds more than it should fix in one sitting. With fenbs connected as a second MCP server at https://fenbs.ai/api/mcp, the assistant can file each finding as a task: a bug for a broken link, an enhancement for weak metadata, with the page URL in the note and the agreed approach in the plan. It should search the board first so it does not file the same page twice, and leave priority (1 is the most urgent, 10 the least) for a person to set. Tasks move through To Do, Next Up, In Progress and Completed, and History records which assistant changed what. A standing instruction such as “never publish the site” belongs on the Decisions and rules page, which every connected assistant reads first.

fenbs is deliberately small. It has no due dates, no sprints and no assignee field, so a launch date or an owner’s name goes in the note, and the site itself stays in Webflow; the task holds the link.