MCP can be better

Help us improve Penpot
1

Hey team,

Thanks for the Penpot - it’s amazing how you support open-source. I hope we all can thrive together.

And one step in that direction is being competitive on the MCP front. I’m mostly a backend developer but with Claude Design I can get good looking designs for my side projects (which I hope to turn into commercial products).

I tried to export the same project in Paper and Penpot. Paper doesn’t even allow to adjust margins in the UI. They just went all in on MCP and selling MCP calls - on a free tier one can have a hundred per week and they reset on the daily basis.

From an end-user perspective that is not economically feasible: no margin adjustments in the UI - use MCP. And we charge you for MCP.

Again: a design tool is charging per call to make margin adjustment.

So I decided to give Penpot a try. Fortunately I did a couple of Figma lessons recently and felt comfortable with a professional design surface.

I wanted to show you difference between Claude Design → Paper and Claude Design → Penpot but can’t attach multiple images. So, here is a Penpot and it doesn’t appear to be even in the same league.

image
image1348×929 37.1 KB

For me, an unprofessional designer: Claude Design → Design Tool (Paper or Penpot) via Claude Code → edit → export into my web app via Claude Code is a massively leveraged workflow.

Claude’s perspective on what’s going on:

Why did you mess up the text alignment in Penpot but not in Paper

Paper’s write_html takes full CSS with flex, auto-sizing, and percentage widths that just work — it’s basically a browser renderer. Penpot’s
plugin API is a design tool API where every shape starts with fixed dimensions and you have to explicitly set horizontalSizing, verticalSizing,
layoutChild.horizontalSizing, growType on each element individually. Missing any one of those defaults to "fix" at 100px, which clips text and
collapses rows.

Paper: write HTML once, everything flows.
Penpot: create each shape, then configure 3-4 sizing properties per element, and some of them don’t persist on the first set.

I’m happy to jump and a call and show all the details.

Best of luck!

1 Like
2

Here is a view of the same design imported from Claude Design by Paper and Penpot.

paper-vs-penpot
paper-vs-penpot903×1474 148 KB

3

Thanks for the thoughtful write-up :slight_smile: this is genuinely helpful.

From your description, it seems the issue isn’t MCP support on its own, but the mismatch between a browser-style HTML rendering flow and Penpot’s API model. In Penpot, layout, sizing, and text behavior have to be defined much more explicitly, which likely explains part of the gap you’re seeing.

To help us understand where things break down, it would be useful to get a bit more detail on a few points:

Claude Design → Claude Code → Penpot
You mentioned using Claude Design through Claude Code to generate, edit, and export. Do you know which model and agent setup handled the Penpot MCP calls? That would help narrow down whether the issue comes from the API itself, the agent’s assumptions, or how the model was instructed.

Same project in Paper vs. Penpot
Since you tried exporting the same project into both tools, seeing the difference would be very helpful. Even a small example or a couple of screenshots would make it easier to compare what Paper handles automatically versus what needs to be spelled out for Penpot.

Expected workflow
The flow you described — Claude Design → design tool via Claude Code → edit → export into a web app. Is exactly the kind of setup we want to support. In that context, what would “good enough” look like for Penpot? For example, are you mainly looking for better auto-layout generation, something closer to HTML-like import behavior, more reliable text sizing, or higher-level MCP commands?

Happy to dig deeper on this. If it’s easier, we could also walk through the flow together and look at where Paper and Penpot start to diverge.

Appreciate you taking the time to lay this out. The comparison with Paper makes the friction much clearer.

1 Like
4

Hi Juan,

From your description, it seems the issue isn’t MCP support on its own, but the mismatch between a browser-style HTML rendering flow and Penpot’s API model.

Agreed. And it may turn out that React components is an ultimate interoperability format between LLMs and design tools.

Onto your questions:

  1. Claude Design → Claude Code → Penpot

Do you know which model and agent setup handled the Penpot MCP calls?

I use latest available Opus in the maximum effort mode. Currently Opus 4.6

Same project in Paper vs. Penpot

Since you tried exporting the same project into both tools, seeing the difference would be very helpful. Even a small example or a couple of screenshots would make it easier to compare what Paper handles automatically versus what needs to be spelled out for Penpot.

I can prepare something because I have more pages coming up. At the same time I want to suggest to try this out personally. This might be a beginning of the debugging process.
You’ll also see how a Paper’s desktop app, even though wrapped in the electron makes the MCP setup easier in comparison to having always on floating panel.

And I’m saying that as a person who prefer web apps to running Electron apps locally.

Expected workflow

In that context, what would “good enough” look like for Penpot? For example, are you mainly looking for better auto-layout generation, something closer to HTML-like import behavior, more reliable text sizing, or higher-level MCP commands?

In human terms - I want a tool to be transparent. Import from Claude Design, edit, tell Claude Code to implement.

Happy to dig deeper on this. If it’s easier, we could also walk through the flow together and look at where Paper and Penpot start to diverge.

Great. I’ll shoot you a DM when I will setup the next page. So I can show how’s it working in both tools.

1 Like