Get the resolved design system context before building UI. Read-only, no side effects. Default (no category) returns a JSON summary of token counts, component names, conflict counts, comparison diagnostic counts, and contract metadata. Pass category: 'all' | 'tokens' | 'components' | 'conflicts' | 'diagnostics' to get detail. Pass tokenCategory to filter tokens: colors, spacing, sizes, typography, borderRadius, shadows, zIndex, breakpoints, motion (unknown/aliased categories return an actionable error, not a silent empty result). Use this as the first call to understand what exists. For lookups by name, use get_token or get_component instead.

Look up a specific design token by name. Read-only, no side effects. Returns the token's name, value, and category, or an error if not found. Pass category to narrow search: colors, spacing, sizes, typography, borderRadius, shadows, zIndex, breakpoints, motion (aliases like 'color'/'radius'/'z-index' are normalized). Omit category to search all. Use this when you know the token name. For a broad overview of all tokens, use get_design_context with category 'tokens' instead.

Look up a component by name or id. Read-only, no side effects. Pass context (your current working file or directory) so same-name components resolve by path scope. Returns the component JSON (with its id) when the lookup resolves to exactly one component, or an error listing available names if not found. Detail is opt-in: pass 'api' for the component's declared prop contract, 'usage' for static JSX-site counts and observed prop values, 'relationships' for sorted outgoing uses and derived incoming usedBy counts, 'conflicts' for bounded source-conflict evidence, or 'all' for every projection. These are static source-site facts, never runtime frequency. When several components share the name and neither governance nor scope decides, returns { ambiguous, matches, instruction } — follow the instruction: match each candidate's rationale.when against the user's intent, and if that doesn't decide, ask the user; never pick arbitrarily. Use this when you need implementation details for a known component to reuse it rather than recreate it. For a list of all components, use get_design_context with category 'components' instead.

Get a bounded, repeatable page of design-system conflicts. Read-only, no side effects. Filter by type, status, scope, exact component name or durable component ID, and a structured fieldPath prefix. Use offset and limit for pagination (default 25, maximum 100). For resolved design values, use get_token or get_component instead.

Get the design rules inferred from your codebase patterns. Read-only, no side effects. Returns JSON with a list of rules including category, pattern, and confidence, or an error if no rules have been generated yet. Pass category to filter: spacing, colors, typography, borderRadius, naming, components. Omit category to get all. Use this to understand implicit conventions the codebase follows. For explicit design token values, use get_token. For source conflicts, use get_conflicts.

Get hardcoded token values: literals in source code typed inline instead of referencing a design token, bypassing the contract. Read-only, no side effects. Returns JSON with a count, suggestion-coverage stats, and a list with file:line:column, the captured literal, the surrounding utility (e.g. 'bg-[#ff0000]'), and an optional smart-match suggestion when a contract token has the same value. Pass category to filter: 'all' | 'colors' | 'spacing' (hardcoded values are only detected for these). Call this BEFORE generating UI with literal values — prefer the suggested token over a hardcoded literal. For available tokens to use instead, use get_design_context or get_token.