I have spent years watching design-to-code tools promise the moon and hand back a pile of unmaintainable div soup. The Penpot MCP server experiment is the first one in a while that looks like actual progress. It is not another describe-to-generate gimmick. It is a bridge between what you asked for and the real design data.
If you have ever asked an AI like Claude to export a specific subset of icons from a design file, you know how that goes. It cannot see the file and it cannot touch the file, so it guesses from whatever you typed. The Penpot MCP server closes that gap, using the Model Context Protocol to give an LLM a direct, secure line into your design system.
Why the Penpot MCP server matters for developers
The standard AI design workflow is the bad and the ugly version of the job. You describe a button, the model invents a component that has nothing to do with your existing design system, and you inherit the technical debt. Penpot works from a “design-expressed-as-code” philosophy instead, so the files are programmatically accessible in the first place. I wrote about handling shifts like this in my guide to the WordPress AI website workflow.
The MCP server sits in the middle as a translator. It takes the intent you wrote in plain language, picks the matching operation (an export, a style update), and converts that into a structured API request. Since the request is bounded by your real design data, the model has far less room to hallucinate, which is the same problem I dug into in stopping AI hallucinations during the development cycle.
Technical specs and the stack
The stack is not exotic, and Penpot being open source means there is no black box to reverse-engineer. The experiment includes:
- A Python SDK and REST API integration;
- Full compliance with Model Context Protocol standards;
- Integration with MCP-enabled assistants like Cursor, Claude Desktop, and VS Code;
- Real-time design data syncing for semantic HTML and modular CSS generation.
The practical version is telling your IDE to refactor a layout to match the Penpot board while keeping your existing CSS utility classes. The MCP server supplies the context that makes a request like that land.
War story: when design context fails
I once worked on a large WooCommerce project where the design team had picked a shiny new tool with no structured API. Every padding value or hex code they changed, I had to go hunt down by hand in their CSS exports. Design updates and staging deploys kept racing each other, and the whole thing was a maintenance nightmare. With a Penpot MCP server back then I could have synced the design tokens automatically through WP-CLI or a transient-based cache refresh.
// Conceptual design-as-code snippet Penpot handles
{
"component": "PrimaryButton",
"styles": {
"background": "var(--penpot-color-primary)",
"padding": "12px 24px",
"border-radius": "4px"
}
}Because Penpot stores designs as code natively, the AI does not have to guess. It reads the JSON-like structure of the file and applies it. The same property is what makes the reverse direction work, code back to design, without the usual friction.
Where the experiment goes next
This is still an active experiment. Penpot is looking for beta testers to work out how these servers should handle complex design systems and documentation. If you are a developer who is tired of guessing what the designer meant, that is a decent place to spend an afternoon. The Penpot MCP showcase has demos of design-to-documentation workflows.
If this kind of integration work is eating your dev hours, I can take it on. I have been wrestling with WordPress since the 4.x days.
What this changes
None of this is about letting an AI draw icons. It is about a workable connection between the creative side of a product and the technical side. With the open-source Penpot API and the MCP standard, the workflow finally moves off describe and generate, and onto understand and execute.
