Integration
Goose runs on your machine. Windcraft gives it your design language.
Goose is an open agent built around MCP — it was one of the first public MCP clients, and it extends through MCP servers. Windcraft is one of those extensions: it hands Goose your tokens and contracts so generated UI is on-system, not improvised.
Why an extensible agent still needs design values
Goose can do a lot through its extensions — read files, run commands, hit APIs — but none of that tells it your brand color or spacing scale. Left to its own priors, it reaches for generic values, and across a session of autonomous work those choices accumulate into drift. The extensibility is the answer: add the extension that supplies your design language.
How Windcraft plugs into Goose
Goose loads MCP servers as extensions. Add Windcraft as a stdio extension and Goose can call the design tools — tokens, contracts, patterns — while it works, reading your values instead of guessing.
- Run npx windcraft init in your repo to generate the config.
- Add Windcraft as a Goose extension (via goose configure or your config.yaml).
- Goose calls get_design_tokens / get_component_contract / get_page_pattern as it builds.
- Run npx windcraft check to flag any drift before you commit.
Goose extension config (~/.config/goose/config.yaml)
extensions:
windcraft:
type: stdio
cmd: npx
args: ["windcraft", "mcp"]
enabled: trueFAQ
- Is Windcraft a Goose extension?
- Effectively, yes — Goose consumes MCP servers as extensions, and Windcraft runs as one. Add it the way you add any Goose extension and the design tools become available to the agent.
- Do I configure it with goose configure?
- You can. goose configure walks you through adding a stdio extension, or you can add the block to your config.yaml directly. Either way it runs npx windcraft mcp locally.
- Does my source code leave my machine?
- No. Goose runs on your machine and so does Windcraft’s server and analyzer. Only metadata — tokens, contracts, rule violations — is synced to the cloud.