mcp-design-models
Related Servers
Alternatives to mcp-design-models
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityAmaintenanceEnables AI agents to create and manage consistent multi-screen UI designs through a token-efficient MCP interface, with design system tokens, components, flows, and visual review.127 npm2AGPL 3.0

Sleek MCP serverofficial
AlicenseNot gradedqualityBmaintenanceEnables MCP clients to turn plain-language mobile app descriptions into rendered, editable screens and project links for exporting to Figma, HTML, or React.MIT- AlicenseNot gradedqualityDmaintenanceTurns product ideas into implementation-ready planning packages including PRD, requirements, user flow, wireframes, data schema, API contracts, and SDK boundaries, with an MCP handoff for coding agents.MIT
- FlicenseAqualityDmaintenanceTransforms basic interface ideas into comprehensive, professional-grade UI/UX design specifications with detailed styling, animations, components, and accessibility requirements for websites, apps, and other digital interfaces.5-
- FlicenseBqualityBmaintenanceEnables coding agents to read, render, and normalize design documents from Figma and Adobe XD, providing visual context plus structured design data and generating starter code for web, React, Vue, Flutter, SwiftUI, and Jetpack Compose.131-
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to read and manipulate visual UI designs drawn on a canvas, translating them into precise JSON specs for production code generation.11,972 npm4ISC
TDQS
Scored 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.