# Penpot's New MCP Server Exposes Design Tokens to AI Agents > Penpot's MCP server now lets AI agents read design tokens with five tools, far leaner than Figma's. It still assumes the tokens already live in a file. Source: https://waalee.ai/blog/penpot-mcp-server-design-tokens-origin-gap Published: 2026-11-01 · 4 min read · By The WAALEE Team Topics: Penpot MCP server, design tokens AI agents, Penpot design tokens API, Figma MCP server comparison, MCP server design system, AI coding tool design tokens Penpot, the open-source alternative to Figma, opened its design tokens up to its MCP server this fall. If you're running Claude Code, Cursor, or any other MCP client against a design file, that's a real capability most people missed: your agent can now read a Penpot file's tokens programmatically instead of just eyeballing a screenshot. It's a good move. It's also not the move that matters most for most teams, because Penpot's MCP server, like Figma's, only works on tokens that are already sitting inside a file somebody built by hand. ## What Penpot actually shipped [Penpot 2.14, nicknamed "Come Together,"](https://penpot.app/release-notes/2-14-come-together) put design tokens into the plugins API for the first time, per Penpot's own release notes. That's the part that matters under the hood: once tokens are reachable from the plugins API, any plugin, including an AI client talking over MCP, can read and write them instead of only a human clicking through the UI. The same release added token groups for collapsing long nested names, and a remap option so renaming a token doesn't quietly break every component that references it. The MCP side landed properly in [Penpot 2.15, "Master of Puppets."](https://penpot.app/release-notes/2-15-master-of-puppets) Per those release notes, the Penpot MCP server moved into an in-app experience with hosted remote access, so you can run it locally or point an AI client at a remote instance without standing up your own server. That's the bridge: a Claude Code or Cursor session now talks to a live Penpot file over a standard protocol, not a one-off export someone remembered to re-run. ## Five tools, not fifty The detail worth noticing is how small Penpot's MCP server actually is. Third-party coverage of the launch counted five tools total, including one called `execute_code` that runs arbitrary JavaScript inside the editor's plugin sandbox with full access to the Plugins API, against [Figma's Dev Mode MCP server](https://help.figma.com/hc/en-us/articles/32132100833559-Guide-to-the-Dev-Mode-MCP-Server), which exposes dozens of narrower, purpose-built tools for reading specific nodes, variables, and Code Connect mappings. Penpot's bet is that one flexible tool beats fifty specific ones, since `execute_code` can do anything the Plugins API can do. Figma's bet is the opposite: more tools, each narrower and more predictable for an agent to call correctly. Neither is obviously wrong. A smaller surface is easier to reason about and harder to misuse; a bigger one gives an agent more specific verbs instead of one blunt "run some code" hammer. - Penpot's tokens API and MCP server both assume the tokens already exist inside a Penpot file. Nothing here extracts a palette or type scale from an arbitrary live website. - Figma's Dev Mode MCP server carries the same assumption: it reads variables and styles already sitting in a Figma file, not values pulled fresh off a URL. - The remap-on-rename feature in 2.14 is a real quality-of-life win for teams that already maintain tokens by hand, since renaming used to silently break every reference to a token. - "Fewer, more flexible tools" versus "more, narrower tools" is the same MCP design tradeoff showing up in a design tool that most agent-framework debates argue about elsewhere. ## The gap is still where it's always been Open an MCP connection to either tool and an agent can now read your tokens cleanly. What it still can't do, through Penpot's MCP server, Figma's, or any design-file tool, is tell you what your tokens should be if nobody built that file yet. That's most teams. A marketing site built in Webflow five years ago, a product with no Figma file anyone kept current, a one-person shop that shipped a site and never opened a design tool since: none of that has tokens sitting in a file waiting to be read over MCP. The protocol got better. The source problem didn't move. Where tokens live right now, and where they still don't: - [Penpot MCP](https://penpot.app/release-notes/2-15-master-of-puppets): Five tools, including execute_code for full Plugins API access. Reads and writes tokens already inside a Penpot file, local or hosted remote. - [Figma Dev Mode MCP](https://help.figma.com/hc/en-us/articles/32132100833559-Guide-to-the-Dev-Mode-MCP-Server): Dozens of narrower tools for reading nodes, variables, and styles already inside a Figma file. - [WAALEE](https://waalee.ai/): Paste any live URL, no Penpot or Figma file required, and get the real colors, type scale, spacing, and radii back as W3C tokens an agent can use. ## Use the protocol, fix the source first None of this is an argument against either MCP server. Giving an agent live, programmatic access to tokens instead of a stale export is a genuine step forward, and Penpot deserves credit for shipping a smaller, more legible surface than Figma's rather than trying to out-tool it feature for feature. The point is sequencing. An MCP server makes an existing token file more useful to an agent. It doesn't create the file. If your brand's real values are only sitting on a shipped website, extract those first, as exact tokens, before worrying about which MCP server reads them best. The protocol layer is moving faster than the source layer right now, and that order isn't going to flip just because the tools keep getting better at the part that was already working.