Integration
Cursor writes the code. Windcraft keeps it on-brand.
Cursor is fast, but by the tenth page the radii drift and the gaps stop matching. Windcraft hands Cursor a structured design language over MCP — so consistency survives.
Why Cursor output drifts
Cursor reasons one file at a time. Your .cursorrules are prose — "use rounded corners", "keep it calm" — re-interpreted on every generation. Ten prompts later you have rounded-md here, rounded-[8px] there, three shades of the same blue. The model never had values to read, only adjectives.
How Windcraft plugs into Cursor
Windcraft runs a local MCP server. Cursor connects to it and, instead of guessing, asks for the exact tokens, the component contract, and the page pattern before it writes.
- Run npx windcraft init in your repo to generate the config.
- Add the Windcraft MCP server to your Cursor settings.
- Cursor calls get_design_tokens / get_component_contract / get_page_pattern as it writes.
- The static analyzer flags any drift before you commit.
Cursor MCP config (.cursor/mcp.json)
{
"mcpServers": {
"windcraft": {
"command": "npx",
"args": ["windcraft", "mcp"]
}
}
}FAQ
- Does Windcraft replace Cursor?
- No. Cursor still writes the code. Windcraft is the design layer Cursor reads from so its output stays consistent across pages.
- Do I have to change how I prompt?
- No. You prompt Cursor the same way. Windcraft works through MCP in the background — Cursor pulls the tokens and contracts itself.
- Does my source code leave my machine?
- No. Windcraft analyzes locally. Only metadata — tokens, contracts, rule violations — ever touches the cloud.