Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-design-models Generate product screens for a habit tracker app"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A thin MCP server that turns a product idea into UI screen mockups plus a complete buildable spec (design tokens, component trees with real copy, assets). It does no rendering itself: it runs the Studio "Design Factory" flow, which owns the render queue and the single-GPU guard, and returns the result.
MCP generate_product(idea, ...)
│ POST /api/flows/flow_design_factory/correr?esperar=1
│ { "parametros": { "brief": ... } }
▼
Studio engine (queue + GPU guard)
compositor (agent, plans) → telas (native render node) → analyst (writes spec)
▼
{ spec, manifest_path, screens[], assets[] } ← the MCP waits and returns thisThe prompt discipline that keeps a diffusion model from producing garbled clip-art (dark
surfaces, colours as materials not codes, only short labels as real text, table rows as
bars, one consistent sidebar) now lives inside the Studio engine's telas node, so it is
shared with the panel and driven through the same GPU guard as every other render.
generate_product — turn an idea into screens + assets + a spec.
Optional hints: product, theme (dark/light), palette, accent, max_screens,
constraints. Returns the analyst's spec JSON plus the rendered image paths and the
manifest.json path. Sequential on one GPU, so it takes several minutes.
Related MCP server: UI Canvas MCP
A running Studio engine (studio-api) with the telas node type and the
flow_design_factory flow registered — see studio-flow/.
The Studio's ComfyUI with the image checkpoints installed (Z-Image Turbo by default; qwen-image and flux-schnell also available) — the Studio manages these.
Node.js >= 20.
Variable | Default | Purpose |
|
| Studio engine HTTP endpoint |
|
| The flow to run |
npm install
npm run build
node dist/index.js{
"mcpServers": {
"design-models": {
"command": "node",
"args": ["/absolute/path/to/mcp-desigh-models/dist/index.js"],
"env": { "STUDIO_URL": "http://127.0.0.1:28950" }
}
}
}The telas node writes the rendered screens, assets and manifest.json under
<studio renders>/studio/design/<product>/. generate_product returns the analyst's
spec (the source of truth for the build) together with those paths.
MIT.
Turn a product idea into a set of screen mockups. Either pass screens explicitly, or (if the server has a planner configured) let it plan them from idea. Renders every screen with a shared sidebar and writes a manifest.json next to the images. Rendering is sequential on one GPU, so several screens take many minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| idea | Yes | The product idea / brief | |
| theme | No | ||
| accent | No | ||
| palette | No | ||
| product | No | Product name; inferred from the plan if omitted | |
| screens | No | Explicit screens to render; skips internal planning | |
| sidebar | No | Shared sidebar; inferred from the plan if omitted | |
| max_screens | No | Cap on screens (default 6) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It mentions writing manifest.json, rendering all screens with a shared sidebar, and sequential GPU rendering with time cost. This covers key non-obvious behavior, though it does not detail overwrite behavior or error handling. The disclosure is strong for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose, followed by mode options and behavioral constraints. No filler or repetition. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, arrays, enums) and no output schema, the description covers the core workflow, output artifact (manifest), shared sidebar behavior, and performance caveat. It does not enumerate all parameters or explain return format, but the essential usage context is present. Missing details like overwrite policy are minor for a generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 63%, and the description clarifies the relationship between the two most important parameters: screens and idea, explaining that they are alternative ways to specify the content. This adds meaning beyond the schema, which already has descriptions for several parameters. It does not elaborate on aesthetic parameters like theme/accent/palette, but those are likely self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'turn' with a specific resource: a product idea into screen mockups. It clearly distinguishes from the sibling render_screen by describing a set of mockups generated from an idea or explicit screens. The purpose is unambiguous and not tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on two usage modes: pass screens explicitly or let the planner derive them from idea, with a conditional on planner configuration. It also warns about sequential rendering time, setting expectations for when to use. However, it does not directly compare with render_screen, relying on the tool name to imply single-screen vs multi-screen usage, so it loses one point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render one UI screen mockup with the local qwen pipeline. Give the screen a name, a prose layout of the main panel, and (for consistency across a product) the shared sidebar items plus which one is active. Returns the image path and a manifest entry. Text discipline (dark theme, colors as words, only short labels real, rows as bars) is applied for you. A render takes a few minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Short technical tags allowed as real text, e.g. ["RTX 4090","QLoRA"] | |
| style | No | Extra style words | |
| theme | No | ||
| accent | No | Single accent color in words, e.g. 'electric violet' | |
| active | No | Which sidebar item is highlighted (defaults to the screen name) | |
| layout | Yes | Prose description of the main panel: which components, where, proportions | |
| screen | Yes | Screen name, e.g. "Overview" | |
| palette | No | Palette in words, e.g. 'near-black graphite with dark charcoal panels' | |
| product | Yes | Product / wordmark name, kept short | |
| sidebar | No | Sidebar nav items, once each, shared across screens |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavior itself, and it does: it states the return value ('image path and a manifest entry'), automatic text-discipline transformations, and a latency warning ('takes a few minutes'). It does not cover persistence/cleanup details, but those are secondary for a render tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized, front-loads the core purpose, and every sentence contributes information (inputs, consistency, automation, output, latency). It is slightly dense, but not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description covers the return type, runtime cost, and automatic behavior, which is the context an agent needs beyond the parameter schema. It could more explicitly address the sibling tool and clarify the product parameter, but the essential calling context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 90%, so the schema already documents most parameters; the description adds useful guidance about shared sidebars, active item, and text-discipline constraints. However, it lists optional sidebar/active as if part of the core call and omits the required 'product' parameter, and its 'dark theme' phrasing sits awkwardly with the theme enum that allows light.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Starts with a specific action and resource: 'Render one UI screen mockup with the local qwen pipeline.' The 'one UI screen' scope distinguishes it from the sibling generate_product, and the rest of the description clarifies it is a single-screen rendering tool rather than a product generator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need a single UI mockup and adds practical context ('for consistency across a product', 'takes a few minutes'), but it never names the sibling generate_product or states when to use one tool instead of the other. No exclusion criteria or explicit alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0generate_productrender_screenScored across 2 tools
render_screen is explicitly for a single UI screen mockup with full control, while generate_product is for turning an idea into a multi-screen product set. Although generate_product can take explicit screens, the descriptions clearly separate single-screen rendering from product-level generation, so an agent should not misselect.
Both tool names follow the same verb_noun snake_case pattern: render_screen and generate_product. The verbs differ semantically but the structural convention is consistent and predictable.
Two tools is at the thin end of the scale; the server covers only single-screen and product-level generation. It is not excessive, but the surface feels minimal for a design-model server.
The core workflows for rendering one screen and generating a full product are covered, including manifest output. Missing conveniences like listing past renders or editing manifest entries are minor gaps that agents can work around via the filesystem.
Turn your app idea into IA, wireframes, PRD, style guides, and dev specs for coding agents.
UI design from prompts, screenshots, and URLs for AI coding agents and theme tokens.
Build and edit app screen mockups and clickable prototypes from your AI assistant.
Agent-Native design tool - create and edit visual designs with agent assistance
