A Deterministic Design Token Architecture for AI-Generated Applications Built for Model Context Protocol (MCP) Agent Workflows
Better prompts do not fix broken theming architectures. A deterministic token system does.
Your AI Is Only as Good as the Tools It Has
MCP-enabled IDEs such as Cursor, VS Code, and Claude Desktop give AI agents a structured context. But context alone does not produce correct theming code. The moment an agent touches your design system, it enters a layer MCP does not control. That is where things break.
Left to their own devices, agents routinely:
Invent CSS variable names that do not exist in the design system
Hardcode hex values directly into components, bypassing token inheritance
Generate framework selectors wrong across Angular, Web Components, React, and Blazor
Change one colour and silently break 50+ components that depend on it
These are not prompting failures. They are knowledge failures, and better prompts will not fix them. What fixes them is giving the agent the right tools to call.
The Ignite UI Theming MCP server exposes exactly that: tools for generating palettes, typography, elevations, and component themes — validated against the actual design system, targeting the right platform, producing code that compiles on the first try.
The MCP-Aligned Pipeline
Ignite UI Theming v25 is designed as the execution endpoint of an MCP-driven pipeline.
When you ask your AI assistant to theme an Ignite UI application, the agent does not generate CSS or Sass from scratch. It calls the Ignite UI Theming MCP server, which knows your design system — the tokens, the platform, the design system presets — and returns code that is correct by construction.
You describe what you want
→ IDE (Cursor / VS Code / Claude Desktop) passes that to the MCP server
→ The MCP server generates validated Sass or CSS
→ You get production-ready output, not a best guess
Included in the igniteui-theming package, the MCP server provides callable tools that agents use instead of producing raw CSS. This approach ensures all AI-generated output stays within a validated, schema-enforced framework.
Supported platforms: Angular, React, Web Components, and Blazor. Supported design systems: Material, Bootstrap, Fluent, and Indigo.
Seeing It in Action: An Agent Theming an Application
Theming an Ignite UI application follows a structured two-phase workflow: establish the application theme first, then adjust individual components. An agent that skips phase one and targets components directly produces inconsistent results — component tokens reference palette CSS variables that do not exist yet.
The following demonstrates the complete workflow end to end, using GitHub Copilot, Claude Sonnet 4.5, and the Ignite UI Theming MCP server against a real Angular application.
Phase 1 — Create the Application Theme
“Create a new light, neon theme for my app.”
The agent calls detect_platform first to read package.json and determine which Ignite UI package and theming module the project uses. This is a required precondition — the generated Sass imports differ between the OSS package (igniteui-angular) and the licensed package (@infragistics/igniteui-angular).
AGENT → MCP
detect_platform()
MCP RESPONSE
Detected Platform: Ignite UI for Angular
Confidence: high
Detected Package: @infragistics/igniteui-angular
Package Type: Licensed (@infragistics)
When generating theme code, use platform: 'angular' and licensed: true
to ensure the correct Sass syntax is generated for this platform.
With the platform confirmed, the agent calls create_theme. The neon colors chosen — #00e5ff cyan primary, #ff00c8 magenta secondary — have high luminance values. The MCP server detects this and returns a structured warning: automatic shade generation will produce washed-out results for shades 600–900. The agent responds by switching to create_custom_palette with explicit shade values for the primary and secondary colors.
⚠ PALETTE SUITABILITY WARNINGS
primary (#00e5ff): luminance 0.63 — too light.
Darker shades (600–900) will appear washed out.
surface (#f8f8ff): luminance 0.94 — too light.
Darker shades (600–900) will appear washed out.
Recommendation: use create_custom_palette with explicit shade values
for these colors to maintain full shade range fidelity.
The MCP server validates input colors against luminance thresholds before generating code. When automatic shade generation would produce suboptimal results, the server returns a structured warning and recommends create_custom_palette. The agent acts on this signal rather than proceeding with a suboptimal palette.
The agent calls create_custom_palette with 14 explicit shades for both primary and secondary colors. Surface, gray, and semantic colors (info, success, warn, error) use automatic shade generation — their luminance values are within acceptable range.
The palette() call generates CSS custom properties (--ig-primary-400, --ig-secondary-500, etc.) into :root. All 50+ Ignite UI components now reference these variables. The agent provided three base colors. The design system derived every shade, contrast value, hover state, focus state, active state, and disabled state for every component automatically.
Phase 2 — Adjust an Individual Component
“Apply our brand light azure to the contained buttons.”
Light azure maps to the primary-400 shade (#26e0ff) established in the palette. The agent queries get_component_design_tokens before writing any code to confirm the token structure for the contained-button component.
Theme Function: contained-button-theme()
Primary Token: $background
Setting $background derives automatically:
$foreground, $hover-background, $hover-foreground,
$focus-background, $focus-visible-background,
$active-background, $icon-color,
$disabled-background, $disabled-foreground,
... and 19 more tokens.
Available tokens: 29 total.
The agent sets only $background. All 28 remaining tokens — every interactive state — derive from that single input. The agent references var(--ig-primary-400) rather than a hardcoded hex value, so the component stays coupled to the palette. If the palette changes, the button changes with it.
// Generated by Ignite UI Theming MCP Server
@use "@infragistics/igniteui-angular/theming" as *;
$custom-contained-button-theme: contained-button-theme(
$schema: $light-material-schema,
$background: var(--ig-primary-400)
);
.igx-button--contained {
@include tokens($custom-contained-button-theme);
}
The agent did not set $hover-background, $focus-background, $active-background, $foreground, or any of the 28 remaining tokens. The Ignite UI token system derives all of them from $background using built-in contrast and opacity rules. This is not a shortcut — it is the correct way to use the design system.
Compound Components: Where Other Systems Break
Some Ignite UI components — including igx-date-picker, igx-combo, igx-select, and igx-grid — are composed of multiple sub-components, each with its own token surface and DOM boundary. Styling only the root selector produces incomplete results. Sub-components such as the calendar overlay, input group, and action buttons each require independent theme calls with correct scoped selectors.
The following continues the session above. The contained buttons in the application now use brand light azure. The user wants the same colour applied to the flat buttons inside the date picker component.
“Apply our brand light azure to the buttons in the date picker component.”
Step 1 — Query the compound component checklist
The agent calls get_component_design_tokens with component: "date-picker". The MCP server returns a component-not-found response and lists available component names. The correct name is date-range-picker — the Ignite UI component that provides the date picker overlay behaviour in Angular.
Component "date-picker" not found.
Available components (partial list):
calendar, card, carousel, checkbox, chip, combo,
contained-button, date-range-picker, fab-button,
flat-button, grid, input-group, outlined-button ...
Total available: 64 components.
The agent corrects the component name and queries date-range-picker. The MCP server returns a compound checklist: the full set of sub-components and scoped selectors required for visual consistency across the date picker overlay.
date-range-picker is a compound component.
The calendar popup renders inside .igx-date-picker (overlay selector).
Related themes — Angular:
Theme Scope Selector
────────────────────────────────────────────────
flat-button overlay .igx-date-picker
input-group inline igx-date-range-picker
calendar overlay .igx-date-picker
Token derivation note:
flat-button $foreground should contrast with
calendar $content-background.
The compound checklist makes the DOM architecture explicit without requiring the agent to inspect the browser. The date picker’s calendar and action buttons render in a CDK overlay scoped to .igx-date-picker — a CSS class on the overlay panel, not the igx-date-range-picker element. An agent targeting the wrong selector produces no visible result.
Step 2 — Query flat-button tokens
The compound checklist identifies flat-button as the sub-component for the action buttons (Today, Cancel). The agent queries flat-button tokens to confirm which token is primary. The token structure differs from contained-button: for flat buttons, $foreground is the primary token — flat buttons have no opaque background by default.
Theme Function: flat-button-theme()
Primary Token: $foreground
Setting $foreground derives automatically:
$hover-background, $hover-foreground,
$focus-background, $focus-hover-background,
$focus-visible-background, $active-background,
$icon-color, $disabled-foreground,
... and 16 more tokens.
Available tokens: 25 total.
Step 3 — Generate the scoped flat-button theme
The agent calls create_component_theme with the scoped selector .igx-date-picker returned by the compound checklist. The $foreground token is set to var(--ig-primary-400) — the same palette reference used for the contained button. The agent does not hardcode a hex value.
// Generated by Ignite UI Theming MCP Server
// Custom flat-button theme — scoped to date picker overlay
@use "@infragistics/igniteui-angular/theming" as *;
$custom-flat-button-theme: flat-button-theme(
$schema: $light-material-schema,
$foreground: var(--ig-primary-400)
);
.igx-date-picker {
@include tokens($custom-flat-button-theme);
}
The selector .igx-date-picker targets the CDK overlay panel, not the igx-date-range-picker component element. This is why compound component lookup is required. The agent did not inspect the DOM, did not guess the selector, and did not risk applying the flat-button style globally. All hover, focus, and active states for the action buttons are derived automatically from var(--ig-primary-400).
Three tool calls. One palette variable. Zero hardcoded hex values in component themes. The brand light azure colour is consistent across the contained buttons in the application and the action buttons inside the date picker overlay — both resolved from --ig-primary-400, defined once in the palette.
What’s New in Ignite UI Theming v25: The Token Architecture That Makes This Possible
1. Unified Tokens Mixin — Zero-Search DX
Previously, agents and developers had to hunt for component-specific variable names. In v25, the tokens() mixin introduces a universal fallback chain. Set global tokens for a component once at the root of your stylesheet and they cascade automatically:
The fallback chain serves two goals: it preserves backward compatibility for existing tokens and supports consistent styling across all four platforms using the --ig global design token prefix. Agents can style components in Ignite UI for Angular, Ignite UI for React, Ignite UI for Web Components, and Ignite UI for Blazor using the same token names.
3. Global Overrides Flow into Scoped Mode
Global token overrides propagate automatically into scoped components:
Scoped instances inherit the value without redeclaration. Agents can make context-driven overrides at scale without desynchronizing the broader design system. CSS specificity alone controls which value wins:
v25 aligns Ignite UI token output with Tailwind’s variable conventions. Teams using Tailwind as their utility layer can integrate Ignite UI components without bridging token naming conflicts. Agents targeting both systems do not need to maintain separate token mappings.
MCP Server: Available Tools
The igniteui-theming MCP server exposes the following callable tools to AI agents:
Tool
What It Does
detect_platform
Auto-detects Angular / Web Components / React / Blazor by reading package.json or other platform-related files.
create_palette
Generates a full color palette with automatic shade calculation (50–900).
create_custom_palette
Explicit shade control for strict brand guidelines or high-luminance colors.
create_typography
Configures font family and type scale per design system.
create_elevations
Sets up shadow and elevation definitions.
create_theme
Generates a complete, production-ready theme in one call.
get_component_design_tokens
Discovers available tokens for any component.
create_component_theme
Generates Sass for a specific component using validated tokens.
set_size
Sets size scale globally or per component (small / medium / large).
set_spacing
Sets spacing scale with optional inline/block overrides.
set_roundness
Sets border-radius factor globally or per component.
read_resource
Returns reference documentation on theming concepts, color relationships, and design system schemas.
Open Source — Built for MCP Extensibility
The Ignite UI theming engine is fully open source. This matters for agent workflows because it means:
Token behaviour is auditable — agents and teams can inspect exactly what any call will produce
Custom MCP integrations are possible — extend or fork the server for your own design system
No black-box theming — what you see in the source is what gets emitted
MCP server documentation: github.com/IgniteUI/igniteui-theming
When to Choose Ignite UI Theming v25
Ignite UI Theming v25 is the correct choice when:
You are generating UI through MCP-enabled IDEs (Cursor, VS Code, Claude Desktop)
You manage large, multi-framework applications across Angular, React, Web Components, or Blazor
You require atomic, agent-safe overrides without visual regressions
You enforce strict enterprise design systems with auditable behaviour
You need cross-framework theming consistency without duplicated token logic
Ignite UI Theming Engine v25 is not just a styling upgrade. It is the theming foundation for the MCP generation era, where AI agents build production applications and correctness is non-negotiable.
Design System Control at Enterprise Scale
Build your enterprise portal on Infragistics Ignite UI Theming when consistency matters at scale. Manage 50+ components under a single design system and use Sass-driven theming to keep your entire UI aligned with your global brand. When AI agents generate your UI, the Ignite UI Theming MCP server ensures every component they produce is validated, framework-correct, and design-system-consistent from the first run.
Radoslav Mirchev
13min read
