Hi, I am testing Penpot with MCP using VS Code + Cline + DeepSeek LLM. The MCP link runs smoothly, and all components are rendered as per the penpot file, including interactions. However, when testing the responsive behaviour on a 10-inch table, a 15-inch laptop & a 15-inch DeepSeek a report of a known bug in Penpot’s responsive behaviour which sounds true on paper. When tested using actual devices" not browser device emulation" laptop view renders as per my penpot size 1255 x 600 px, but desktop screen test result in empty space of lef, right and bottom on 22 inch monitor. I don’t have the knowledge to validate the DeepSeek report and need someone to help me.
This is my question to DeeSeek:
" before troubleshooting. My penpot design was made with FR units for responsive behavior. Since this is my first MVP using penpot there might be mistakes from my end. why you need me to spoon feed cline what to do when my main concern that my penpot design should be communicated properly using MCP "
This is DeepSeek reponse:
You’re asking the right question, and I owe you a straight answer: **Cline’s report is not because MCP failed to communicate your design. It’s because of a known, documented limitation in the Penpot MCP and Plugin API itself.**
### The Root Cause: Penpot’s API Can’t Reliably Communicate Flex Sizing
Your design intent (Option A, responsive fill) was expressed in Penpot using **flex layout sizing properties** — specifically `horizontalSizing: “fill”` and `verticalSizing: “auto”`.
Here’s the problem: **These properties are broken in Penpot’s Plugin API**, which is what MCP uses to read your design.
There is an open bug report on Penpot’s official GitHub (Issue #39) stating exactly this: *“FlexLayout sizing properties cannot be set via API… the sizing properties do not seem to actually exist in the implementation and cannot be set.”*
A second bug report (#8520) confirms the same for reading: setting `flex.horizontalSizing = “auto”` is “accepted by the setter and reads back correctly, but the board retains its `resize()` dimensions. The board never actually auto-sizes to fit its content.”
**In plain terms:** Your Penpot design says “this should fill the width.” But when MCP asks Penpot for the layout details, the API either doesn’t return that information or returns it in a broken state. Cline never *saw* the responsive intent, because Penpot’s API didn’t *send* it.
### Why Cline Fell Back to Fixed Pixels
Without reliable sizing data from MCP, Cline did the only thing it could: it read the **static width and height** of each element (the `resize()` dimensions) and reproduced those as fixed CSS pixels. That’s why your table became `width: 976px` instead of `width: 100%`.
Cline wasn’t ignoring your design. It was using the only data Penpot’s API would give it.
### The Workarounds (What Actually Works)
**1. Use the Inspect panel’s CSS export, not MCP, for layout values.**
Penpot’s Inspect panel generates **real CSS** (Flexbox/Grid) that you can copy directly. This CSS *does* include the correct responsive properties (like `display: flex`, `flex: 1`, `width: 100%`). The MCP path is broken for sizing; the Inspect export path is not.
**2. Feed the generated CSS to Cline as a reference file.**
Instead of asking Cline to read Penpot via MCP, you:
- Open Penpot, select the Products board
- Click Inspect → copy the generated CSS
- Save it as `penpot-products.css` in your project
- Tell Cline: *“This is the Penpot-generated CSS. Use it as the source of truth for layout properties.”*
This bypasses the broken MCP sizing path entirely.
**3. Or accept that you’ll need to specify the fix manually (what we were doing).**
Since MCP can’t communicate sizing, there’s no way for Cline to “discover” the responsive intent on its own. You have to tell it.
### The Honest Bottom Line
You were right to expect MCP to carry your design intent. It should. But **Penpot’s MCP/Plugin API has a documented bug** that prevents it from doing so for flex sizing. This is a limitation of the tool, not a mistake on your part.
The fix prompt I wrote is still the right move — but now you know *why* it’s necessary. It’s not spoon-feeding Cline. It’s working around a broken bridge.
**For future projects:** Use the Inspect panel’s CSS export as your design-to-code bridge, not MCP’s layout reading. MCP is good for structure (what elements exist, what text they contain, what colors they use) but unreliable for layout behavior (how they resize).
