Writing
White paperJuly 202628 min read

Machine-Readable Content

How the Model Context Protocol and token libraries converge

A technical survey of how governed, structured content is served to AI agents, and a reference architecture for a shared content-token library.

Prepared by Robert Ballard · Content systems and UX engineering Revision 2.0 · July 30, 2026

Abstract

Two standards efforts have matured on parallel tracks and are now colliding in a useful way. The Model Context Protocol (MCP), introduced by Anthropic in November 2024 and revised through its 2025-06-18 specification, defines how an AI application connects to external data and tools through a single, schema-described contract discovered at runtime [1][2]. Separately, the token library pattern, exemplified by the W3C Design Tokens Community Group format that reached its first stable version in October 2025, defines how design and content decisions are captured as structured, typed, referenceable JSON that is portable across tools [9][11].

This paper surveys both, in technical depth, for an engineering and platform audience, and then argues that they are two halves of one architecture. A token library is a governed body of structured content. MCP is the transport and discovery layer that lets an agent find and consume that content. The connective tissue between them is JSON Schema, which both use as their contract. The paper closes with a concrete reference shape for a content-token library built on that contract, and with the limits of the evidence behind it.

Scope note on rigor: every technical claim here is traced to a primary source, listed in the References. Three deliberate corrections are carried through the text. JSON Schema is a community-maintained standard published as expired individual IETF Internet-Drafts, not an IETF standards-track document [15]. The phrase content-as-code is used as this author's framing; it is not vendor or standards-body terminology [21][22]. And while grounding an agent in retrieved contextual data is shown to reduce hallucination [23], no clean, peer-reviewed head-to-head result was found proving that structured content beats bare strings for agent accuracy, so that stronger claim is not made here.

Contents

  • Abstract
    1. Scope and definitions
    1. The Model Context Protocol: a technical survey
    • 2.1 Problem statement and origin
    • 2.2 Architecture
    • 2.3 Server feature: Resources
    • 2.4 Server feature: Tools
    • 2.5 Server feature: Prompts, and client features
    • 2.6 The 2025-06-18 revision
    • 2.7 Security and trust model
    1. Token libraries: a technical survey
    • 3.1 Design tokens and the DTCG format
    • 3.2 Content tokens and structured content
    • 3.3 The common denominator
    1. Convergence: serving token libraries over MCP
    • 4.1 Why they fit
    • 4.2 Mapping a token library onto MCP primitives
    • 4.3 The contract and governance layers
    • 4.4 What MCP does not give you
    1. Bridging design, content, and code through UX engineering
    • 5.1 The discipline and the gap
    • 5.2 The token pipeline: one source, many artifacts
    • 5.3 Design-to-code contracts: the component as interface
    • 5.4 Contract-driven development: schema as source, code as output
    • 5.5 Native instantiation: how tokens and content land in a native app
    • 5.6 A three-layer bridge model for native delivery
    1. A reference shape for a content-token library
    • 6.1 The leverage point is the schema, not the pipe
    • 6.2 A concrete reference shape
    • 6.3 Failure modes worth designing against
    1. Limits of this paper
  • References

1. Scope and definitions

This paper uses a small set of terms precisely. They are defined once here and used consistently throughout.

  • Token. A single named, typed unit of content or design decision, expressed as data. A color value, a spacing value, a piece of user-facing copy, or a governed message are all candidates. A token has a name, a value, and metadata about its type and use.
  • Token library. A governed, versioned collection of tokens with a shared schema, references between tokens, and metadata for provenance and governance. Design-token libraries are the mature case; content-token libraries are the emerging case this paper is most interested in.
  • Design token. A token that captures a visual design decision, standardized by the W3C Design Tokens Community Group (DTCG) format [9][10].
  • Content token. A token that captures a user-facing content decision, that is, copy plus the rules, governance, and context that make it safe and correct to render. Not yet standardized by any body; treated here as a structural sibling of the design token.
  • MCP. The Model Context Protocol: an open client-server protocol over JSON-RPC 2.0 that lets an AI host application discover and use external context and capabilities through typed contracts [1][2].
  • Agent. An LLM-driven application that reasons over context and invokes tools to act. In MCP terms, the agent lives inside the host and reaches servers through clients.

The paper is organized as a survey (Sections 2 and 3), a synthesis (Section 4), an applied UX engineering bridge (Section 5), a reference architecture (Section 6), and a statement of limits (Section 7). The surveys are deliberately neutral and citation-dense; the applied argument is concentrated in Sections 5 and 6 so that the research and the recommendations stay in separate rooms.

2. The Model Context Protocol: a technical survey

2.1 Problem statement and origin

MCP was open-sourced by Anthropic on November 25, 2024, with a specification, SDKs for Python and TypeScript, and a set of reference servers [1]. Its stated purpose is to replace bespoke, per-source integrations with one protocol: "a universal, open standard for connecting AI systems with data sources, replacing fragmented integrations with a single protocol" [1]. The design problem it addresses is combinatorial. Without a shared protocol, connecting m applications to n data sources tends toward m × n custom connectors; with a shared protocol it collapses toward m + n. The specification explicitly takes inspiration from the Language Server Protocol, which standardized how editors talk to language tooling across an entire ecosystem [2].

2.2 Architecture

MCP is a client-server protocol built on JSON-RPC 2.0 messages over stateful connections with capability negotiation [2][8]. It defines three roles [2]:

  • Host. The LLM application that initiates and coordinates connections (for example, a desktop assistant or an IDE).
  • Client. A connector inside the host that maintains a one-to-one, stateful session with a single server.
  • Server. A service that exposes context and capabilities to clients.

Because sessions are stateful and negotiated, a client and server first agree on protocol version and on which capabilities each supports, and only then exchange feature messages. Servers expose three feature types to clients: Resources, Prompts, and Tools. Clients may in turn expose three features to servers: Sampling, Roots, and Elicitation [2]. This symmetry matters: MCP is not only a way to pull data into a model, it is a bidirectional channel in which a server can ask the host to sample the model, to reveal filesystem or URI boundaries, or to prompt the user for more input.

Transport is defined for two cases: standard input/output for local servers, and Streamable HTTP for remote servers. The authoritative contract for all of this is a TypeScript schema, schema.ts, from which the prose specification is derived [2].

2.3 Server feature: Resources

Resources are the read-only side of MCP: "a standardized way for servers to expose resources to clients... data that provides context to language models, such as files, database schemas, or application-specific information" [3]. Every resource is identified by a URI. Resources are application-driven: the host decides how they enter context, whether through an explicit picker, a search UI, or automatic inclusion by heuristic or model selection [3].

A server that supports resources declares the capability, optionally advertising two features: per-resource change subscriptions, and list-changed notifications.

{
  "capabilities": {
    "resources": { "subscribe": true, "listChanged": true }
  }
}

Figure 1. Resource capability declaration [3].

Discovery uses resources/list (paginated); retrieval uses resources/read. A resource definition carries uri, name, optional title, optional description, optional mimeType, and optional size. Contents are returned as either text or base64 binary [3].

{ "method": "resources/read", "params": { "uri": "file:///project/src/main.rs" } }
// →
{ "contents": [ { "uri": "file:///project/src/main.rs",
                  "mimeType": "text/x-rust",
                  "text": "fn main() { println!(\"Hello world!\"); }" } ] }

Figure 2. Reading a resource by URI [3].

Three capabilities of Resources become load-bearing later in this paper. First, resource templates: servers can expose parameterized resources through RFC 6570 URI templates, listed via resources/templates/list, with arguments auto-completable through the completion API [3][6]. Second, subscriptions and list-changed notifications: a client can subscribe to a URI and receive notifications/resources/updated when it changes, and the server can emit notifications/resources/list_changed when the catalog itself changes [3]. Third, annotations: resources, templates, and content blocks carry optional hints, audience ("user" and/or "assistant"), priority (0.0 to 1.0, where 1 is effectively required), and lastModified (ISO 8601), which let clients filter, prioritize, and order what enters the model's context [3].

{ "uri": "file:///project/README.md", "name": "README.md",
  "title": "Project Documentation", "mimeType": "text/markdown",
  "annotations": { "audience": ["user"], "priority": 0.8,
                   "lastModified": "2025-01-12T15:00:58Z" } }

Figure 3. A resource with audience, priority, and modification annotations [3].

2.4 Server feature: Tools

Tools are the executable side of MCP: functions a model can invoke to query databases, call APIs, or compute [4]. Where Resources are application-driven, Tools are model-controlled, the model discovers and decides to call them, though the specification is emphatic that there SHOULD always be a human in the loop able to deny an invocation [4].

A tool definition carries a name (programmatic identifier), optional title, a description, an inputSchema that is a JSON Schema for its parameters, an optional outputSchema that is a JSON Schema for its result, and optional behavioral annotations [4]. This is the first place JSON Schema appears in MCP, and it is central: the contract for both what a tool takes and what it returns is a JSON Schema document.

{ "name": "get_weather_data", "title": "Weather Data Retriever",
  "inputSchema": {
    "type": "object",
    "properties": { "location": { "type": "string" } },
    "required": ["location"] },
  "outputSchema": {
    "type": "object",
    "properties": {
      "temperature": { "type": "number" },
      "conditions": { "type": "string" },
      "humidity": { "type": "number" } },
    "required": ["temperature", "conditions", "humidity"] } }

Figure 4. A tool declaring both input and output JSON Schemas [4].

Results may be unstructured or structured. Unstructured content is returned in a content array of typed blocks, text, image, audio, resource links, or embedded resources. Structured content is returned as a JSON object in a structuredContent field. When a tool declares an output schema, servers MUST return structured results that conform to it and clients SHOULD validate against it [4]. The specification lists the benefits plainly: strict validation of responses, type information for integration, and clearer guidance for clients and LLMs on how to parse the result [4].

Two result block types matter for later. A resource link lets a tool return a URI pointing back to a Resource rather than inlining the data, so a tool call can hand the agent a canonical, subscribable reference [4]. An embedded resource lets a tool inline a full resource, with the same annotations Resources use, when it is more useful to deliver the content directly [4]. Both share the annotation vocabulary from Section 2.3, so audience and priority hints travel with tool output as well.

2.5 Server feature: Prompts, and client features

Prompts are the third server feature: reusable, templated messages and workflows surfaced to users [2]. On the client side, MCP defines three features a host may offer back to a server: Sampling, which lets a server request a model completion (with the protocol intentionally limiting server visibility into the prompt); Roots, which lets a server ask about the URI or filesystem boundaries it may operate within; and Elicitation, which lets a server request additional information from the user mid-interaction [2]. Elicitation was added in the 2025-06-18 revision and is discussed next.

2.6 The 2025-06-18 revision

The 2025-06-18 specification made a set of changes that tighten MCP into a more production-grade protocol [5]. The ones relevant here:

  • Structured tool output. Tools can return typed, schema-validated JSON via structuredContent with an accompanying outputSchema (PR #371) [5]. This is the change that makes MCP a viable delivery layer for token data, not just prose.
  • Elicitation. Servers can request additional information from users during an interaction (PR #382) [5].
  • OAuth Resource Server classification. MCP servers are classified as OAuth Resource Servers, with protected-resource metadata so a client can discover the corresponding Authorization Server (PR #338) [5].
  • Resource Indicators (RFC 8707). Clients MUST implement resource indicators so a malicious server cannot obtain access tokens meant for another (PR #734) [5][7].
  • Resource links in tool results. Tools may return links to Resources (PR #603) [5].
  • Protocol version header. Over HTTP, the negotiated version MUST be sent in an MCP-Protocol-Version header on subsequent requests (PR #548) [5].
  • Removal of JSON-RPC batching, a title field for display names distinct from the programmatic name, and a _meta field on more types for out-of-band metadata [5].

2.7 Security and trust model

MCP is explicit that it enables "arbitrary data access and code execution paths" and cannot enforce security at the protocol level; it places the burden on implementors [2]. Its key principles are user consent and control, data privacy, tool safety, and sampling controls. Two points are worth carrying forward. First, tool annotations must be treated as untrusted unless they come from a trusted server, because a description is attacker-controllable text [2][4]. Second, the human-in-the-loop requirement is normative for tool invocation: clients SHOULD show tool inputs before calling, insert visual indicators, and present confirmation prompts [4]. Any token library exposed over MCP inherits this trust model. Governance cannot live only in the content; it must be enforced at the boundary.

3. Token libraries: a technical survey

3.1 Design tokens and the DTCG format

The Design Tokens Community Group (DTCG) at the W3C standardizes "a file format to exchange design tokens between different tools", with the explicit goal of interoperability across design and build tooling [9][10]. The specification reached its first stable version, 2025.10, on October 28, 2025, with reference implementations in Style Dictionary, Tokens Studio, and Terrazzo [11][12]. The format is plain JSON, which is what makes it relevant to an agent-consumption discussion: it is already machine-readable and already schema-describable.

Anatomy of a token. An object with a $value property is a token; $value is a reserved word and the parent object's key is the token name [10]. $value is the only required property. Optional reserved properties are $type, $description, $extensions, and $deprecated [10].

{
  "button-background": {
    "$type": "color",
    "$description": "Background color for buttons in their normal state.",
    "$value": { "colorSpace": "srgb", "components": [0, 0, 0] },
    "$extensions": { "com.example.governance": { "locked": true } },
    "$deprecated": false
  }
}

Figure 5. A DTCG color token with type, description, vendor extension, and deprecation flag [10].

The $type property is resolved by a defined precedence: if the value is a reference, the type is that of the referenced token; otherwise it is inherited from the nearest parent group that sets $type; otherwise the token is invalid [10]. $extensions is a namespaced escape hatch: tools MAY attach proprietary data under a vendor-specific key [10]. $deprecated may be a boolean or a string carrying the reason and even a reference to the replacement token [10]. These three, typed values, a namespaced extension slot, and first-class deprecation, are exactly the governance primitives a content token needs.

The type system, including composite tokens. DTCG defines base types (including color, dimension, fontFamily, fontWeight, duration, number, and cubicBezier) and a set of composite types. A composite token has a value "made up of multiple, named child values" and is used for closely related properties that are always applied together, such as a shadow, a gradient, or a full typography style [10]. Composite types in the specification include strokeStyle, border, transition, shadow, gradient, and typography [10].

{
  "elevation-low": {
    "$type": "shadow",
    "$value": {
      "color": { "colorSpace": "srgb", "components": [0,0,0], "alpha": 0.2 },
      "offsetX": { "value": 0, "unit": "px" },
      "offsetY": { "value": 2, "unit": "px" },
      "blur": { "value": 4, "unit": "px" },
      "spread": { "value": 0, "unit": "px" }
    }
  }
}

Figure 6. A composite shadow token: one name, multiple typed child values [10].

Aliases and references. A token's value can be a reference to another token, and the same value can therefore have multiple names, or aliases [10]. The recommended syntax is curly-brace dot-path, for example a text color that aliases a palette entry, with the specification also integrating JSON Pointer, chained-reference resolution, and explicit circular-reference prevention [10]. References can even operate at the property level, for instance referencing a color component or a typography sub-value [10]. This reference graph is the mechanism that turns a flat list of values into a library: semantic tokens point at primitive tokens, themes re-point aliases, and a change at the root propagates.

{
  "palette": { "black": { "$type": "color",
                          "$value": { "colorSpace": "srgb", "components": [0,0,0] } } },
  "text": { "primary": { "$type": "color", "$value": "{palette.black}" } }
}

Figure 7. text.primary is an alias of palette.black via curly-brace reference [10].

Finally, DTCG distinguishes groups from composite tokens: a group is any JSON object without a $value, used to organize child tokens and nested groups, and to carry inherited $type [10]. Groups give the library its namespace tree; composite tokens give individual entries internal structure.

3.2 Content tokens and structured content

There is no standards body for content tokens the way DTCG exists for design tokens. But the surrounding practice is well established, and it converges on the same shape: typed, structured, referenceable data with a schema. Four threads are worth surveying.

Structured content modeling. Headless content platforms model content as structured, typed, reusable units rather than presentation-bound documents. Contentful defines a content model composed of content types, each a set of typed fields that "correspond to a JSON type" [21]. Sanity defines content through a schema of typed document and field definitions with validation, and positions its store as a "structured foundation... to power every content experience," extending that framing explicitly to AI agents [22]. The through-line is content-as-data: the meaning and structure are captured independent of any single rendering, and the serialization is JSON.

Semantic vocabularies. Schema.org provides shared, extensible vocabularies that publishers embed as structured data so that "search engines and other applications" can understand what content means, not just how it displays [19]. Its motivating example is precisely the machine-readability gap: an HTML tag conveys presentation but not semantics, which makes content hard for machines to use correctly [19]. This is the same gap a content token closes for an agent.

Machine-readable content for LLMs. The llms.txt proposal (Jeremy Howard, Answer.AI, September 2024) standardizes a Markdown file at a site's root that gives LLMs "curated", concise content at inference time, motivated by the fact that "context windows are too small to handle most websites" and that converting noisy HTML into LLM-usable text is "difficult and imprecise" [20]. It is an early, explicit acknowledgment that agents need a purpose-built, machine-readable content surface distinct from the human-facing one.

Schema-constrained model output. The demand side is now standardized too. JSON Schema is "a declarative language for defining structure and constraints for JSON data" that "establishes a common language for data exchange... to create a shared understanding and increase interoperability across different systems" [13]. Both major model vendors use it to constrain output. OpenAI's Structured Outputs "ensures the model will always generate responses that adhere to your supplied JSON Schema" [16]. Anthropic's structured outputs "constrain Claude's responses to follow a specific schema" through constrained decoding, and its tool use passes an input_schema that is itself a JSON Schema [17][18]. The significance: the same schema that describes a token can constrain what a model emits about it, closing the loop between content and generation.

A rigor note on this thread. It is well established that grounding a model in retrieved contextual data reduces hallucination, Shuster et al. show retrieval augmentation "substantially reduce[s] the well-known problem of knowledge hallucination" [23]. It does not follow, and is not claimed here, that structured content strictly outperforms bare strings for agents; that specific head-to-head result was not found in a peer-reviewed source. The defensible claim is narrower: schemas make outputs validatable and grounding reduces hallucination, and a token library provides both a schema and grounded content.

3.3 The common denominator

Stripped to essentials, design tokens and content tokens are the same construct. Both are JSON. Both are typed. Both use references to build a library out of primitives. Both carry governance metadata: DTCG has $deprecated and a namespaced $extensions slot; content modeling has validations and versioned schemas. And both are describable by a JSON Schema, which is the exact contract MCP already speaks. That shared denominator is what makes the next section possible.

4. Convergence: serving token libraries over MCP

This section is the synthesis. It argues that a token library and MCP are complementary layers, maps a token library onto MCP's primitives concretely, and is careful to state what MCP does not provide so the token library's responsibilities are clear.

4.1 Why they fit

MCP's job is discovery, transport, and typed contracts for context an agent consumes at runtime. A token library's job is to be governed, structured content with a schema. MCP has no opinion about what the content is; a token library has no opinion about how an agent reaches it. They compose cleanly because they meet at JSON Schema: MCP tools already declare input and output schemas, DTCG tokens are already typed JSON, and content tokens can adopt the same discipline. Nothing has to be invented to connect them; the connection is a modeling decision.

4.2 Mapping a token library onto MCP primitives

Resources as the token catalog. The natural home for a token library is MCP Resources. Each token or collection gets a URI; resources/list is catalog discovery; resources/read is token resolution [3]. Because a token library is a reference graph, a custom URI scheme maps onto it well, for example token://billing/cancel-cta. Resource templates (RFC 6570) then express parameterized lookups, token://{surface}/{name} or token://{locale}/{surface}/{name}, with argument completion, so an agent can enumerate a theme or a locale without the server pre-expanding every combination [3][6].

resources/templates/list →
{ "resourceTemplates": [
    { "uriTemplate": "token://{locale}/{surface}/{name}",
      "name": "Content token",
      "title": "Governed content token",
      "description": "Resolve a content token for a surface and locale",
      "mimeType": "application/json" } ] }

Figure 8. A resource template exposing a parameterized content-token lookup [3][6].

Two Resource features earn their place here. Subscriptions and list-changed notifications mean an agent can hold a live reference to a token and be told when the copy or its governance changes, rather than caching a stale string [3]. And annotations let the library tell the model which tokens matter: audience separates content meant for the user from content meant for the assistant, priority ranks what belongs in a tight context window, and lastModified surfaces recency [3].

Tools for resolution and generation. Where a lookup needs logic, resolving an alias chain, selecting a variant by state, or generating copy within governed constraints, a Tool is the right primitive. The token's JSON Schema becomes the tool's outputSchema; the resolved token is returned in structuredContent and validated against it; and a resource_link can point back to the canonical Resource so the agent keeps a subscribable handle [4]. This is the payoff of the 2025-06-18 structured-output change: a token arrives as typed, validated data, not as a string the agent must parse and hope.

tools/call resolve_content_token { "name": "cancel-cta", "surface": "billing" }
→
{ "content": [ { "type": "text",
                 "text": "{\"text\":\"Cancel plan\",\"locked\":true}" } ],
  "structuredContent": {
    "id": "billing.cancel-cta",
    "text": "Cancel plan",
    "governance": { "locked": true, "review": "legal" } },
  "isError": false }

Figure 9. A resolver tool returning a governed content token as validated structured content [4].

Prompts and the trust boundary. Prompts can carry governed usage guidance, for example a templated instruction that tells an agent how to apply a family of tokens. But the more important point is the trust boundary from Section 2.7: because tool annotations and descriptions are untrusted, and because tool invocation is human-in-the-loop, a token library exposed over MCP cannot rely on the model to respect governance voluntarily. Governance that must hold, a locked legal string, a locale restriction, has to be enforced by the server and the schema, not merely described in metadata the client is told to distrust.

4.3 The contract and governance layers

JSON Schema is the contract that binds the two systems, describing a token's shape on the way in (tool inputSchema) and out (tool outputSchema, validated), and describing a resource's payload [4][13]. Governance metadata has two idiomatic homes. Within the token itself, DTCG's namespaced $extensions slot carries proprietary governance data such as lock state, review status, or locale rules [10]. At the protocol layer, MCP's _meta field carries out-of-band metadata on protocol objects [5]. Provenance and versioning are served by $deprecated (with replacement pointer) on the content side and the negotiated MCP-Protocol-Version on the transport side [5][10]. Access control is not improvised: MCP servers are OAuth Resource Servers, and clients must use RFC 8707 resource indicators, so a token library gets a real authorization story rather than an ad-hoc one [5][7].

4.4 What MCP does not give you

It is as important to state the seam as the fit. MCP is transport and contract; it is not a content system. Specifically:

  • No content model. MCP will carry any JSON, but it does not tell you how to model a token, what fields govern it, or how variants and locales relate. That is the token library's schema to define.
  • No governance semantics. MCP provides annotations that are explicitly untrusted and a consent model, but it has no concept of "legally locked copy" or "approved for market X." Those semantics live in the token schema and must be enforced server-side.
  • No versioning of content. MCP versions the protocol, not your content. Token versioning, deprecation, and change history are the library's responsibility (DTCG $deprecated is a start, not a system).
  • No interoperability guarantee. Two teams can both expose tokens over MCP and still be incompatible if their schemas differ. MCP standardizes the pipe, not the payload. Section 6.1 takes this up directly.

5. Bridging design, content, and code through UX engineering

The preceding sections established that MCP can serve a token library (Sections 2 and 4) and that design and content tokens share a structural shape (Section 3). A protocol and a schema, however, do not ship a screen. Between the token libraries and a running native surface sits an engineering discipline whose entire job is to keep design, content, and code in agreement: UX engineering, also called design engineering or design-systems engineering. This section surveys the modern practices that make that bridge work, from primary sources, and then applies them to the applied problem this paper is concerned with: how a design-tokenization system, a content-token library, and native engineering instantiation compose to ship a native app's experiences.

The problem is that these three worlds have three sources of truth and three cadences. Visual decisions live in the design-token system. Content decisions live in the content-token library. Behavior lives in native component code. Each is edited by a different team on a different clock. Left unbridged they drift, and the drift shows up as the same fragmentation Section 4.4 warned about, one layer down. UX engineering is the practice that owns the seams between them.

5.1 The discipline and the gap

A candid note on terminology, because this paper holds itself to primary sources. There is no standards-body definition of the "design engineer" or "UX engineer" role; the title is practitioner usage and its boundaries vary by company. What authoritative design-system documentation does agree on is the underlying idea: the token and component layer is a shared source of truth between design and engineering. Figma describes Code Connect as a way to "create a shared source of truth for both the design and code elements" [24]. GitHub's Primer exists to "provide common language to build cohesive, accessible, responsive experiences" [28]. Shopify's Polaris ships as one system with two representations, design resources and development resources, side by side [29]. The UX engineer, whatever the title, is the owner of that shared layer and the transforms that keep its representations in sync.

5.2 The token pipeline: one source, many artifacts

The mature pattern for design values is define once, generate per platform. Style Dictionary, the reference tool, is "a build-system... to parse and transform your design tokens to then export them to any platform: iOS, Android, CSS..." and is explicitly "a build tool rather than a runtime tool because it is used to generate files rather than used directly in an application" [27]. It merges token source files into a single token object and applies per-platform transforms before emitting outputs [27]. The design tool has moved the same way: Figma Variables "store reusable values" and are the mechanism to "implement design tokens for your design system," including light and dark modes [26], and Dev Mode "gives you everything you need to navigate design files and transform designs into code," letting a developer choose the output language [25].

The important property, for this paper, is that a token is a semantic reference resolved into concrete, platform-specific artifacts by a build step. That is the same interchange idea as the DTCG format in Section 3.1, now with a compiler attached. It is also the same move MCP makes with typed tool output in Section 2.4: a schema at the source, validated artifacts at the edge.

5.3 Design-to-code contracts: the component as interface

Tokens style a component; they do not define it. The contract for the component itself is increasingly captured by Figma Code Connect, which is "a bridge between your codebase and Figma's Dev Mode, connecting components in your repositories directly to components in your design files" [24]. Once connected, Dev Mode shows "true-to-production code snippets from your design system instead of autogenerated code" [24], and a single design component can map to many implementations across "React, SwiftUI, Jetpack Compose, Vue" [24]. The component API, its props and variants, becomes the typed interface between design intent and running code.

This matters to the rest of the paper for one reason: it runs over the same rails as the agent story. Figma states that Code Connect connections "enhance the Figma MCP server's ability to guide AI agents with... direct references to your actual code" [24]. The design-to-code bridge and the agent-to-content bridge are the same MCP surface. A component that is Code-Connected and a content token that is MCP-served are both, in the end, typed contracts that an engineer or an agent can read.

5.4 Contract-driven development: schema as source, code as output

The bridge only holds if it is generated, not hand-maintained. Mature engineering has a well-established pattern for this: describe the interface once, generate the artifacts. OpenAPI describes an HTTP API in a single document from which teams "generate client code and create test cases," keeping interface and implementation "closely-matched" through "a single version of the truth" [30]. A GraphQL schema is a type system whose types "completely describe the set of possible data" and against which every request "is validated and executed," independent of implementation language [31]. Protocol Buffers let you "define how you want your data to be structured once," after which a compiler "invoked at build time" generates source code so that "the same messages can be read by code written in any supported programming language" [32].

The lesson transfers directly. Treat the design-token schema and the content-token schema as contracts, and generate the platform bindings, the native theme, the string catalog, and the resolver from them. Section 4.3 already identified JSON Schema as the shared contract; contract-driven development is how that contract becomes shipping code without a human retyping it in three places.

5.5 Native instantiation: how tokens and content land in a native app

The native platforms already consume design tokens as semantic references. Apple defines "dynamic system colors" that are "semantically defined by... purpose, rather than... appearance or color values," and instructs developers to "avoid hard-coding system color values"; brand tokens live as Asset Catalog color sets that carry light, dark, and high-contrast variants and "load the color variant that matches the current environment" at draw time [33][34]. Dynamic Type exposes named text styles that "scale proportionately when people change the system's text size" [35]. On Android, Compose's MaterialTheme carries color, typography, and shape token sets, and components read them via MaterialTheme.colorScheme and MaterialTheme.typography, so that changing the tokens re-themes the components automatically [36].

Both platforms compile these resources into the app at build time and reference them by identifier. Android externalizes resources and accesses them "using resource IDs that are generated in your project's R class" via the aapt tool [37]; iOS String Catalogs are populated "each time you build your project" [38]. The practical consequence for a native app: by default, tokens and shipped copy bake into the binary and are referenced by ID, not fetched live. Any content that must change without an app release needs a separate runtime channel, which is exactly where MCP-served content tokens (Section 4) and over-the-air mechanisms enter. Which content is build-time and which is runtime is a product decision rather than a protocol one.

Crucially, native localization already treats content as structured, not as bare strings, which is the content-token thesis of Section 3 arriving from the platform side. ICU MessageFormat requires that a message be "written and translated as a single unit" with typed "plural" and "select" arguments, precisely because concatenating fragments would stop translators from being able to "rearrange the pieces" [39]. Apple's String Catalog encodes plural and device variants as structured data [38], and Android's <plurals> selects a grammatically correct sub-string by quantity keyword, "based on grammatical necessity" [40]. Accessibility rides on the same semantics: semantic colors deliver dark mode and contrast, Dynamic Type delivers text scaling, and Material's color roles are built to "meet accessibility standards for color contrast" [34][35][36].

5.6 A three-layer bridge model for native delivery

Putting the survey together, the design-to-content-to-native chain resolves into three layers, each with one contract, connected by transforms the UX engineering layer owns, meeting at the component.

  • Layer 1, design tokenization (the visual contract). DTCG-shaped design tokens [9][10], transformed by a Style-Dictionary-class pipeline [27] into a SwiftUI or Compose theme and asset-catalog or resource files. The native code references semantic tokens, never hard-coded values [33][36].
  • Layer 2, the content-token library (the content contract). JSON-Schema-described content tokens (Sections 3 and 4), governed for lock, locale, legal review, and state. Delivered two ways: baked into String Catalogs and quantity strings at build time for shipped copy [38][40], and served over MCP Resources and a resolver Tool for agent-time and dynamic use (Section 4). Content stays structured (ICU), never concatenated strings [39].
  • Layer 3, engineering instantiation (the code contract). Native SwiftUI or Compose components whose props are the typed API. Each component binds a design-token set for form and a content-token set for copy, and a Code Connect mapping ties the Figma component to this native component so design, code, and the MCP surface agree [24].

The unifying move is that all three are single-source contracts, generated into platform artifacts rather than hand-copied, following the contract-driven pattern of Section 5.4. The component is where they meet: it takes form from design tokens, copy from content tokens, and exposes behavior through a typed API, and Code Connect plus MCP make that meeting point legible to both engineers and agents.

6. A reference shape for a content-token library

The survey supports a specific architecture. This section states it plainly: what to define first, how to expose it, and which failure modes to design against.

6.1 The leverage point is the schema, not the pipe

The technical survey points to a single highest-leverage artifact: the token schema. Section 4.4 is the reason. MCP standardizes the pipe, not the payload, so two libraries can both be served correctly over MCP and still be unable to talk to each other. DTCG demonstrates the pattern to copy, a small set of reserved properties ($value, $type, $description), a namespaced extension slot for governance, first-class deprecation, and a reference graph, and it reached stability precisely because it standardized the payload, not the tooling [10][11]. A content-token schema should therefore be defined as the contract first, in JSON Schema, so that it can simultaneously serve as a Resource payload shape, a tool outputSchema, and a constraint for model generation [4][13][16][18]. Whoever owns that schema owns the interoperability of every library built against it.

6.2 A concrete reference shape

Synthesizing the survey, a minimal, defensible delivery architecture looks like this:

  • Define the token schema in JSON Schema. Model id, role, value (fixed / templated / generated), governance (lock, review, locale, state), and rules. Borrow DTCG's reserved-property discipline and its $extensions pattern for governance [10].
  • Expose the catalog as MCP Resources. A token:// URI scheme, resource templates for surface and locale, subscriptions so agents track changes, and audience / priority annotations to guide what enters context [3][6].
  • Expose resolution as a Tool. A resolver whose outputSchema is the token schema, returning validated structuredContent and a resource_link to the canonical token [4].
  • Enforce governance server-side. Treat annotations as untrusted; enforce locks, locale, and legal review in the server and schema, not in model-facing hints [2][4].
  • Use MCP's auth story as given. OAuth Resource Server plus RFC 8707 resource indicators, rather than a bespoke access scheme [5][7].

6.3 Failure modes worth designing against

  • Divergent schemas behind a common protocol. Token libraries with different shapes can each be served correctly over MCP and still fail to interoperate, which is the fragmentation a shared standard is meant to prevent. The countermeasure is a shared schema treated as a governance artifact rather than a per-team implementation detail.
  • Governance as a hint. Encoding a legal lock only in a description or annotation is unsafe by MCP's own trust model. Governance that must hold must be enforced at the boundary [2][4].
  • Feasibility mistaken for interoperability. A working end-to-end demonstration establishes that the architecture runs. It does not establish a contract others can build against, and the two are separate pieces of work.

7. Limits of this paper

Three honest limits. First, there is no standards body for content tokens; DTCG covers design tokens only, so a content-token schema of the kind described in Section 6 is a local invention that should borrow DTCG's structure but cannot claim its authority [9][10]. Second, the evidence base supports grounding and schema-validation, but not the stronger claim that structured content beats bare strings for agents; that study does not yet exist in a form worth citing [23]. Third, MCP is young and moving: the 2025-06-18 revision materially changed tool output and authorization within months, so any architecture built on it should expect the contract to keep tightening [5]. None of this argues against the direction. It argues for investing in the durable layer, the schema, rather than the fast-moving one.

References

[1] Anthropic. "Introducing the Model Context Protocol." November 25, 2024. https://www.anthropic.com/news/model-context-protocol

[2] Model Context Protocol Specification, revision 2025-06-18 (overview). https://modelcontextprotocol.io/specification/2025-06-18

[3] Model Context Protocol Specification, Server Features: Resources (2025-06-18). https://modelcontextprotocol.io/specification/2025-06-18/server/resources

[4] Model Context Protocol Specification, Server Features: Tools (2025-06-18). https://modelcontextprotocol.io/specification/2025-06-18/server/tools

[5] Model Context Protocol Specification, Key Changes (2025-06-18 changelog). https://modelcontextprotocol.io/specification/2025-06-18/changelog

[6] IETF RFC 6570, URI Template. https://datatracker.ietf.org/doc/html/rfc6570

[7] IETF RFC 8707, Resource Indicators for OAuth 2.0. https://www.rfc-editor.org/rfc/rfc8707.html

[8] JSON-RPC 2.0 Specification. https://www.jsonrpc.org/specification

[9] Design Tokens Community Group (W3C). https://www.designtokens.org/

[10] DTCG, Design Tokens Format Module (draft). https://www.designtokens.org/tr/drafts/format/

[11] W3C Design Tokens Community Group. "Design Tokens Specification reaches first stable version" (2025.10). October 28, 2025. https://www.w3.org/community/design-tokens/2025/10/28/design-tokens-specification-reaches-first-stable-version/

[12] Style Dictionary, Design Tokens Community Group support. https://styledictionary.com/info/dtcg/

[13] JSON Schema, What is JSON Schema. https://json-schema.org/overview/what-is-jsonschema

[14] JSON Schema, Specification. https://json-schema.org/specification

[15] IETF Datatracker, draft-bhutton-json-schema (status note). https://datatracker.ietf.org/doc/draft-bhutton-json-schema/

[16] OpenAI, Structured Outputs (developer documentation). https://platform.openai.com/docs/guides/structured-outputs

[17] Anthropic, Tool use overview. https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview

[18] Anthropic, Structured outputs. https://platform.claude.com/docs/en/build-with-claude/structured-outputs

[19] Schema.org, Getting started. https://schema.org/docs/gs.html

[20] llms.txt proposal (Jeremy Howard, Answer.AI). https://llmstxt.org/

[21] Contentful, Data model (developer documentation). https://www.contentful.com/developers/docs/concepts/data-model

[22] Sanity, Schema types (documentation). https://www.sanity.io/docs/studio/schema-types

[23] Shuster, Poff, Chen, Kiela, Weston. "Retrieval Augmentation Reduces Hallucination in Conversation." arXiv:2104.07567, 2021. https://arxiv.org/abs/2104.07567

[24] Figma, Code Connect documentation. https://developers.figma.com/docs/code-connect/

[25] Figma, Guide to Dev Mode. https://help.figma.com/hc/en-us/articles/15023124644247-Guide-to-Dev-Mode

[26] Figma, Guide to variables in Figma. https://help.figma.com/hc/en-us/articles/15339657135383-Guide-to-variables-in-Figma

[27] Style Dictionary, official documentation. https://styledictionary.com/

[28] GitHub Primer, Getting started. https://primer.style/product/getting-started/

[29] Shopify Polaris, Getting started. https://polaris-react.shopify.com/getting-started

[30] OpenAPI Initiative, What is OpenAPI. https://www.openapis.org/what-is-openapi

[31] GraphQL, Schemas and Types. https://graphql.org/learn/schema/

[32] Protocol Buffers, Overview. https://protobuf.dev/overview/

[33] Apple, Human Interface Guidelines: Color. https://developer.apple.com/design/human-interface-guidelines/color

[34] Apple, Supporting Dark Mode in Your Interface. https://developer.apple.com/documentation/uikit/supporting-dark-mode-in-your-interface

[35] Apple, Human Interface Guidelines: Typography. https://developer.apple.com/design/human-interface-guidelines/typography

[36] Android Developers, Material Design 3 in Compose. https://developer.android.com/develop/ui/compose/designsystems/material3

[37] Android Developers, Providing resources. https://developer.android.com/guide/topics/resources/providing-resources

[38] Apple, Localizing and varying text with a string catalog. https://developer.apple.com/documentation/xcode/localizing-and-varying-text-with-a-string-catalog

[39] Unicode ICU, Formatting Messages (MessageFormat). https://unicode-org.github.io/icu/userguide/format_parse/messages/

[40] Android Developers, String resources. https://developer.android.com/guide/topics/resources/string-resource

Want to talk through where this goes next? Get in touch.