stitch mcp

google stitch generates ui screens from natural-language prompts, but it only exists as a standalone web app — there’s no way to drive it from an agent or chain it into a bigger workflow. i wanted to describe a screen once, in a claude conversation, and have it actually generate the design without hopping over to a browser.

built with fastmcp, the server wraps stitch’s api as a set of tools: create a project, generate a screen from a prompt, list and manage design systems, produce variants of an existing screen. the trickiest part wasn’t the api calls themselves but shaping the tool schemas so an llm could reliably describe ui intent — “a settings screen with a dark mode toggle and account section” — in a way that maps cleanly onto stitch’s generation parameters without the model having to know stitch’s internals.

the payoff is that ui generation becomes just another step in an agentic workflow instead of a separate manual task — claude can generate a screen, look at the result, and iterate on it in the same conversation that’s driving the rest of the build.