Better Design

Create an HTML prototype from a Figma frame

create-figma-prototype

Converts a selected or named Figma frame into an HTML page built from design system components, reports layers that cannot map, and supports rebuilding frames from files outside the library.

Instructions

Reads a frame from the Figma file the designer has open and returns it as one HTML page, built from the same components the design system ships. Name a frame, or omit the name to take whatever is selected in Figma. The Better Design plugin must be open in that file: run Plugins, Development, Better Design once and leave the panel open. Every layer that could not map is reported rather than dropped. For a frame from a file that was not built from a Better Design library, pass mode "model" and a catalog design system. The designer confirms in the plugin panel. By default you rebuild the frame yourself: the tool returns a prompt file and the frame's image, you write the answer to a file, and you call this tool again with frameId and answerPath so it checks the page and reports what is missing. Pass a projectId whose project keeps a client's Figma kit to build with that kit, and the page keeps each client component as a named part.

Input Schema

Name	Required	Description
`mode`	No	library (the default) maps components from a Better Design library. model asks a model to rebuild a frame from any file.
`frame`	No	The frame's name as it reads in Figma. Omit to use the current selection.
`model`	No	Model mode with openai-compatible: the local model id. Defaults to gemma4:latest.
`theme`	No	Model mode with a kit: the kit's brand theme, such as Matrix. Defaults to the kit's first theme.
`method`	No	Model mode: page (the default) has the model write the whole page. blocks draws the frame in code first, so layout, text and icons match Figma, and the model only turns the client's components into working parts. blocks suits a cheaper model.
`system`	No	Model mode: the catalog design system to build with, as find-design-system names it.
`frameId`	No	Model mode, second call: the frameId the first call returned.
`kitPath`	No	Model mode: a kit file from read-figma-kit. The page then uses that kit's colours, font and radius on the system's parts.
`provider`	No	Model mode: agent (the default) hands the frame to you to rebuild; openai-compatible calls a local server, Ollama by default.
`projectId`	No	Model mode: a Better Design project that keeps a Figma kit from read-figma-kit. The page wears that kit, builds with the project's design system unless system is given, and keeps each client component as a named part.
`answerPath`	No	Model mode, second call: the file holding your answer, as the prompt file asks.
`outputPath`	No	Where to write the HTML. Relative paths resolve against the working directory.
`drawInFigma`	No	Model mode, second call: also draw the finished page on a new page of the open Figma file, each named part as an instance of the client's component found on the page Figma shows when the draw starts, so keep the frame's page open. Use a copy of the client's file; the designer confirms in the plugin panel.

Output Schema

Name	Required	Description	Default
`path`	No
`model`	No
`report`	No
`status`	Yes
`frameId`	No
`message`	Yes
`imagePath`	No
`components`	No
`promptPath`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 25, 2026

TDQS

A4.1/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the sparse annotations: it names the hard prerequisite (Better Design plugin open, installed via Plugins > Development, panel left open), discloses that the designer confirms in the panel, that unmappable layers are reported rather than dropped, and that drawInFigma mutates the Figma file and should be run on a copy. It also spells out the default two-call protocol (prompt file + image out, then frameId/answerPath back).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Length is defensible for 13 parameters and a two-phase workflow, and the core purpose is front-loaded. But it is delivered as one dense wall of text with no segmentation, and the prerequisite/workflow/option sentences interleave so an agent must read the whole paragraph to find the mode switch.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the description still covers prerequisites, side effects, and both workflow phases. What it lacks is any signal about failure behavior when the plugin is absent or a frame name doesn't resolve, which matters for a tool with a mandatory external prerequisite.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the per-parameter baseline is already met; the description adds cross-parameter sequencing the schema does not (frameId and answerPath belong to the second call, provider 'agent' means the agent rebuilds, projectId implies kit plus named parts). Some of this repeats the enum descriptions almost verbatim.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('reads a frame ... returns it as one HTML page, built from the same components the design system ships') and immediately separates the default library path from the 'model' path. It is clear what the tool produces, though the opening 'returns it as one HTML page' understates that it creates/writes a file, and the multi-mode sprawl slightly blurs the core purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing conditions: use mode 'model' plus a catalog design system for frames not built from a Better Design library, pass projectId to build with a client's kit, use 'blocks' for a cheaper model. It never contrasts this tool against siblings like read-figma-kit or make-sales-page, so the alternative-selection guidance stops at the parameter level.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server