Ignite UI Theming MCP

Generate Sass or CSS code to customize an Ignite UI component's appearance using design tokens.

<use_case> Use this tool AFTER calling get_component_design_tokens to customize specific component styles. The generated code can be included in your theme file to override default component appearances. </use_case>

<workflow>

1. First call get_component_design_tokens to discover available tokens
2. Choose which tokens to customize based on your design requirements
3. Specify designSystem and variant to match the global theme or the one explicitly requested (defaults to Material light)
4. Call this tool with component name, token values, and output format ("sass" or "css")
5. Receive ready-to-use Sass or CSS code with the component theme

</workflow>

<important_notes> DESIGN SYSTEM & VARIANT:

• designSystem: Choose "material" (default), "bootstrap", "fluent", or "indigo"
• variant: Choose "light" (default) or "dark"
• The correct schema (e.g., $light-bootstrap-schema, $dark-material-schema) is automatically selected and passed to the component theme function
• The correct output: Choose output format based on the target file type (Sass vs CSS)
• This ensures component tokens inherit proper defaults from the design system

TOKEN VALIDATION:

• All provided token names are validated against the component's schema
• Invalid tokens return an error with the list of valid token names
• You don't need to specify all tokens - only those you want to customize (prefer PRIMARY tokens to minimize the number of overrides)

TOKEN VALUE FORMATS:

• Colors: Any valid CSS color format (hex, rgb, hsl, named colors)
• Dimensions: Include units (e.g., "8px", "0.5rem", "2em")
• Border radius: Can be single value or shorthand ("8px" or "8px 8px 0 0")
• Shadows: Full box-shadow syntax ("0 2px 4px rgba(0,0,0,0.1)")

SELECTORS:

• Default selector is auto-detected based on platform and component
• For child sub-components (e.g., "list-item", "card-header"), the selector automatically resolves to the parent component's selector (e.g., "igx-list", "igx-card")
• Angular: Uses "igx-*" element selectors or attribute selectors
• Web Components: Uses "igc-*" element selectors
• Custom selectors supported for targeted styling (e.g., ".my-button")

CHILD SUB-COMPONENTS:

• When creating a theme for a child sub-component (e.g., "card-actions"), the output uses the parent's theme function, variable name, and selector.
• This means the output for "card" and "card-actions" is merge-compatible: both produce $custom-card-theme: card-theme(...) scoped to igx-card.
• To add tokens for multiple sub-parts, merge the token arguments into a single theme function call rather than creating separate themes.

SASS OUTPUT:

• Generated code uses @include tokens($theme) to apply the theme
• The tokens mixin emits --ig-{component}-{token} CSS custom properties in global mode

COMPOUND COMPLETENESS:

• Standard compounds: If the user asks for a standard compound component, the response is incomplete unless related theme calls are also generated. Use the related themes list from get_component_design_tokens to drive the sequence. All related themes should use the compound component's selector as the wrapper. Follow token derivation hints to set child token values consistently.
• Composed compounds: If the component is a composed compound (e.g., grid), do NOT generate separate child themes. Only set the primary tokens (background, foreground, accent-color) on the parent component's theme — child themes are auto-derived internally by the component's Sass styles. Refinement tokens (e.g., header-background) can be added in follow-up calls when the user explicitly asks to customize a specific aspect.

SASS FILE PLACEMENT:

• When combining Sass output from multiple tools into one file, all @use rules must appear at the top before any other statements. Deduplicate @use lines that share the same module path.

</important_notes>

<output> Returns:

• Generated Sass or CSS code with:
• Platform-specific @use import (Sass only)
• Theme function call with $schema parameter and provided token values (Sass only)
• tokens mixin to apply the theme to the selector (Sass only)
• Description of what was generated
• Design system and variant used
• List of tokens used

</output>

<error_handling>

• Unknown component: Returns error with list of available components
• Invalid tokens: Returns error listing invalid tokens and valid alternatives
• Invalid color format: Returns error with format guidance

</error_handling>

<example> Custom blue flat button with rounded corners (Angular, Material Design): { "platform": "angular", "designSystem": "material", "variant": "light", "component": "flat-button", "tokens": { "foreground": "#1976d2", } }

Generates:

@use 'igniteui-angular/theming' as *;

$custom-flat-button-theme: flat-button-theme(
  $schema: $light-material-schema,
  $foreground: #1976d2,
);

.igx-button--flat {
  @include tokens($custom-flat-button-theme);
}

Bootstrap dark theme example: { "platform": "webcomponents", "designSystem": "bootstrap", "variant": "dark", "component": "avatar", "tokens": { "background": "#ff5722" } }

Generates:

@use 'igniteui-theming' as *;

$custom-avatar-theme: avatar-theme(
  $schema: $dark-bootstrap-schema,
  $background: #ff5722
);

igc-avatar {
  @include tokens($custom-avatar-theme);
}

</example>

<compound_example> Date Picker (compound) — all child themes use the parent component's selector. Follow token derivation hints from get_component_design_tokens:

1. get_component_design_tokens { "component": "date-picker" }
2. create_component_theme { "component": "date-picker", "platform": "angular", ... }
3. create_component_theme { "component": "calendar", "selector": "igx-date-picker", ... }
4. create_component_theme { "component": "flat-button", "selector": "igx-date-picker", ... }
5. create_component_theme { "component": "input-group", "selector": "igx-date-picker", ... }

Each child theme uses the parent's platform selector (e.g., igx-date-picker for Angular, igc-date-picker for Web Components / React / Blazor). The tokens mixin emits --ig-{component}-{token} variables that child components consume via var() fallback — no per-child selectors needed. </compound_example>

<related_tools>

• detect_platform: Run to auto-detect platform for correct imports
• get_component_design_tokens: MUST call first to discover valid tokens
• create_theme: Use for full theme (palette + typography + elevations)

</related_tools>

Generate a custom color palette with fine-grained control over individual shade values.

⚠️ CRITICAL RULES - READ BEFORE GENERATING SHADES:

1. MONOCHROMATIC: Each color (primary, secondary, etc.) must use ONE HUE only. All 14 shades are lighter/darker versions of the SAME color. Example: primary blue → all shades must be blue (#E3F2FD light → #0D47A1 dark). WRONG: mixing blue, green, purple in one color's shades.
2. NEVER INVERT: Chromatic colors always go 50=lightest → 900=darkest. This applies to BOTH light and dark themes. Only gray inverts for dark themes.

<use_case> Use this tool when:

• The standard palette() function produces suboptimal shade distribution
• You have brand guidelines specifying exact color values for each shade
• Base colors are too light (luminance > 0.45) or too dark (< 0.05)
• You have specific accessibility audit requirements with exact contrast color values (rare - auto-generated contrast is usually sufficient)
• You want to mix auto-generated and manually specified color groups

</use_case>

<output_formats>

• "sass" (default): Generates Sass code with palette map structure. Requires Sass compilation.
• "css": Generates CSS custom properties (variables) directly. Ready to use in any CSS file.

Use "css" output when:

• Working with vanilla CSS projects without Sass
• You want immediately usable CSS variables
• Building prototypes or quick demos
• Using CSS-in-JS or other non-Sass styling approaches

</output_formats>

<workflow>

1. For each color group, choose a mode:

• mode:"shades" → Auto-generate all shades from baseColor using shades() function
• mode:"explicit" → Manually specify every shade value

2. Validates all explicit shades for:

• Completeness: All required shades present
• Color format: Valid CSS color values
• Luminance progression: 50 lightest → 900 darkest (chromatic colors)
• Hue consistency: All shades within ±30° hue tolerance (monochromatic)

3. Generates Sass code with color() map structure
4. Returns any validation warnings

</workflow>

<important_notes> CRITICAL - SHADE PROGRESSION RULES:

• CHROMATIC colors (primary, secondary, surface, info, success, warn, error): Shade 50 = ALWAYS lightest, shade 900 = ALWAYS darkest. This is TRUE FOR BOTH light AND dark themes. NEVER invert chromatic colors.
• GRAY color ONLY: Inverts for dark themes (50=darkest, 900=lightest).
• DO NOT confuse these rules. Only gray inverts, never primary/secondary/etc.

⚠️ CRITICAL - MONOCHROMATIC REQUIREMENT: Each color group (primary, secondary, etc.) must contain shades of ONE COLOR ONLY. Shades are lighter/darker variations of the SAME hue - NOT different colors!

CORRECT example for primary blue: 50: "#E3F2FD" (very light blue) 500: "#2196F3" (medium blue) 900: "#0D47A1" (dark blue) → All shades are BLUE, just different lightness levels

WRONG example (DO NOT DO THIS): 50: "#E3F2FD" (light blue) 500: "#4CAF50" (green) ← WRONG! Different hue 900: "#9C27B0" (purple) ← WRONG! Different hue → This creates a rainbow, not a shade palette

Rule: Keep hue constant (±30° tolerance), vary only lightness and saturation.

CHROMATIC COLORS (primary, secondary, surface, info, success, warn, error):

• Explicit mode requires 14 shades required: 50, 100, 200, 300, 400, 500, 600, 700, 800, 900, A100, A200, A400, A700
• Shade 50 = lightest, shade 900 = darkest (SAME for light AND dark themes)
• ALL shades must be the SAME HUE (monochromatic) - see requirement above
• A100-A700 are accent shades (same hue, typically more saturated)

GRAY COLOR (the ONLY color that inverts):

• Explicit mode requires 10 shades required: 50, 100, 200, 300, 400, 500, 600, 700, 800, 900
• LIGHT themes: 50 = lightest (near white), 900 = darkest (near black)
• DARK themes: 50 = darkest, 900 = lightest (INVERTED progression)
• Gray inverts because text/UI elements need to contrast against the surface

CONTRAST COLORS (AUTO-GENERATED - DO NOT PROVIDE):

• DO NOT include contrastOverrides in your input - OMIT THIS FIELD ENTIRELY
• The system AUTOMATICALLY generates contrast colors using adaptive-contrast()
• For each shade, the generated Sass output will include: '500': #4CAF50, '500-contrast': adaptive-contrast(#4CAF50), ← AUTO-GENERATED '500-raw': #4CAF50,
• The adaptive-contrast() function auto-selects black or white for readability
• Only provide contrastOverrides if you have a specific accessibility audit requiring exact contrast color values (this is extremely rare)

MIXING MODES:

• You can use "shades" mode for some colors and "explicit" for others
• Example: explicit primary, shades-based secondary and surface

SASS FILE PLACEMENT:

• When combining Sass output from multiple tools into one file, all @use rules must appear at the top before any other statements. Deduplicate @use lines that share the same module path.

</important_notes>

<output> Returns:

• Generated Sass code with color() map definitions, OR
• Generated CSS with custom properties (:root { --ig-primary-50: ...; })
• Summary of which colors use shades() vs explicit values
• Variable name created (e.g., $custom-light-palette) (Sass only)
• Validation warnings (if any)

</output>

<error_handling> Validation FAILS (returns error, no code generated) if:

• Missing required shades in explicit mode
• Invalid CSS color format in any shade

Validation WARNS (generates code with warnings) if:

• Luminance progression incorrect (50 darker than 900)
• Hue inconsistency detected (shades not monochromatic)
• Gray progression doesn't match variant (light vs dark)

</error_handling>

<example> Brand green with exact shades (NOTE: ALL shades are GREEN - same hue, different lightness):

INPUT (what you provide - NO contrastOverrides needed): { "variant": "light", "primary": { "mode": "explicit", "shades": { "50": "#E8F5E9", "100": "#C8E6C9", "200": "#A5D6A7", "300": "#81C784", "400": "#66BB6A", "500": "#4CAF50", "600": "#43A047", "700": "#388E3C", "800": "#2E7D32", "900": "#1B5E20", "A100": "#B9F6CA", "A200": "#69F0AE", "A400": "#00E676", "A700": "#00C853" } // ↑ Only provide shades - contrast colors are AUTO-GENERATED }, "secondary": { "mode": "shades", "baseColor": "#FF9800" }, "surface": { "mode": "shades", "baseColor": "#FAFAFA" } }

GENERATED OUTPUT (contrast colors added automatically): 'primary': ( '500': #4CAF50, '500-contrast': adaptive-contrast(#4CAF50), // ← AUTO-GENERATED '500-raw': #4CAF50, // ← AUTO-GENERATED // ... same pattern for all 14 shades ) </example>

<related_tools>

• detect_platform: Run first to get correct platform value
• create_palette: Use for simpler cases with mid-range luminance colors
• create_theme: Does not support custom palettes; use this tool + manual theme assembly

</related_tools>

<anti_example> ❌ WRONG - DO NOT create shades like this (different hues = broken palette): { "primary": { "mode": "explicit", "shades": { "50": "#E3F2FD", // blue "100": "#DCEDC8", // green ← WRONG HUE "200": "#FFF9C4", // yellow ← WRONG HUE "500": "#9C27B0", // purple ← WRONG HUE "900": "#BF360C" // red-brown ← WRONG HUE } } } This creates a rainbow, not a shade palette. Components will look broken. </anti_example>

<related_resources> Call read_resource to load reference data:

• "theming://presets/palettes" — preset palette colors for reference
• "theming://guidance/colors/usage" — which shades to use for different purposes
• "theming://guidance/colors/roles" — semantic meaning of each color family

</related_resources>

Set up elevation shadows for Ignite UI themes.

<use_case> Use this tool to configure box-shadow values that provide visual depth and hierarchy. Elevations follow Material Design or Indigo design specifications. </use_case>

<workflow>

1. Selects elevation preset based on design system parameter
2. Generates Sass code using the elevations() mixin
3. Creates 24 elevation levels (0-24) with corresponding shadow values

</workflow>

<important_notes>

• "material" preset: Material Design 3 shadow specifications
• "indigo" preset: Infragistics Indigo shadow specifications
• Elevation 0 = no shadow, elevation 24 = maximum shadow depth
• Components use elevation() function to apply specific levels

SASS FILE PLACEMENT:

• When combining Sass output from multiple tools into one file, all @use rules must appear at the top before any other statements. Deduplicate @use lines that share the same module path.

</important_notes>

<output> Returns:

• Generated Sass code with elevations() mixin call
• Platform-specific module imports
• Variable name used (e.g., $my-elevations)

</output>

<related_tools>

• detect_platform: Run first to get correct platform value
• create_theme: Use instead if you want elevations + palette + typography together

</related_tools>

<related_resources> Call read_resource to load reference data:

• "theming://presets/elevations" — elevation presets for Material and Indigo

</related_resources>

Generate a color palette for Ignite UI themes using the palette() Sass function.

<use_case> Use this tool when you have base colors and want to auto-generate a complete palette with all shade variations (50-900, A100-A700). Best for colors with mid-range luminance that will produce good automatic shade distribution. </use_case>

<output_formats>

• "sass" (default): Generates Sass code using the palette() function. Requires Sass compilation.
• "css": Generates CSS custom properties (variables) directly. Ready to use in any CSS file.

Use "css" output when:

• Working with vanilla CSS projects without Sass
• You want immediately usable CSS variables
• Using CSS-in-JS or other non-Sass styling approaches

</output_formats>

<workflow>

1. Validates input colors against the theme variant
2. Analyzes color luminance for shade generation suitability
3. Generates Sass code OR compiles to CSS based on output parameter
4. Adds warning comments to code if issues detected
5. Returns validation warnings and tips in response

</workflow>

<important_notes>

• Requires primary, secondary, and surface colors (matches Sass palette() API)
• Gray, info, success, warn, error are optional (use design system defaults)
• Surface color should match variant: light colors for "light", dark for "dark"
• Colors with extreme luminance (< 0.05 or > 0.45) may produce suboptimal automatic shade generation.

SHADE PROGRESSION (important):

• Primary, secondary, and all chromatic colors: shades are NEVER inverted. The palette() function always generates 50=lightest to 900=darkest.
• Only gray shades behave differently based on variant (for text contrast).
• DO NOT manually invert primary/secondary colors for dark themes.

SASS FILE PLACEMENT:

• When combining Sass output from multiple tools into one file, all @use rules must appear at the top before any other statements. Deduplicate @use lines that share the same module path.

</important_notes>

<output> Returns:

• Generated Sass code with palette() function call, OR
• Generated CSS with custom properties (:root { --ig-primary-50: ...; })
• Platform-specific module imports (Sass only)
• Validation warnings (if any colors have issues)
• Variable name created (e.g., $my-palette) (Sass only)

</output>

<error_handling>

• Invalid color format: Returns error with format examples
• Variant mismatch: Warns if surface color doesn't match theme variant
• Luminance issues: Warns with recommendation to use create_custom_palette

</error_handling>

<example> Blue brand with orange accent on light theme (Sass output): { "primary": "#1976D2", "secondary": "#FF9800", "surface": "#FAFAFA", "variant": "light" }

Same palette as CSS variables: { "primary": "#1976D2", "secondary": "#FF9800", "surface": "#FAFAFA", "variant": "light", "output": "css" } </example>

<related_tools>

• detect_platform: Run first to get correct platform value
• create_custom_palette: Use if this tool warns about luminance issues
• create_theme: Use instead if you want palette + typography + elevations together

</related_tools>

<related_resources> Call read_resource to load reference data:

• "theming://presets/palettes" — preset palette colors
• "theming://guidance/colors" — color guidance overview
• "theming://guidance/colors/rules" — light/dark theme color rules

</related_resources>

Generate a complete, production-ready Ignite UI theme with palette, typography, and elevations.

<use_case> Use this tool as the starting point for new projects. It generates everything needed for a working theme in a single operation: color palette, typography setup, elevation shadows, and the theme application mixin. </use_case>

<workflow>

1. Analyzes input colors for palette shade generation suitability
2. Creates color palette using palette() function
3. Sets up typography with specified font family (if includeTypography: true)
4. Configures elevations based on design system (if includeElevations: true)
5. Configures spacing utilities for Web Components, React, and Blazor (if includeSpacing: true)
6. Applies the theme using the theme() mixin
7. Returns luminance warnings if any colors may produce poor shades

</workflow>

<important_notes> REQUIRED COLORS:

• primaryColor: Main brand color
• secondaryColor: Accent/highlight color
• surfaceColor: Background color (should match variant)

SHADE PROGRESSION (important):

• Primary and secondary colors are NEVER inverted between light/dark themes.
• The palette() function generates shades 50=lightest to 900=darkest for ALL chromatic colors regardless of theme variant.
• Only gray shades behave differently (for text contrast against surface).
• DO NOT provide inverted primary/secondary colors for dark themes.

LUMINANCE ANALYSIS:

• Colors with extreme luminance (< 0.05 or > 0.45) may produce suboptimal automatic shade generation.
• If warnings appear, consider using create_custom_palette for those colors

PLATFORM DIFFERENCES:

• Angular: Uses igniteui-angular/theming with core() and theme() mixins
• Web Components: Uses igniteui-theming directly with palette(), typography(), elevations() mixins
• React: Uses igniteui-theming directly (same as Web Components), common with Vite/Next.js
• Blazor: Uses igniteui-theming for Sass compilation, theme CSS referenced in Blazor components

SASS FILE PLACEMENT:

• When combining Sass output from multiple tools into one file, all @use rules must appear at the top before any other statements. Deduplicate @use lines that share the same module path.

</important_notes>

<output> Returns:

• Complete Sass code with all theme components
• Luminance analysis warnings (if applicable)
• List of variables created/used
• Platform-specific guidance

</output>

<error_handling>

• Invalid color format: Returns error with format examples
• Luminance issues: Warns but still generates code (may produce suboptimal shades)
• Variant mismatch: Warns if surface color doesn't match theme variant

</error_handling>

<example> Complete Material Design blue theme: { "platform": "angular", "designSystem": "material", "primaryColor": "#1976D2", "secondaryColor": "#FF9800", "surfaceColor": "#FAFAFA", "variant": "light", "fontFamily": "'Roboto', sans-serif", "includeTypography": true, "includeElevations": true } </example>

<next_steps> After generating a theme:

1. Review any luminance warnings in the output
2. If warnings suggest shade generation issues:

• Use create_custom_palette for problematic colors
• Manually assemble theme with custom palette

3. Import the generated Sass file in your application's main styles
4. Customize individual component themes as needed using component schema overrides

</next_steps>

<related_tools>

• detect_platform: Run first to auto-detect platform from package.json
• create_custom_palette: Use for colors that produce luminance warnings
• create_palette: Use if you only need a palette without full theme
• create_typography: Use if you only need typography setup
• create_elevations: Use if you only need elevation shadows

</related_tools>

<related_resources> Call read_resource to load reference data:

• "theming://presets/palettes" — preset palette colors
• "theming://guidance/colors" — color guidance overview
• "theming://guidance/colors/rules" — light/dark theme color rules
• "theming://platforms/angular" — Angular platform configuration
• "theming://platforms/webcomponents" — Web Components platform configuration
• "theming://platforms/react" — React platform configuration
• "theming://platforms/blazor" — Blazor platform configuration </related_resources>

Set up typography for Ignite UI themes with custom font families and type scales.

<use_case> Use this tool to configure fonts that match your brand identity while maintaining consistent sizing, line heights, and letter spacing based on design system conventions. </use_case>

<workflow>

1. Takes font family string and optional design system preset
2. Generates Sass code using the typography() mixin
3. Applies the type scale from the selected design system
4. Optionally applies custom scale overrides

</workflow>

<important_notes>

• Font family string should include fallbacks for cross-platform compatibility
• Quote font names that contain spaces: '"Segoe UI"' not 'Segoe UI'
• Design system affects: font sizes, line heights, letter spacing, font weights
• Type styles include: h1-h6, subtitle-1/2, body-1/2, button, caption, overline

SASS FILE PLACEMENT:

• When combining Sass output from multiple tools into one file, all @use rules must appear at the top before any other statements. Deduplicate @use lines that share the same module path.

</important_notes>

<output> Returns:

• Generated Sass code with typography() mixin call
• Platform-specific module imports
• Variable name used (e.g., $my-typography)

</output>

<error_handling>

• Empty font family: Returns error requesting valid font family string

</error_handling>

<example> Modern sans-serif typography for Material Design: { "fontFamily": "'Inter', 'Segoe UI', 'Helvetica Neue', sans-serif", "designSystem": "material" } </example>

<related_tools>

• detect_platform: Run first to get correct platform value
• create_theme: Use instead if you want typography + palette + elevations together

</related_tools>

<related_resources> Call read_resource to load reference data:

• "theming://presets/typography" — typography presets for all design systems

</related_resources>

Detect the target platform by analyzing dependencies and project config files.

<use_case> Use this tool FIRST before generating any theme code to ensure platform-optimized output. The detected platform determines the correct Sass module paths and syntax. Output format ("sass" vs "css") is a separate concern — see the output parameter on each generation tool. For non-Angular platforms, prefer "css" unless the project has a confirmed Sass pipeline; use your own file-reading tools or ask the user to confirm before choosing output: "sass". </use_case>

<detection_signals> Uses multi-signal detection with confidence scoring:

1. Ignite UI packages (HIGH - 100): igniteui-angular, igniteui-webcomponents, igniteui-react, IgniteUI.Blazor
2. Config files (MEDIUM-HIGH - 80): angular.json, vite.config.*, next.config.*, .csproj
3. Framework packages (LOW - 40): @angular/core, react, lit (fallback only)
4. Generic fallback: When no Ignite UI product is found, returns "generic" for standalone theming

</detection_signals>

<output> Returns:

• platform: "angular" | "webcomponents" | "react" | "blazor" | "generic" | null
• confidence: "high" | "medium" | "low" | "none"
• ambiguous: true if multiple Ignite UI platforms detected (requires user to specify explicitly)
• alternatives: Array of detected platforms when ambiguous
• signals: Array of detection signals found
• detectedPackage: The primary package that triggered detection
• platformInfo: Name, theming module path, and description

"generic" means no Ignite UI product framework was found. Most tools work in generic mode (palette, typography, elevations, theme generation, color references, layout tokens with scope). Component-specific tools (create_component_theme, get_component_design_tokens) are NOT available in generic mode. The response includes Sass load path guidance based on detected build tooling. null is reserved for error states (package.json read failure) or ambiguous multi-product detection. </output>

<ambiguous_handling> When multiple Ignite UI platforms are detected with significant confidence (≥60), returns:

• platform: null
• ambiguous: true
• alternatives: List of possible platforms with their signals
• Action: User must specify platform explicitly in subsequent tool calls

</ambiguous_handling>

<related_tools> After detection, use the platform value with:

• create_palette: Generate color palette
• create_theme: Generate complete theme
• create_typography: Set up typography
• create_elevations: Configure shadows

</related_tools>

<related_resources>

• "theming://guidance/platform-setup": Comprehensive setup guide covering detection workflow, Sass load path configuration, dependency handling, and the recommended theming sequence. Read this for detailed platform-specific setup instructions.

</related_resources>

Retrieve a palette color from Ignite UI Theming as a CSS variable reference.

<use_case> Use this tool when you need to reference a specific palette color in CSS or Sass code. Returns CSS variable references that work in both Sass and CSS contexts.

Common scenarios:

• Setting component backgrounds/foregrounds using theme colors
• Creating hover/focus states with opacity variations
• Ensuring text contrast against colored backgrounds

</use_case>

<workflow>

1. Specify the color family (primary, secondary, gray, etc.)
2. Optionally specify a shade variant (50-900, A100-A700)
3. Optionally request the contrast color for text readability
4. Optionally apply opacity for transparency effects

</workflow>

<output_examples> Basic color: { color: "primary" } → var(--ig-primary-500)

Specific shade: { color: "primary", variant: "600" } → var(--ig-primary-600)

Contrast color: { color: "primary", variant: "600", contrast: true } → var(--ig-primary-600-contrast)

With opacity: { color: "primary", opacity: 0.5 } → hsl(from var(--ig-primary-500) h s l / 0.5)

Contrast with opacity: { color: "primary", contrast: true, opacity: 0.7 } → hsl(from var(--ig-primary-500-contrast) h s l / 0.7) </output_examples>

<important_notes> CSS VARIABLE NAMING:

• Base colors: --ig-{color}-{variant} (e.g., --ig-primary-500)
• Contrast: --ig-{color}-{variant}-contrast (e.g., --ig-primary-500-contrast)

GRAY RESTRICTIONS:

• Gray only supports standard shades (50-900), not accent shades (A100-A700)

OPACITY HANDLING:

• Uses CSS relative color syntax: hsl(from <color> h s l / <opacity>)
• Works in modern browsers (CSS Color Level 4)
• For Sass projects, this syntax is passed through unchanged

</important_notes>

<related_tools>

• create_palette: Generate a complete palette with these colors
• create_component_theme: Use retrieved colors in component theming

</related_tools>

Discover available design tokens (themeable properties) for an Ignite UI component.

<use_case> ALWAYS call this tool FIRST before using create_component_theme. It returns the exact token names that can be customized for a component, preventing hallucination of invalid property names.

NOTE: This tool returns tokens for Ignite UI framework components. It is NOT useful when the detected platform is "generic" — component theming requires a specific Ignite UI product (angular, webcomponents, react, or blazor). </use_case>

<workflow>

1. Provide the component name (e.g., "button", "avatar", "grid")
2. Receive list of all available tokens with their types and descriptions
3. Use the token names in create_component_theme

</workflow>

<important_notes> COMPONENT NAMING:

• Basic components: Use simple names like "avatar", "badge", "card"
• Button variants: Use specific variant names like "flat-button", "contained-button", "outlined-button", "fab-button" (NOT just "button")
• Icon button variants: "flat-icon-button", "contained-icon-button", "outlined-icon-button"
• Child sub-components: Use names like "list-item", "card-header", "accordion-header", "tab-item", "step", "expansion-panel-header". These resolve to the parent component's theme automatically.

CHILD SUB-COMPONENTS:

• Some component parts (e.g., "list-item", "card-header", "accordion-header") don't have their own theme function — they are styled through the parent component's theme tokens.
• When you query a child sub-component, the response includes a note explaining the parent-child relationship and shows the parent theme's full token list.
• The token descriptions guide you to the relevant tokens (e.g., "item-background" for list items, "header-text-color" for card headers).
• When you then call create_component_theme with a child name, it automatically uses the parent's theme function, variable name, and selector — producing output that is merge-compatible with the parent component's theme.

COMPOUND COMPONENTS: There are two types of compound components:

Standard compounds (e.g., "combo", "select", "date-picker"):

• Use multiple internal components that each need their own theme
• The response lists related themes and, where available, token derivation hints showing how child token values relate to parent/sibling tokens (e.g., "foreground → adaptive-contrast of calendar.content-background")
• Follow derivation hints when setting child token values. If the user specifies an explicit value, use that instead of the derived value.
• All related themes should be scoped under the parent component's selector
• For each related theme: call get_component_design_tokens, then create_component_theme using the parent component's selector for the target platform

Composed compounds (e.g., "grid components"):

• The framework automatically generates internal themes for all child components from just the primary tokens
• Do NOT create separate themes for the related components — they are auto-derived in the component's Sass styles
• The response uses a two-tier token hierarchy:
• ✅ Primary Tokens — USE THESE: Use ONLY these tokens for the initial theme
• 📖 Refinement Tokens — REFERENCE ONLY: Auto-derived tokens available ONLY when the user explicitly requests fine-grained control (e.g., "change the header background")
• Only set the primary tokens in the parent component's theme; all children inherit automatically
• The response clearly marks these as "Composed Compound Component" and lists the internally themed children for reference (not for separate theming)

VARIANTS INFO:

• If you query a base component that has variants (e.g., "button"), the response lists available variants to help you choose the right one

</important_notes>

<output> Returns:

• component: The component name
• themeFunctionName: The Sass function to use (e.g., "button-theme")
• description: Information about the component theme
• tokens: Array of { name, type, description } for each available token
• variants: (if applicable) List of variant-specific theme names
• compoundInfo: (if applicable) Related themes with token derivation hints and guidance
• childNote: (if child sub-component) A note explaining the parent-child relationship

</output>

<error_handling>

• Unknown component: Returns list of similar component names as suggestions
• Partial match: If query partially matches multiple components, returns all matches

</error_handling>

<example> Get tokens for flat button: { "component": "flat-button" }

Returns tokens like: background, foreground, hover-background, border-radius, etc.

Get tokens for a child sub-component: { "component": "list-item" }

Returns the list theme's tokens with a note: "list-item is a child of the list component. Its styling is controlled through the list theme." </example>

<related_tools>

• create_component_theme: Use the discovered tokens to create a custom theme

</related_tools>

Read a theming resource by URI. Returns reference data such as platform configurations, color palette presets, typography presets, color guidance, and layout documentation.

<use_case> Use this tool to load reference data before or during theme generation. Other tools reference these resources in their related_resources sections — call this tool with the listed URI to retrieve the data.

Common scenarios:

• Load palette presets to see available colors before creating a palette
• Read color guidance to understand shade usage and semantic roles
• Check platform configuration for usage examples and supported features
• Read layout documentation for spacing, sizing, and roundness details

</use_case>

<workflow>

1. Identify the resource URI from the available_resources list or from a related_resources hint in another tool
2. Call this tool with the URI
3. Use the returned data to inform your next action

</workflow>

<output> Returns the resource content as text. Format depends on the resource:

• application/json resources return JSON data
• text/markdown resources return Markdown documentation

</output>

<error_handling> If the URI is not found, returns the list of all available resource URIs. </error_handling>

Set global or component-specific roundness by updating --ig-radius-factor.

<use_case> Use this tool for requests like:

• "Make the flat buttons more round"
• "Square off the cards"

</use_case>

<behavior>

• Sets --ig-radius-factor in the chosen scope (defaults to :root)
• 0 = minimum radius, 1 = maximum radius, values between interpolate
• When platform is "generic", do NOT use the "component" parameter (it resolves Ignite UI component selectors). Use "scope" with a custom CSS selector instead, or omit both for :root.

</behavior>

<sass_notes>

• border-radius() responds to --ig-radius-factor without extra mixins

</sass_notes>

<example> Round avatars more: { "component": "avatar", "radiusFactor": 0.9 }

Globally reduce roundness: { "radiusFactor": 0.8 } </example>

<related_resources> Call read_resource to load reference data:

• "theming://docs/spacing-and-sizing" — spacing and sizing overview
• "theming://docs/functions/border-radius" — border radius function

</related_resources>

Set global or component-specific sizing by updating --ig-size.

<use_case> Use this tool for requests like:

• "Make the calendar smaller"
• "The buttons feel too big"
• "Use the small size everywhere"

</use_case>

<behavior>

• Sets --ig-size in the chosen scope (defaults to :root)
• Accepts "small", "medium", "large" (mapped to 1, 2, 3) or numeric values
• When platform is "generic", do NOT use the "component" parameter (it resolves Ignite UI component selectors). Use "scope" with a custom CSS selector instead, or omit both for :root.

</behavior>

<sass_notes>

• Components map --ig-size to --component-size internally
• Styles using sizable() require @include sizable() in component styles

</sass_notes>

<example> Make flat buttons medium: { "component": "flat-button", "size": "medium" }

Make everything small globally: { "size": "small" } </example>

<related_resources> Call read_resource to load reference data:

• "theming://docs/spacing-and-sizing" — spacing and sizing overview
• "theming://docs/functions/sizable" — sizable value function
• "theming://docs/mixins/sizable" — sizable mixin

</related_resources>

Set global or component-specific spacing by updating --ig-spacing.

<use_case> Use this tool for requests like:

• "The button feels bloated"
• "Tighten the spacing on the form"
• "Double the padding on cards"

</use_case>

<behavior>

• Sets --ig-spacing in the chosen scope (defaults to :root)
• Optional overrides for --ig-spacing-inline and --ig-spacing-block
• 0 = no spacing, 1 = default, 2 = double (fractions allowed)
• spacing is required; inline/block are optional overrides
• When platform is "generic", do NOT use the "component" parameter (it resolves Ignite UI component selectors). Use "scope" with a custom CSS selector instead, or omit both for :root.

</behavior>

<sass_notes>

• pad(), pad-inline(), pad-block() require @include spacing() once

</sass_notes>

<example> Reduce calendar spacing: { "component": "calendar", "spacing": 0.75 }

Override inline spacing: { "scope": ".compact", "inline": 0.5, "block": 0.75 } </example>

<related_resources> Call read_resource to load reference data:

• "theming://docs/spacing-and-sizing" — spacing and sizing overview
• "theming://docs/functions/pad" — pad spacing function
• "theming://docs/mixins/spacing" — spacing mixin

</related_resources>