Skip to main content
Glama
southleft

figma-console-mcp

by southleft
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

figma_ds_analyze

Analyze app codebases to inventory components, detect frameworks, styling methods, and vendor layers before design system extraction. Compare multiple targets to find shared design language.

Instructions

Analyze one or more production app codebases as the first step of design system extraction. Detects framework (React/Next/Angular/Web Components), styling methods (Tailwind v3/v4, CSS Modules, SCSS, Emotion, styled-components), and vendor component layers (shadcn/ui, Radix, MUI, Chakra, etc.); builds a component inventory with per-component classification (vendored / wrapped / pure-vendor / bespoke), prop contracts, real usage counts (porting rank), observed prop values (variant inference), and duplicate detection. Pass multiple targets to find the shared design language across several apps. Writes the full manifest to /.extraction/analysis.json and returns a compressed summary — read slices of the manifest for detail. Run this before figma_ds_extract_tokens and figma_ds_scaffold. Local Mode only.

Input Schema

NameRequiredDescriptionDefault
outDirNoDirectory where the design-system package will be generated (manifests persist under <outDir>/.extraction/). Default: '<first target>/design-system'.
excludeNoSubstring filters on relative paths to skip (node_modules, dist, .next etc. are always skipped).
includeNoSubstring filters on relative paths — when set, only matching files are scanned (e.g. ['src/', 'app/']).
targetsYesApp root directories to analyze. Absolute paths strongly recommended (the MCP server's working directory is not the project). Multiple targets = cross-app extraction: the inventory merges and duplicate components across apps are flagged.
maxFilesNoHard cap on files scanned per target (default 5000).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.46.0

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and succeeds: it discloses framework/style/vendor detection, component classification, prop contracts, usage counts, duplicate detection, manifest writing to <outDir>/.extraction/analysis.json, and that only a compressed summary is returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose, then details the analysis outputs, manifest behavior, sequencing, and execution constraint. The description is dense but every sentence contributes useful selection or invocation information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a complex multi-parameter analysis tool with no output schema and no annotations, the description is complete enough: it covers purpose, outputs, manifest location, summary return behavior, sequencing, and local-mode restriction.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all five parameters thoroughly. The description adds useful context for targets and outDir but does not materially expand the semantics of include, exclude, or maxFiles beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: analyze production app codebases for design system extraction. It also distinguishes itself from siblings by naming itself the first step before figma_ds_extract_tokens and figma_ds_scaffold.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to run this before figma_ds_extract_tokens and figma_ds_scaffold, and clarifies that it is Local Mode only. It also explains that passing multiple targets enables cross-app design language extraction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools