I have been seeing running Claude with Penpot MCP often uses thousands of tokens just to change static wireframes into components and variants for examples. Claude is often bumping around and being like oh weird this doesn’t work, this is a caveat. Have other people seen Penpot MCP use lots of tokens out of the box? What did you do to make the token usage more efficient? Is there a Claude skill that has Penpot API and MCP information so that it understands the API better instead of trying every JavaScript framework?
I am unable to programmatically bind tokens in Penpot 2.15, and I’ve resorted to copying a markdown file from the Penpot Plugin API High-Level Overview to stop using the MCP so much because it uses so many tokens. I’m unable to upload a markdown file to the forum.
in the past 2 weeks I have been using claude as part of making a design system - and yes - i too have been extremely frustrated and disheartened by the stumbling blocks being experienced by Claude - to the point that I am again having to abandon my hopes of using Penpot as a meaning input or a output of a design system tool I am creating. I have actually managed to do a few things, but it has taken access of Claude by the REST API, the MCP/Plugin API, AND the Claude browser extension which is spending enormous time and tokens to do what should be simple tasks and finding many “not working”, “not saving”, confusion and blocking on how to do basic things like saving a new token, etc. So maybe will check back after another while.
Hi! I would love to know more about your workflows and examples but right now what I would like to know for sure is whether you are using MCP Server “remote” (bundled) with design.penpot.app or some other setup (local MCP server, different Penpot instance, etc). Thak you!
Hmm, we’re investigating an issue around design token application with Penpot 2.15. This could be the culprit. Stay tuned.
1 Like
I had Claude create a set for this conversation. It will have all the bits and data you might want if you want to get into the weeds.
this document is what I was having Claude (Code) create as it worked through working with Penpot for itself to reference. It is probably the best detail of what Claude Code was actually finding for itself and marking as what it should know when trying Penpot interactivity. (the doc is linked from the summary too)
Thanks so much, I’m sharing this with the team to see if ou patch release today might have solved some of those issues.
let me also add that Claude wanted to resort to using the .penpot file - which had much easier access for Claude to pull values it wanted. I rejected that because as I currently understand it the file is not documented by Penpot and I am thinking there was talk or plans to change it to a binary version. From a dev (using AI) standpoint, if the file spec/schema was open and published changing it would be fine as long as the changes were documented when changed. Using the file would be checked and picked up by the AI and there could be added “versions” of file usage applied in the code. I am doing this exact thing for the token standards - I default to the DTCG 2025.10 spec and have the previous specs and drafts and then a Tokens Studio (Penpot uses) match/switch happening to adjust to the file on import or export. Same idea could be for .penpot files.
DTCG 2025.10 spec will surely be replaced in the future and my code is already able to add the new spec when it happens. same could be for .penpot - even breaking changes.
