Wireframe

Updated 8 Oct 20262 min read

Send "type": "wireframe".

Create a UI WIREFRAME screen (render_wireframe) as a document of TYPED WIDGETS: navbar, appbar, sidebar, tabbar, button, input, card, list, table, chart, image box, hero, pricing and about sixty more, drawn by MockFlow in the frame's current style (outline, sketchy, blueprint, hi-fi, iOS liquid glass, Windows Fluent or Android Material, each in light or dark mode, with an optional brand colour and font, switched by the user at any time). You write the document, never HTML or CSS.

Also available as the MCP tool render_wireframe. The same payload works through either surface.

Fields

data

titlestring

Short screen name shown as the frame title

deviceenum<string>

Device frame drawn around the screen; also the default size. One of phone, tablet, desktop, mac, windows, car, tv or none.

wnumber

Frame width in px (default: the device width)

hnumber

Frame height in px (default: the device height; more for a long page)

themeenum<string>

Drawing style; leave out unless the user asked for a look. One of outline, sketchy, blueprint, hifi, glass, fluent or android.

modeenum<string>

Dark mode of the style; leave out unless the user asked for dark mode. One of light or dark.

accentstring

Brand colour for buttons, links and selection; leave out unless the user named one or the brand colour is known

fontstring

Google Fonts family name for the text; leave out unless the user named a font or a brand whose typeface is known

sectionsobject[]

A NEW screen as structure, top to bottom: { name, bleed?, pin?, space?, rows: [ { cols: [ { span, align?, items: [ widget | { inline: [widgets] } ] } ], valign?, align? } ] }, as the step-1 reply describes. Leave out (with nodes) to receive the widget catalog instead of drawing

asideobject

With sections: an optional full-height rail down the left of an app screen, e.g. { "type": "sidebar", "w": 240, "props": {...} }

nodesobject[]

Only when MODIFYING an existing frame: its widgets in drawing order with px positions and ids. A new screen uses sections instead

Child attributes

idstring

Only when modifying: the id of a widget kept from the existing document

typestringrequired

Widget key exactly as returned by the step-1 catalog call

xnumberrequired

ynumberrequired

wnumberrequired

hnumberrequired

propsobject

Widget props per the catalog schema

styleobject

The widget's own look over the theme, as STYLE in the catalog describes; keep it as it is when modifying unless the user changes that widget's look

Example

{
  "type": "wireframe",
  "data": {
    "title": "Q4 Launch Planning",
    "device": "phone",
    "w": 0,
    "h": 0,
    "theme": "outline",
    "mode": "light"
  }
}

Was this page helpful?