The MCP Tool That’s Changed How I Design

Earlier in the week I ran a test: export a set of HUX icons from Figma via MCP. Simple enough. The model replaced every fill colour with #000000. I checked a manual export — the SVGs came through in HUX primary, no issue. The fault sat in the prompt for Claude Code, not the tool.

I fed those results back to Opus 4.6. It wrote an updated prompt and pushed it to my Notion via a knowledge capture skill I'd built for exactly this kind of feedback loop.

What struck me wasn't the fix. It was watching the model think through the workflow. Each step exposed a better way to frame the task. For example, my prompt had specified "components" when the icons were vectors — no component logic involved. A naming slip. I'd also input the primitive tokens (HUX-3, HUX-HH) but skipped the semantic layer (base/small/medium/large). None of this broke the output. All of it sharpened how I think about the input.

I liked that. The tool taught me something about my own system while it did the work.

Complex tasks like variable creation used to sit on the backlog because the effort felt disproportionate to the result. I'd built all my Webflow variables by hand to match the design system, but never mirrored them in Figma. Too manual. Too tedious. It waited.

So I tested whether the MCP could reach into my Webflow variables, extract the parameters, and bring them into Figma — retroactively syncing what I'd avoided for months.

Thirty seconds. Done. Hours of grunt work resolved in less time than it takes to describe it. That single result gave me the confidence to try more complex component workflows. Follow-up to come.

There was a moment during the variables test worth mentioning. One of the type scale headlines came through in all caps after the MCP had run. I thought the tool had made a mistake — Headline 2, all caps, clearly wrong. Then I looked at the tab I'd left open. The all-caps style was mine. I'd set it and forgotten.

Human error remains a factor. Good to remember.

I expected MCP to save time on the mechanical work. Variables. Token mappings. The repetitive, wrist-destroying tasks that eat hours and deliver nothing a client would notice.

It did all of that. Two hundred variables in seconds. Token mappings that would have taken an afternoon, done before the coffee went cold.

But the real shift happened somewhere else.

It forced me to think about naming before I built anything. That changed everything downstream.

Here's what most teams miss: naming in a design tool isn't housekeeping. It's architecture.

Every layer, every frame, every variable collection carries intent — or carries confusion. When a file is called Onboarding but the team searches for signup flow, it vanishes. When a component is called Frame 47, the person who inherits your library inherits your mess.

The discipline of naming well is the discipline of clear thought. MCP makes that discipline non-negotiable, because the machine reads what you name things.

A human designer can squint at a bad layer name and guess what it means. An MCP tool cannot. It takes your naming at face value. Incoherent structure produces incoherent automation. Garbage in, garbage out — at machine speed.

naming in a design tool isn't housekeeping. It's architecture.

This is where naming conventions stop being a preference and start being infrastructure.

In Figma, the hierarchy runs deep: teams, projects, files, pages, frames, components, variables. Each level is a chance for clarity or chaos.

‍Files benefit from a pattern that carries context. Onboarding (v2.1) [signup, auth, new-user] is searchable. It survives the six-month gap between creation and the moment someone needs it. Version numbers and keyword tags cost nothing and prevent lost work.

‍Pages do more than separate canvases — they structure the Assets Panel. When a designer enables your component library, page names become the top-level navigation. Name them with intent and adoption rises. Name them carelessly and the library gathers dust.

‍Frames around component groupings create dropdown categories in the Assets Panel. A frame called Apple Pay around four related components turns a flat list into something navigable. Capitalise each word. Use spaces, not camelCase — the panel is for people who scan fast.

‍Components need a convention the team can predict. I prefix private molecule-level components with an underscore — _Calendar-dayRow — so they stay out of the published library but remain available as nested instances. Parent name first, hyphen, molecule name. It scales without surprises.

‍Variable collections deserve the same attention. Split variables into Primitive and Semantic collections — Color – Primitive and Color – Semantic — and a layered system forms where Blue/500 is an option and Button/Background/Default is a choice. Groups within collections (via / in the variable name) add another level of navigation.

When this naming architecture holds, MCP tools can traverse it, query it, and build on it without hand-holding.

The surprise wasn't the automation. It was the space. I was able to do all of this whilst making a coffee and watching the trees sway in the wind.

Space to focus on the experience of the system rather than the mechanics of assembly. Space to consider whether a variable structure helps the team understand intent quickly, rather than spending that time mapping hex values to swatches by hand.

That distinction — experience versus mechanics — is the whole point.

Design systems exist to create coherence. Not consistency for its own sake, but a shared language that lets teams move with clarity and confidence. The mechanical work of assembly has always been a tax on the thinking work of design. MCP reduces the tax.

But only if the naming holds. Only if the architecture is sound.

This is the shift I keep returning to.

AI tools — MCP included — don't interpret intent. They read structure. They parse names. They follow the hierarchy you gave them.

A well-named, well-structured design system becomes a machine-readable brief. The tokens carry meaning. The collections carry logic. The naming carries intent that both people and tools can act on.

A poorly named system becomes noise at scale. MCP will faithfully execute against it, and the result will be fast, consistent, and wrong.

The system is the brief the machine reads. Get the naming right, get the structure right, and the tools amplify your thinking. Get it wrong, and they amplify the chaos.

If you've been watching MCP from the outside — curious but hesitant — here's what I'd suggest.

Don't start with the tool. Start with your naming.

Open your variable collections. Can a stranger read them and understand the intent? Open your component library. Can someone predict what a component is called before they search for it? Open your file browser. Can you find last quarter's work in under ten seconds?

If the answer is no, that's your starting point. Fix the naming. Build the architecture. Then bring in the MCP tool and watch it move through a system that was built to be read.

No need to overhaul everything overnight. No need to automate the lot. But time spent on the structure — the naming, the collections, the hierarchy — pays back every hour invested.

The tool is ready. The question is whether your system is ready for the tool.

Hamish Duncan is the founder of HUX, a design systems consultancy that helps creative agencies and product teams build coherent, machine-readable systems. Find out more at hux.works.