Smootify MCP: the server your agent builds stores with

What it gives your agent

An agent that writes Smootify markup from memory invents attributes, puts elements in the wrong place, and uses what 1.x did. The MCP answers from the 2.0 contract, the attribute glossary and the API types, the same sources the Smootify runtime and the Webflow app use.

Before building: the agent looks up elements and values instead of guessing, and starts from markup that works.
Before pasting: check_markup checks HTML, a Webflow clipboard payload or a Designer tree, and says what Smootify will do with each mistake.
After publishing: audit_page and audit_site read the live pages, and diagnose goes from a symptom to its cause.

What no rule can check comes back as unknown, never as fine. The server tells the agent so, and the agent tells you.

Tools

Contract and vocabulary

`get_element`	Everything about one element: what it is for, where it must go, the attributes it reads, the plan and add-on it needs, its state classes.
`list_elements`	The elements, filtered by area, plan, add-on or status, to find which one does a job.
`resolve_vocabulary`	The values an attribute takes in 2.0, with their meaning, where they go, aliases and what is deprecated.
`suggest_attributes`	Which attributes work on an element where it sits, from its ancestors: the same logic as the Smootify Webflow app.
`get_plans`	What each plan includes, which add-ons need turning on, and what happens to their markup without them.
`get_options`	The SmootifyUserOptions keys with their defaults, the label globals and the page hooks.
`get_changes`	What 2.0 removed, renamed or changed, what replaces it, and the migration steps.

JavaScript API

get_api window.Smootify for custom code: methods, events with their payloads, filters, types, the Shopify AJAX endpoints 2.0 answers, how scripts load.

Examples

`get_example`	Markup that works, from the Smootify test theme, for an element or an attribute, as designed in Webflow.
`find_capability`	From a need in words, such as “a quote instead of checkout”, to the elements, attributes and options that meet it.

Checks

`check_markup`	Checks HTML, a Webflow clipboard payload or a Designer tree against the 2.0 contract: unknown tags, wrong places, missing parts, values Smootify does not read.
`scan_requirements`	What the markup asks Shopify for: metafields by scope, metaobjects, store availability, bundle components.
`check_custom_code`	Checks a site’s own JavaScript and CSS against the 2.0 API: events and methods that do not exist, hooks 2.0 removed, renamed classes, calls that may run before Smootify loads.
`check_annotations`	Checks the Smootify annotations of a Figma file before it is built.

Published site

`audit_page`	Audits a published page as Smootify sees it: the version it loads, the options, the links, the markup and the scripts.
`audit_site`	audit_page on up to 10 pages, one per template found in the sitemap, with the findings merged by cause.
`check_license`	The license of a site as the runtime reads it: plan, trial, authorized domains and add-ons.
`probe_storefront`	What the site’s public Storefront token sees: whether it works, the products on its channel, markets, currencies and languages, and the metafields a page asks for.
`plan_migration`	The steps to move a page from 1.x to 2.0, with what this page needs and the script tag to change.
`diagnose`	From a symptom, such as “the swatches do not show”, to the known causes and the check that confirms each one.

Prompts and resources

Four prompts start the common jobs with the right tools in order:

`build-page`	Plan and check the Smootify markup of a page before building it in Webflow.
`migrate-site`	Plan the move of a 1.x site to 2.0.
`diagnose-issue`	Find why something does not work, from a symptom and a page.
`review-figma-annotations`	Check the annotations of a Figma file before building it.

Nine resources give the agent the sources to read in full:

`rules`	The markup rules the checks use.
`glossary`	The 2.0 attribute glossary, as the Webflow app reads it.
`types`	smootify.d.ts: window.Smootify, the events and the filters.
`changelog`	What 2.0 adds.
`breaking-changes`	What 2.0 removes or changes.
`migration`	Moving a 1.x site to 2.0.
`scripts`	How custom scripts wait for Smootify.
`ajax-api`	The Shopify AJAX endpoints 2.0 answers.
`sources`	Which version of each source the server answers from.

Claude

Claude Code:

claude mcp add --transport http smootify https://mcp.smootify.io/mcp

Then run /mcp in Claude Code and sign in with your Smootify account.

Claude on the web and desktop: in Settings › Connectors, add a custom connector with the address https://mcp.smootify.io/mcp, and sign in. Pair it with the Figma to Webflow skill to build from a design.

Cursor

Add the server to ~/.cursor/mcp.json, or to .cursor/mcp.json in a project, then sign in when Cursor asks:

{
  "mcpServers": {
    "smootify": { "url": "https://mcp.smootify.io/mcp" }
  }
}

Codex

codex mcp add smootify --url https://mcp.smootify.io/mcp
codex mcp login smootify

Access and data

Your Smootify account. You sign in with the account of your Smootify dashboard, on any plan, the free one too. The server registers your agent by itself: there is no key to copy.
Read only. It never writes to Shopify and never publishes Webflow. It returns markup and findings; you or your agent decide what to change.
Public data only. The audits read pages anyone can open. probe_storefront uses the site’s public Storefront access, the same the site uses, and check_license never returns a token. No customer or order data goes through the server.
Up to date with 2.0. Its rules come from the same contract and glossary as each Smootify release; sources says which version it answers from.

Smootify MCP.