Figma

The same tokens, as Figma Variables.

Every theme here publishes a W3C DTCG token file. The plugin fetches it and creates a variable collection with Light and Dark modes: every colour token, radius and spacing as numbers, font families as strings. Measured role tokens are named color/…; the derived chart and sidebar groups are named derived/…, so the file's honesty survives the import. Any public site's tokens come the same way, with its own declared names by scope: /api/decode-url?url=…&format=tokens.

Where it stands

The plugin is finished as code and runs from its manifest as a development plugin. It is not yet listed in the Figma Community; that listing needs an account, listing copy and a cover, and is on the owner's list. Until then, anyone can install it in two minutes:

Get figma-plugin/ from the repository (manifest, code.js, dist-ui.html).
In Figma: Plugins → Development → Import plugin from manifest… and pick manifest.json.
Run it, type a theme slug such as deep-ocean or any website such as stripe.com, click Fetch and create variables.

The only network request the plugin makes is the tokens file on csscreme.com. No account, no key, no telemetry. Shadows arrive as strings holding the CSS box-shadow, because Figma has no shadow variable type; the plugin says so rather than dropping them.

Two doors, one mapping

There are two ways to land these Variables in a file, and they run the same transform.

The plugin (above). Fetches the tokens file and writes the collection. Needs a Figma account and the desktop app for a development plugin; no paid seat, no MCP.
Figma's own MCP, use_figma. It runs JavaScript in a file through the Plugin API from the remote server, so it reaches the canvas with no desktop plugin at all. We publish a ready recipe: the mapper's output for a theme, inlined, plus the plugin's own apply step, so the script makes no network request inside Figma and cannot drift from what the plugin writes. /d/deep-ocean.figma.js is one; any public site gets the same from /api/decode-url?url=…&format=figma, with the site's own declared token names as declared/… variables beside the roles.

Honest about the seat: Figma's MCP server is available on the seats Figma says it is, and Figma's own documentation is the authority on that; nothing on this page changes it. Both doors write Light and Dark modes, which Figma's read tool get_variable_defs cannot return at all.

The layers half: html.to.design

Tokens are not layers. html.to.design imports a rendered page as editable Figma layers, and since 2024 offers to create local styles and variables from what it detects. What its own material never shows is a single variable name, a collection or a mode, and its dark and light captures are separate imports. Ours carry no layers at all and are nothing but names and modes: color/… with Light and Dark, and for a decoded site the vocabulary the site itself declared.

So the round trip is three steps, not one product: import the layers with html.to.design; name them from our tokens file for the same URL (format=aliases maps every hex an import knows back to the site's declared names); write the modes with either door above.

Measured on our side only. Their variable output was not measured (it needs a Figma seat and an account we did not create), so this page claims nothing about its names.

Why this and not a screenshot paste

Pattern libraries offer "copy to Figma" and paste a picture. A picture cannot become a variable, cannot switch modes, and cannot be checked for contrast. Tokens can. The round trip is the point: the file an agent reads (DESIGN.md), the file a build reads (DTCG), and the file a designer reads (Variables) are the same tokens with the same fingerprint.