Building an MCP Server That Serves Design Tokens

Design tokens today are the closest thing you can get to a machine-readable brand contract, so they make the right foundation for any agent-facing brand system. Every token names a value, types it, and scopes it to a context, so a piece of software can consume it without interpreting a sentence of prose first. Compare that to how most brands actually store their identity: a PDF style guide, a Figma file full of annotated frames, a slide deck a marketing team built for an offsite two years ago. A human can read those documents and extract a hex code or a spacing rule, but an AI agent asked to do the same thing is guessing. It has no reliable way to confirm that the blue in paragraph three is the brand's primary color or a screenshot artifact. Tokens remove that guesswork by encoding brand values in three distinct levels: primitive tokens hold raw values like a hex code or a pixel number, semantic tokens reference those primitives for a specific use (a button's background, a body text color), and component tokens apply semantic values to a specific interface element. That structure mirrors how an agent needs to reason through a design decision: what the value is, what it means in context, and where it gets applied. A brand encoded this way is no longer a document someone has to interpret, but a dataset something can query.

The W3C DTCG Specification and the Token Interoperability Gap

Tokens only work this way if every tool agrees on what a token file looks like, and for years, no such agreement existed. The W3C Design Tokens Community Group settled the question with its first stable specification, version 2025.10, released October 28, 2025, with backing from dozens of organizations including Adobe, Figma, Google, Microsoft, Shopify, and Salesforce. The format is simple by design: every token is an object with a required $value and an optional $type, and tokens can reference other tokens through a curly-brace alias to avoid duplicating a raw value. A semantic token for a button's background doesn't hardcode a hex string. It points at a primitive color token instead. That single design choice is what makes the whole system worth building on: change the base value once, and every token referencing it updates automatically in any tool that reads the DTCG 2025.10 format, with no custom resolution step required per destination. Before this specification, a token pipeline moving from a design tool to a codebase to a documentation site often needed a translation layer at each hop, and drift could enter at any one of them. You can build a token file to this spec, and it travels cleanly across tools built on top of it today, so it makes more sense to build a server around tokens than around some proprietary export format.

MCP: the Right Protocol for Serving Brand Tokens

Format is one problem. The Model Context Protocol solves how brand tokens get delivered to agents, and it does so in a way that fits brand infrastructure specifically. MCP gives an agent a standard way to ask a server what the current brand values are, rather than relying on whatever was baked into its training data or pasted into a prompt at the start of a session. Cloudflare's August 2026 coverage of the MCP 2026-07-28 specification describes the protocol as now fully stateless: every request carries its own protocol version, client identity, and required capabilities, so there's no session state to store and no sticky routing to manage. That matters if you are building a server, because it means a token server can run as a simple, lightweight service, and it needs no careful session management the way stateful infrastructure does. The protocol also inverts the interaction pattern most APIs use. The NSA's security brief on MCP notes that the protocol often expects servers to query, and in some cases execute actions, for the clients that connect to them. For a brand token server, that inversion is the whole point: an agent can ask for the one token it needs, color.brand.primary or spacing.lg, rather than receiving a full dump of every value the brand has ever defined. MCP's primitives map directly onto that need. Tools expose callable functions, resources expose the underlying token data, and prompts carry reusable templates for the queries agents make most often.

The file structure and four core tools a design token MCP server needs

A production-ready design token server does not require an elaborate architecture. It needs a minimal but complete structure: an entry point, a typed token directory, and a small set of tools that cover the full retrieval-and-update cycle an agent actually needs. A single index.js file is the entry point, and it stands up the MCP server itself. Alongside it sits a tokens/ directory holding colors.json, spacing.json, and typography.json, each written in DTCG 2025.10 format so the values inside stay portable across every downstream tool that reads that spec. Configuration, API keys, and references to the source repository live in a .env file, kept separate from the token data itself. On top of that structure, four tools cover what an agent needs to do with the tokens. get_token retrieves a specific value by name, the most basic and most frequently called operation. list_tokens enumerates everything the brand defines, giving an agent a way to discover what's available before it asks for anything specific. search_tokens finds values by pattern, useful when an agent needs every spacing token at once or every color token with "primary" somewhere in its name. update_token modifies a value directly, which turns the server from a read-only reference into a genuine write target for brand updates. The open-source design-token-bridge-mcp project (kenneives/design-token-bridge-mcp on GitHub) shows what this structure makes possible once it's in place: it translates tokens extracted from Tailwind, CSS, Figma, or W3C DTCG format into native themes for Material 3 in Kotlin, for SwiftUI, for Tailwind, and for CSS Variables, so the same server output reaches every target platform without a separate pipeline for each one.

Extending the server: compiled brand contracts and the brand-runtime pattern

A server that only hands back hex values and spacing numbers covers a fraction of what a brand actually is, and a fraction of what an agent generating on-brand work actually needs. A complete brand-ready MCP server compiles tokens alongside voice rules, logo assets, and documented anti-patterns into a single, fast-access structure, so any agent can query it without reassembling context from five different files. That structure typically includes a brand-runtime.json, a single-document brand contract that merges all of a session's relevant context into one flat, fast-access format, paired with an interaction-policy.json holding visual anti-patterns, voice constraints such as never-say lists and known AI-ism patterns, and content claims policies. This upgrade turns a token server into brand infrastructure. Figma's official MCP server, released June 4, 2025, extends this same pattern to live design data, with tools including get_design_context, get_screenshot, get_variable_defs, get_metadata, and get_code_connect_map, alongside a prompt called create_design_system_rules. So an agent querying that server gets the design intent behind a value, not just the value itself. The discipline that keeps this pattern durable over time is version control: brand context belongs under the same versioning rigor as code, so a token file gets updated, the change gets committed, and every downstream agent inherits the new version the next time it queries the server. Bloom's Brand Skill follows this same architecture at the infrastructure level: it ingests existing brand assets and exposes them as structured, retrievable context through API or MCP, so any connected agent or product can pull the current brand contract without prompt stuffing or manual re-entry of the same guidelines.

The agent workflow that a token server enables: fetch, transform, inject, validate

A token-serving MCP server has its real value in the workflow it makes possible, not in the storage layer. That workflow runs in four steps. First, an agent fetches current values by calling get_token or list_tokens on the server. Second, a language model transforms those typed values into generation-specific instructions, turning something like color.brand.primary #E8500A into an instruction such as "use a warm burnt-orange for all hero CTAs." Third, those instructions get injected into the creative prompt, whether the output is an image, a line of copy, or a piece of code. Fourth, you validate the output against the same token source, so deviations get flagged before they reach production, not after. For image generation specifically, the language model functions as a translator sitting between the token file, which holds machine-typed values, and the image model, which only understands natural language. The token file stays the source of truth throughout, and the language model converts it into usable instructions without losing precision along the way. New York State's MCP deployment, documented by Jesse Gardner, shows this workflow running at production speed: a five-page foster-adoptive parent PDF fed into Claude Code generated a working multi-step, state-styled form in a matter of minutes, with components and tokens documented through JSDoc and exposed via a custom MCP server. The deployment shows that the fetch-transform-inject-validate pattern holds up outside a controlled demo, and because an earlier decision had built on DTCG 2025.10 rather than a proprietary token format, the token data could travel cleanly into that custom server from the start.

Single update, universal propagation: why this architecture beats prompt stuffing at scale

The structural advantage of this entire architecture comes down to one fact: a single update to the token file propagates to every connected agent automatically, with no re-prompting, no version drift, and no manual synchronization across tools. Set that against what most organizations do today, where each team member pastes brand guidelines into a prompt by hand. That habit creates as many siloed copies of brand context as there are people doing the pasting, and every one of those copies risks going stale the moment the brand updates a color, a font, or a spacing rule. A token MCP server removes that risk by design: agents read from the file at runtime, so updating the token once, a new palette, a font change, a revised spacing system, means every workflow querying the server inherits the change on its very next request. The advantage compounds in a multi-brand environment. You can override a core system of primitive tokens intelligently for individual sub-brands or platforms, so you keep a shared global identity while letting product teams adapt within defined limits, and if you update a shared primitive once, it still propagates correctly to every sub-brand referencing it. Figma's MCP server shows this governance pattern in action: asked to update every primary call-to-action button across multiple brands to a 16px corner radius, the model reads tokens and component metadata through MCP, applies the update across brands, and runs regression checks to flag anomalies. The token server functions as the governance layer in that exchange, not merely the place where the data happens to live.

Security and token hygiene: what the MCP security guidance means for brand infrastructure

Running a token MCP server in production carries the same security obligations as any API exposing sensitive business data, and brand tokens are business data: pricing language constraints, unreleased color systems, voice rules tied to legal review. The NSA's published guidance on MCP makes a point that builders of brand infrastructure need to take seriously. The protocol's current specification places the burden of secure implementation on whoever builds the server, not on the protocol itself. MCP gives a server the ability to query and, in some configurations, execute actions on behalf of connected clients, and that inversion of the usual client-server relationship is precisely what makes brand tokens easy to serve on demand. Access control, authentication, and scoping decisions need tighter enforcement than they would on a conventional read-only API. A token server with an update_token tool is a write target, so when it updates brand color systems or voice constraints, it needs the same credential hygiene, the same scoped permissions, and the same audit discipline as any system of record a company depends on. None of that discipline is exotic. It is the ordinary security practice already applied to internal APIs, extended to a new protocol that happens to make brand data easier for agents to reach than it has ever been before.