Adobe XD to a coding agent: getting out of a frozen tool

Adobe stopped selling XD as a standalone app to new customers on 22 June 2023. From 2024 it has been in maintenance mode: bugs and security updates, no new features. Adobe has never announced a formal end-of-life date, and existing Creative Cloud customers still have access.

That combination is the awkward part. There is no deadline forcing anyone to act, so nothing happens — and meanwhile every tool built after 2023 was built for other file formats. MCP arrived after XD stopped receiving feature work, which means there is no design-tool MCP server for it and there is not going to be one.

So this is not a handoff guide. Every other guide here describes a live route from a design tool to an agent. This one describes getting out.

What you are actually working with

An XD file is a proprietary format that a frozen application reads. Practically, that leaves three ways to get anything out:

• Export assets — PNG, SVG, PDF — from XD itself, which still works.
• Read the design specs by hand from the XD interface, which also still works.
• Migrate the file into a tool with a future, and use that tool's route.

There is no fourth option involving an API, a plugin ecosystem worth investing in, or a server that speaks to your agent. Anyone waiting for one is waiting for a product decision Adobe made in the other direction three years ago.

If what you are actually holding is a PSD rather than an XD file, the situation is better than it looks: Photoshop's format is old enough to be thoroughly documented and readable by parsers without Adobe running. XD's is not.

Migrate the decisions before the screens

The instinct is to move the artwork: open every artboard, rebuild it in Figma, tick it off. That is the expensive half and mostly the wrong half.

Most artboards in an XD file are obsolete. They describe screens that shipped and changed, features that were cut, and states nobody implemented. Faithfully rebuilding them buys an accurate record of what somebody thought in 2022.

What is genuinely expensive to reconstruct is small enough to fit on a page:

• The colour roles. Not the hexes — the hexes are recoverable from any artboard. Which grey is the page, which is the card, which is the hairline, and what the accent is allowed to touch. Nothing in the file records this, and the person who decided it may not be here.
• The type scale, and which sizes are real. An XD file will contain 14, 15, 16 and 17 because a text box got nudged. Only some of those are the system.
• Spacing and radius. The numbers, not adjectives.
• The negative constraints. What this product is never allowed to look like. This is the category most likely to be lost entirely, and it does more work per word than anything else, because it closes off exactly the defaults a generative tool will otherwise reach for.

Write those down first, in a form that is not an XD file. They are the part with a future, and they take an afternoon.

Then pick a destination

Both realistic destinations are supported tools with active roadmaps.

Figma is the stronger choice if handing designs to a coding agent is the point, because of the Dev Mode MCP server — an agent receives a component tree, variables and Code Connect mappings as structured data rather than inferring from a picture. The Figma route covers what that does and does not carry.

Sketch is the other supported option, with an MCP server built into the Mac app and an agent story of its own. The Sketch route covers it, including the Mac-only constraint.

For the migration itself, rebuild rather than convert. Converters produce a structurally faithful copy of a file authored without Auto Layout, variables or components — and a file rebuilt badly in Figma generates worse code than a file redrawn properly, because the agent reads the structure it is given. You are not moving a file. You are taking the chance to build one that a machine can read.

What this costs if you wait

Nothing dramatic, which is the problem. XD keeps opening. The file keeps rendering. The cost is entirely opportunity, and it accrues quietly.

Every screen built by an agent during that time gets no design context at all, because there is no route from XD to an agent. The rules stay in a file only one frozen application reads. The person who knows which of those four greys is the card leaves, and the knowledge leaves with them.

That is worth separating from the tooling question, because it is the durable one. A design tool is where the artwork lives, and it is going to change again — XD is proof. The decisions behind the artwork are what should outlive any of them, and they should live somewhere that is not a proprietary file: readable, reviewable, and available to the agent at the moment it writes code. A few properties are worth insisting on in anything holding them, and which moodspec's endpoint enforces: it is read-only, the token is scoped to one canvas rather than an account, and an agent can only ever propose a change through propose_change, which a person approves. The docs are one block of config.

The test

Open your XD file and answer three questions without opening any other document: which grey is the card background, which of your type sizes is the body size, and what is the accent colour forbidden from touching.

If you can answer all three, that knowledge is in your head and not in the file — write it down this week, because it is the only copy. If you cannot answer them, it has already gone, and the migration you are putting off is not the artwork. It is the reconstruction of decisions nobody recorded while the tool that held them was still being updated.

Further reading

• Figma MCP server documentation — what a supported destination offers a coding agent
• Sketch MCP server — the other supported destination, and its constraints
• Apple Human Interface Guidelines — a worked example of decisions written down with their reasons
• Taste for Makers — Paul Graham, on naming the properties that make design good