The distinction it enforces is the one people get wrong — styled components, primitives and Runtime are separate surfaces with separate install paths, and the server answers per surface instead of blurring them. Nothing is executed for you: you get the command with the right package manager filled in and run it yourself.
A server for Starwind UI v3 and Starwind Pro that keeps the library's three surfaces — styled components, primitives and the Runtime — distinct, and validates every answer against the site's versioned AI manifest.
- Live documentation pulled from starwind.dev — component and primitive pages, Runtime APIs, theming, installation and migration
- Search across styled components, primitives and Pro blocks, with framework metadata and Pro plan and category filters, paginated
- The correct installation command for the components you name, built for the package manager detected in your project
- Initialization commands for an existing Astro or React project, with Pro opt-in rather than assumed
- Migration guidance from v2 to v3 that inspects the project first and stays interactive unless you say otherwise
- Answers validated against the versioned ai-manifest.json and cached, falling back to a bundled v3 snapshot when the site is unreachable
- Both readable JSON and structured content on every call, and no tool ever executes the command it generates
Nothing to authorize for the free catalogue. Runs from npm as @starwind-ui/mcp over stdio. The CLI commands it generates need Node.js 22.12.0 or newer, and initialization targets an existing Astro 5+ or React 18+ project. Paid Pro blocks need a licence key in .env.local, which the setup command scaffolds; free Pro catalogue blocks install without one. Pro blocks currently target Astro — React searches leave them out and React installs reject them.
One command — npx -y @starwind-ui/mcp
