|How an MCP design tool works

Why "give the agent an API" is not enough

Most design tools have an API. Very few are pleasant for an agent, and the reason is granularity. If the smallest unit you can write is a whole file or a whole frame, every change is a rewrite: the model has to reconstruct everything it is not changing, and any detail you adjusted by hand in the meantime is quietly destroyed.

The other failure is the opposite — an API so low-level that placing a button takes fourteen calls. Models are bad at long mechanical sequences and each call is a chance to drift. What works is a middle layer: operations that are meaningful units of design intent.

The document has to be addressable

Every node needs a stable ID, and a node has to be changeable without touching its neighbours. That is what makes a targeted edit possible: patch this node’s padding, leave the other four hundred alone.

It also has to be structured rather than free-form. A layout expressed as values — direction, gap, alignment, tokens — is something a model can reason about and change precisely. The same layout expressed as a CSS class string is something it can only pattern-match against, and it will get it subtly wrong in ways nobody notices until the export.

The operations have to be typed and validated

Every write should be a transaction with a schema, and the server should reject anything that does not fit rather than storing it. This sounds bureaucratic and is actually the thing that makes agent editing survivable: an invalid value caught at the boundary is an error message the model can correct from, and an invalid value written to the document is a bug you find three days later.

Two more properties earn their keep. An idempotency ID means a retried call does not apply twice. A precondition on the fields being touched means an edit made against a stale read fails loudly instead of silently reverting something you changed by hand in the meantime.

• +Reads: readNode, readTree, searchNodes, getDesignContext
• +Writes: createPage, insertNodes, patchNodes, moveNodes, deleteNodes
• +Reuse: createComponent, createInstance, setTokens
• +Motion: setAnimations, animateNodes

The model has to be able to look

This is the part most integrations skip, and it is the one that changes the output most. A model writing layout without seeing it is working blind: it has no way to notice that the heading overlaps the image or that the card is three times too tall.

Render the document to an image and hand it back. The loop becomes: build, look, fix. Agents are good at that loop and bad at the alternative, which is predicting pixel positions from a tree of numbers.

It has to be safe to be wrong

Agents make confident mistakes, so the interesting question is what happens afterwards. Version history means you can roll back. A transaction log means you can see exactly what changed and when. Branches mean speculative work never touches the thing you were happy with.

Given those, the right instruction to an agent is not "be careful" but "work on a branch" — which is a thing it can actually do, rather than a mood.

And the human has to still be able to edit

The failure mode of every generate-then-edit tool is that manual changes and generated changes fight. If the agent regenerates a page, your hand-tuned spacing is gone; if you edit the output, the next generation overwrites it.

One document, one set of operations, both parties using them, is what avoids that. When an agent’s edit is the same kind of transaction as a drag, there is nothing to reconcile — you can nudge a node the moment after it was inserted, and the agent’s next read sees where you put it.

Questions