systembridge-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Capabilities
Features and capabilities supported by this server
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_tokensA | Search and discover design tokens by name, type, value, or other criteria. Use this to answer questions like 'What color tokens exist?', 'Find all spacing tokens', or 'Show deprecated tokens'. When results are truncated (e.g. '50 of 200'), offer to fetch more by calling again with limit: . Do not report truncation as a failure. |
| validate_tokensA | Validate design tokens against configurable rules. Checks naming conventions, value formats, type requirements, deprecated references, and architectural patterns. Returns a structured report with errors, warnings, and suggestions. |
| transform_tokensA | Transform design tokens into platform-specific output files using Style Dictionary. Generates CSS custom properties, SCSS variables, JavaScript modules, iOS/Swift code, Android XML, Compose code, etc. Use dryRun=true to preview without writing files. |
| list_dimensionsA | List all variation dimensions (e.g. color-scheme, density) defined in your design-token theming config, with their allowed values and defaults. |
| list_themesA | List all named themes defined in config. Each theme is a specific combination of dimension values (e.g. dark + compact). |
| resolve_themeA | Resolve the full set of design tokens for a specific theme (or arbitrary coordinate set). Shows how tokens change from the default. When truncated, offer to fetch more by calling again with limit set to the total count. |
| diff_themesB | Compare two themes side-by-side and show which tokens differ, which are added, and which are removed. |
| list_brandsA | List all brands defined in config, showing their token paths, token-set overrides, and dimension defaults. |
| resolve_brandA | Resolve design tokens for a specific brand, optionally combined with a theme. Shows how brand overrides affect the token system. When truncated, offer to fetch more by calling again with limit set to the total count. |
| diff_brandsA | Compare two brands side-by-side, showing which tokens differ between them. Optionally resolves both under the same theme. |
| list_templatesA | List all available factory templates for generating new token systems. Shows required parameters and built-in algorithm options. |
| generate_systemB | Generate a new design-token system from a template. Supports color palettes, spacing scales, and full systems. Use dryRun=true to preview first. |
| describe_ontologyA | Explain the semantic token naming model — property classes (CSS targets), semantic intents, UX contexts, interaction states, emphasis modifiers, and the canonical naming formula. Use this to understand how semantic tokens should be structured. |
| scaffold_semanticsA | Generate a minimum viable semantic token set from a component inventory. Provide a comma-separated list of components (e.g. 'button, text-input, card, alert') and get properly structured tokens with CSS property class separation, intent coverage, and state completeness. |
| audit_semanticsA | Run a comprehensive semantic token audit on your existing token set. Analyzes naming compliance, property-class separation, coverage gaps, scoping violations, accessibility pairing, and suggests migrations. Returns a health score (0-100) and detailed report. |
| analyze_coverageA | Show the semantic token coverage matrix — which UX contexts have which property classes covered, and where the gaps are. Displays a table of contexts × property classes with status indicators. |
| check_contrastA | Check color contrast ratios using WCAG 2.1 and/or APCA algorithms. Two modes: (1) provide explicit foreground + background colors, or (2) scan your token set for all foreground/background pairs and report failures. |
| analyze_topologyA | Analyze token topology with dependency graph, anti-pattern detection, and structure analysis. Shows token relationships, reference chains, isolated tokens, circular dependencies, and common anti-patterns like primitive leakage, naming inconsistencies, and redundant tokens. Includes visual dependency graph (Mermaid), distribution charts, and coverage matrix. |
| generate_refactor_scenariosA | Generate migration scenarios for token refactoring with risk assessment. Produces 3 approaches (conservative, progressive, comprehensive) with detailed action plans, effort estimates, and risk profiles. Helps plan B→C token migration by comparing trade-offs and recommending best path forward based on readiness. |
| execute_migrationA | Execute token migration with automated reference updates, validation, and rollback. Applies scenario phases to token system, updates references across codebase, validates integrity (no broken refs/circular deps), and checks accessibility. DEFAULTS TO DRY RUN for safety - set dryRun:false to apply changes. Creates snapshot before execution for rollback if needed. |
| generate_paletteA | Generate color palettes using pluggable strategies. Supports HSL ramp (built-in), Leonardo (optional), manual hex values, or importing from existing tokens. Returns tonal scales with contrast metadata. |
| map_palette_to_semanticsA | Map generated palette scales to semantic tokens using configurable rules. Includes built-in presets for light-mode and dark-mode mappings. Can write output to disk with merge and split strategies. |
| plan_flowA | Solve 'blank canvas syndrome' — describe a screen, feature, or user problem in plain language and get back suggested UI patterns, component inventories, token surface requirements, and next steps. Perfect for starting a new design or understanding what a feature needs from the design system. |
| audit_designA | Audit a partial or complete design against the design system. Provide the components used in your design and get a gap analysis: missing tokens, naming issues, accessibility problems, and concrete fixes. Use this before handoff to ensure design-system coverage. |
| analyze_uiA | Analyze UI elements and colors against the design system. Describe the components you see and the colors used — get back which components are in the system, which colors match existing tokens (using perceptual color distance), and what gaps exist. Useful for reverse-engineering a screenshot or mockup into system terms. |
| audit_figma_usageA | Audit Figma variable usage and cross-reference with local design tokens. Analyzes sync status between Figma variables and local token definitions, identifies unused tokens, missing definitions, and naming discrepancies. Helps maintain consistency between Figma designs and token system. Note: Requires Figma variable data from mcp_figma_get_variable_defs. |
| extract_figma_tokensA | Extract Figma variables and convert to standardized token formats (W3C, Tokens Studio, Style Dictionary). Takes Figma variable definitions from mcp_figma_get_variable_defs and transforms them into design tokens with proper type inference, collection mapping, and metadata. Useful for syncing Figma variables to your local token system. |
| validate_figma_tokensA | Validate Figma variables against local token definitions. Checks for naming mismatches, type errors, missing mappings, and value discrepancies. Provides detailed validation report with errors, warnings, and sync status. Use strict mode to fail on any mismatch, or non-strict for warnings only. |
| extract_stylesA | Extract design tokens from CSS and SCSS files. Reverse-engineers colors, spacing, typography from stylesheets. Use when project has styles but no design tokens. Scans for CSS custom properties (--var: value) and SCSS variables ($var: value). |
| generate_component_docsA | Generate comprehensive component documentation combining local tokens, Figma component data, and design system knowledge. Creates LLM+human-readable markdown with frontmatter, token references, code examples, and accessibility information. Perfect for design-to-development handoffs. |
| analyze_scalesA | Analyze existing design token scales (spacing, typography, etc.). Detects mathematical patterns (linear, modular, fibonacci, etc.), identifies outliers, and suggests improvements based on design principles. |
| generate_scaleA | Generate a mathematical scale for design tokens. Supports linear, modular (geometric), exponential, fibonacci, golden ratio, harmonic, and hybrid strategies. Returns token-ready values. |
| suggest_scaleB | Suggest optimal scale parameters based on design principles. Combines Swiss style, Material Design, iOS HIG, financial UI, and other industry standards to recommend strategy, ratio, base, and constraints. |
| derive_density_modeA | Derive a new density mode (compact/spacious) from existing tokens. Applies scale factors while respecting WCAG accessibility constraints (44px minimum touch targets). Outputs conditional tokens. |
| audit_scale_complianceA | Audit design token scales against accessibility and platform standards. Checks WCAG 2.2 (44px touch targets, 1.5 line height), Material Design (8dp grid), and iOS HIG (8pt grid) compliance. |
| generate_fluid_scaleB | Generate fluid/responsive scales using CSS clamp(). Creates viewport-aware tokens that scale between min/max sizes. Based on Utopia fluid typography methodology. |
| generate_make_guidelinesA | Generate a structured 'guidelines/' folder for Figma Make. Exports your design system's tokens and component rules into Markdown format that Figma Make's AI can use to understand your system context. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| create-token | Guided workflow to create a new design token with proper naming, typing, and documentation. Checks for duplicates and suggests alternatives. |
| audit-tokens | Run a comprehensive audit of your design token architecture. Checks for issues, suggests improvements, and identifies areas for evolution. |
| design-semantic-tokens | Guided workflow to design semantic tokens for your component inventory. Understands your components, scaffolds the right token surface, and audits for gaps. |
| design-color-palette | Guided workflow to generate a color palette and map it to semantic tokens. Walks through palette generation, preview, and semantic mapping with contrast checking. |
| design-from-scratch | Start a new design from a problem description. Identifies UI patterns, suggests components, resolves token requirements, and walks through scaffolding the complete token surface. |
| design-handoff-review | Review a design before developer handoff. Audits component coverage, token completeness, naming compliance, and accessibility. |
| component-reference | Find curated component implementations from 50+ production design systems. Points to component.gallery for pattern research, then helps cross-reference with your local tokens. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| tokens | Design tokens grouped by category. Use 'all' for everything, or a category name like 'color', 'spacing', 'typography'. |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/teyepe/systembridge-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server