# Design Tokens: Manual Setup and AI Workflow (Penpot) > [!question] Lingering Questions > - Which model/agent backs the Penpot MCP, and how does it infer token names and the global/semantic split? The video shows results, not the mechanism. > - What happens on conflicting or near-duplicate raw values during AI inference — does the agent flag them or silently pick one? > - Can inferred tokens export to the DTCG (Design Tokens Community Group) JSON format for downstream tools, including a WordPress `theme.json` pipeline? > [!tip] Article Ideas > - Map Penpot's global → semantic → composite token structure directly onto `theme.json` palette/spacing/typography presets; test whether the reference chain survives export. > [!link] Cross Reference > - [[3. Resources/MOCs/Visual Thinking MOC]] — token systems as a visual-thinking / design-system organizing pattern. > - [[The Design File as a Programmable Bidirectional Surface for Agents]] — related claim from a different Penpot source (2026-06-14) about agent-editable design files generally; this note's claim is narrower (bounded specifically by API exposure). > [!quote] Vocabulary > - **Global vs. semantic tokens** — global tokens hold raw values (a hex code); semantic tokens reference globals, so styling resolves through a chain rather than repeated raw values. > - **Composite tokens** — tokens built from other tokens (e.g., typography = font family + size + weight; shadow = color + blur + offset). ## Bibliographic capsule Short Penpot tutorial video (~4 min, published 2026-06-29) demonstrating manual design-token setup in Penpot, then the same task via Penpot's MCP-driven AI agent. ## Author's thesis (as argued) Design tokens replace hard-coded, inconsistent style values with a referenced system (global raw values → semantic references → composite tokens), and this system can be built by hand or inferred and applied directly by an AI agent — because the agent can read Penpot's exposed plugins API. ## Key arguments (≤3) 1. **Tokens are organized in sets that function like collections** — a `global` set holding raw values and a `semantic` set that references those globals, so a single change propagates everywhere it's used. 2. **Composite tokens (typography, shadows) are built from other tokens**, and math operations on values are supported, giving the system real computational structure, not just naming conventions. 3. **An AI agent can extract, name, and apply the same token structure to an untokenized file** because Penpot exposes a complete plugins API the agent can read and act on directly — the capability is bounded by what the tool exposes, not by the agent's general skill. ## Claim atoms ### Design tokens replace hard-coded, inconsistent style values > [!quote] ID:rw_pending > "If your designs are still full of hard-coded colors, random spacing values, and inconsistent styles, today we fix that using design tokens" Where/why: opening of the video (~00:00) — states the core problem tokens solve. ### Penpot groups tokens into global and semantic sets > [!quote] ID:rw_pending > "Inside pimpot, you can group tokens into sets. As you can see here, I have two sets, global with this token types and semantic." Where/why: ~00:30 ("pimpot" is an auto-caption error for Penpot) — the two-layer structure the rest of the workflow depends on. ### Agent applies tokens by reading Penpot's plugins API > [!quote] ID:rw_pending > "the agent is able to apply the tokens as you can see here directly in my design and component because agent can read perfectly the plugins API that penpot is exposing" Where/why: ~02:30, the AI-workflow payoff — ties agent capability to API exposure, a transferable principle beyond Penpot specifically. Promoted below. ## Permanent candidates - **An agent's design-editing power is bounded by the tool's exposed API** (H3) — not yet captured by an existing note (the closest neighbor, [[The Design File as a Programmable Bidirectional Surface for Agents]], comes from a different source and argues the broader "design file as agent surface" point rather than this narrower API-exposure-bounds-capability claim). Promoted below as a new Permanent note. ## Processing checklist - [x] Checked for an existing Permanent note before creating — none found for this specific source; checked the neighboring Penpot-related notes for duplication and confirmed this claim is distinct. - [x] Promoted the API-boundedness claim to a new Permanent note. - [ ] Test Penpot MCP on a real untokenized file and log the name-correction rate before treating the "agent applies perfectly" framing as reliable rather than a single successful demo. - [x] Connect into [[3. Resources/MOCs/Visual Thinking MOC]] and [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]]. ## Metadata - Source: [[3. Resources/Literature Notes/Design Tokens Manual Setup and AI Workflow (Penpot)]] ## Links - [[3. Resources/MOCs/Visual Thinking MOC]] — token systems as an organizing structure for visual/design decisions. - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — agent capability bounded by tool API exposure is a general AI-tooling pattern.