Press slash to focus this field, or Escape to return home.

How do you drive Webflow from Claude Code?

Method

6 August 20267 min readMethod

The interesting part of Webflow's MCP server is not that an agent can read your CMS. The Data API could always do that. It is that the Designer side lets an agent act on styles and elements in the project you actually have open.

That changes the shape of the work. Before, an agent could tell you what to change. Now it can make the change in the project, and you review it in the Designer like any other edit.

What it is good at

Repetitive structural work. Porting a component pattern across pages, renaming and consolidating classes, applying a spacing scale that was decided once and then drifted. This is the work that is too boring to do carefully and too consequential to do carelessly.

CMS modelling at scale. Creating collections, fields and references from a schema you wrote down, instead of forty minutes of clicking.

Auditing. Reading every page's structure and reporting what disagrees with the standard. This is where I get the most value, because it turns a vague sense that the site has drifted into a list.

What it cannot touch

Webflow publishes a current limitations list, and it is worth reading before you plan around the tool. As of August 2026 the ones that bite:

  • Interactions are out. No IX3 automation. Motion stays hand-built, which is fine by me, because motion is a judgement call per project.
  • Fonts are partial. Uploaded font files only, not remotely hosted Google or Adobe fonts.

Plan for those rather than discovering them mid-build.

The thing that makes it work

The agent is not deciding anything. It is executing a standard I wrote down.

Naming, structure, spacing, motion timings, CMS patterns, handover rules: all of it lives in versioned markdown that every project starts from. That file is the actual product. The agent is a fast, tireless, literal-minded implementer of it, and it is only as good as the thing it is implementing.

Which is why "AI built the site" is the wrong description of this. Nobody says a compiler wrote the program. The interesting question is whether the standard is any good, and that is a question about the person, not the tool.

Where I keep the judgement

Three things never go to the agent, on any project:

  • Information architecture. What gets a URL, what a collection represents, how things relate. Get this wrong and everything downstream is fast work in the wrong direction.
  • Anything a client will be judged on by their own audience. Copy, hierarchy, the argument the page makes.
  • The decision to change working behaviour. An agent mid-task will happily "fix" something that was deliberate. The rule on my projects is that at a fork it either verifies, defers, or asks. It never silently changes and back-fills a reason.

That last one is not a theoretical risk. It is the failure mode, and I have the commit history to prove it.

Whether it is worth setting up

If you build one Webflow site a year, no. The setup cost is real and the payoff is in repetition across projects.

If you build continuously, the compounding is in the standard rather than the tooling. Every project that starts from the same written rules is faster than the last, and the tool is just what makes following them cheap. I would still be writing the standard if the tooling vanished tomorrow. I would just be applying it by hand.

Written by Yar Al Roshidi · 6 August 2026 Book a call