The Data-API side is complete enough to run a CMS from a conversation — schema, fields, items, drafts against live, publish — while the Designer side puts real elements, styles and variables onto the canvas someone is looking at. The seams are visible: element_builder caps nesting at three levels per call, delete_all_site_scripts arrives with an empty description, and webflow_guide_tool exists to tell the model to call it before anything else.
A Webflow server covering both halves of the platform — the Data API for CMS collections, pages, components, scripts and publishing, and Designer tools that act on the page currently open — 43 tools in total.
- CMS collections listed, read with their schema, and created; static, option and reference fields added, and existing fields updated
- Collection items created and updated either as drafts or directly to the live site, listed with filtering and sorting, published in batches by itemIds, and deleted per locale
- Pages listed, their content read, SEO and Open Graph metadata read and written, and static-page text nodes localized
- Components listed with versions, their content and properties read, and both updated for secondary locales
- Sites listed and inspected, and published either to the Webflow subdomain or to named custom domains
- Scripts registered inline within a 2000-character limit, listed as registered or as applied by the app, and cleared for a site
- Designer tools acting on the open canvas: element_builder creating structures up to three levels deep per call, alongside element, style, variable, component, page and asset tools
- ask_webflow_ai for questions about the Webflow API, and get_designer_app_connection_info for whether the Designer half is reachable at all
A Webflow account and an API token in WEBFLOW_API_TOKEN. The Designer tools act on the page open in the Designer, so that half also needs the Webflow MCP app connected to a running Designer session.
One command plus a key — npx -y webflow-mcp-server, then supply credentials