DAES Token Manager is an open source Figma plugin that stores design tokens in the W3C DTCG 2025.10 format, the shape Style Dictionary already reads. Author every token type, resolve aliases live, apply them to nodes and variables, and push plain JSON to your own repo. No server of ours in between.
The spec is the storage format, not an export target.
No server of ours between you and your tokens.
Reach your token store from an agent running on your own machine.
Apache-2.0. Read it, fork it, run your own build.
Author in DTCG 2025.10, scaffold an architecture, theme it, and bind tokens to nodes and variables. Sync with your own repo, and reach the same token tree from your agent over a local bridge.
An MCP server runs from npx on your machine and reaches the plugin over a localhost websocket. Your agent reads the live token tree, resolves an alias, or writes an edit back through the plugin's own import path. No Figma access token, and nothing leaves your machine.
Tokens are stored in the shape the DTCG 2025.10 spec describes: $type and $value, references in dot notation, no plugin wrapper around them. There is no legacy format underneath and no conversion on the way out, so the JSON in your repo is the JSON the plugin edits.
Your tokens live in the Figma file and in your own Git repository. The plugin talks to the Figma API and your provider directly, so there is no server of ours in that path. Accounts and login are the only things we host, and they run in Germany.
Every token type the spec defines, stored in the shape DTCG 2025.10 describes, not converted into it on the way out.
Reach the token store from an agent over a local MCP bridge and work next to it in one interface, instead of describing your tokens in a prompt.
Create a theme and link the token sets that belong to it, so the same token stops being maintained twice in two places.
Connect the token repository you already have: GitHub, GitLab, or a plain remote URL for read-only sources.
Bind tokens straight to Figma nodes, so a layer carries the decision instead of a copied value.
Skip the long first pass at a token architecture. The wizard scaffolds a working three-tier system, contrast-checked, and you take it from there.
Your tokens never reach our infrastructure. The plugin talks to Figma and your Git provider directly. Accounts and login are the only things we host, and they run in Germany.
Push your tokens into Figma variables, so the values in the file come from the token store instead of being retyped by hand.
Sync copy alongside design decisions. Share access once and text changes stop being another round of manual edits, without buying more Figma seats.
2 of these 9 features sit outside the free plan. See what is in each plan.
What the established token tools already give you, and where this one is genuinely different.
| Criterion | DAES Token Manager | Other token tools |
|---|---|---|
| Table stakes | ||
| Token types beyond colour and number | Ten types including shadow, transition, cubicBezier and strokeStyle. Typography and gradient in progress. | Established plugins cover a broad type set, composite types included |
| Live alias resolution while editing | Computed value shown inline; cycles and dangling references rejected on save | Standard in plugin-based tools |
| Apply tokens to Figma nodes | Typed applicators write the matching Figma property | Standard in plugin-based tools |
| Tokens to Figma variables | Push token sets into variable collections | Standard in plugin-based tools |
| Themes across brand, mode and density | Token sets linked per axis, switched together | Usually modelled as themes over token sets |
| Git sync | GitHub, GitLab, or a read-only remote URL | Widely supported, often across a longer provider list |
| Where this differs | ||
| DTCG 2025.10 as the storage format | Native, with no legacy format underneath | Commonly a proprietary or legacy format, with DTCG offered as an export or an opt-in |
| Guided setup for a new token architecture | The wizard generates a three-tier system across brand, mode and density, contrast-checked before it writes | Starter kits and templates to copy, rather than a generator that writes the structure for you |
| Copy and localisation keys alongside tokens | Phrase keys sync with your design decisions, without buying more Figma seats | Design tokens only; copy lives in a separate localisation pipeline |
| Agent access over MCP | Local MCP bridge over a localhost websocket, with no vendor cloud in the path | Where MCP access exists, it starts at a paid tier |
| Vendor infrastructure in the token path | None. Accounts and login are hosted in Germany, token data is not stored at all. | Plugin-only sync keeps it out; hosted platform tiers put your tokens on the vendor's servers |
| Plugin licence | Apache-2.0, with an explicit patent grant | Permissive open source is common at the plugin layer; hosted platform tiers are closed |
| Price | Free during the beta. Planned after that: a free plan, €29 per seat per month, €130 per month for five seats, Enterprise on request. Less if paid yearly. | Free plugin tiers are common; hosted platforms are paid, usually billed annually |
The established token tools have years of production use, longer provider lists, and hosted platforms your organisation can buy on a purchase order. DAES Token Manager stores tokens in the DTCG 2025.10 shape with no legacy format underneath, keeps your token data out of any vendor infrastructure, and scaffolds a three-tier architecture for you if you are starting from scratch. If the storage format matters to you, or a vendor cloud in your token path is a problem, start here. If you need a mature ecosystem today, use something that already has one.
One token store, authored in Figma, committed to your repo. That's the whole loop.
Tap a step to see the panel it happens in. You need a Figma file and somewhere to put the JSON. That is the entire prerequisite list.
The spec is still moving and every design system carries an edge case this plugin hasn't met yet. Those edge cases are the roadmap, which only works if the people hitting them can reach the people building it.
Support questions, spec arguments, and half-formed ideas. The quickest way to get unstuck, and where most work is discussed before anyone opens an issue.
Bugs, feature requests, and the roadmap. A report with a token value and a repro gets picked up fastest. The failing case usually writes the test.
Read it, fork it, audit it, run your own build. A tool that decides what your design system may express should not be a black box.
Support questions, feedback on the token model, and early looks at what's next. No ticket queue: the people building it are in the same channel.
dimension, duration, number, cubicBezier, fontFamily, fontWeight, strokeStyle, border, shadow and transition are implemented against the 2025.10 spec. color is supported with 14 color spaces; its full migration to the 2025.10 shape is in progress. typography and gradient are planned.Tell us what your token setup looks like and we'll send you in.