Figma Console MCP Server

figma_lint_design

Check a Figma page or node for WCAG 2.2 accessibility and design quality issues, returning categorized findings by severity and conformance level so teams can fix contrast, focus, alt text, and layout problems.

Instructions

Run comprehensive accessibility (WCAG 2.2) and design quality checks on the current page or a specific node tree. WCAG conformance checks (10 rules): color contrast (AA), non-text contrast (1.4.11), color-only differentiation (1.4.1), focus indicators (2.4.7), touch targets (2.5.8), image alt text (1.1.1), heading hierarchy (1.3.1), reflow/responsive (1.4.10), reading order (1.3.2), and disabled context (4.1.2). Best-practice readability hints (opt-in via rules: ['best-practice'] or ['all']): text sizing, line height, letter spacing, paragraph spacing. Note: line/paragraph spacing below 1.5x/2x is NOT a WCAG 1.4.12 failure — 1.4.12 requires supporting user spacing overrides without breaking (a code concern, see figma_scan_code_accessibility), not specific design values — so these are non-normative hints scoped to multi-line text only. Design system checks (5 rules): hardcoded colors, missing text styles, default names, detached components, and token misuse (a semantic token bound to the wrong property, e.g. a bg/* or surface/* variable used as a text fill). Layout checks: missing auto-layout, empty containers. Default audit runs WCAG + design-system + layout (best-practice hints excluded). Returns categorized findings with severity levels (critical/warning/info) and WCAG conformance level (a/aa/aaa/best-practice) so teams can filter by target level. Use natural language like 'check my design for accessibility issues' or 'lint this page'. Requires Desktop Bridge plugin.

Input Schema

Name	Required	Description
`rules`	No	Rule filter. Default (omitted) = ['wcag','design-system','layout'] — real WCAG conformance plus quality checks, with best-practice hints excluded. Groups: ['wcag'] (10 conformance rules), ['best-practice'] (text-size, line-height, letter-spacing, paragraph-spacing), ['all'] (everything incl. best-practice), ['design-system'], ['layout']. Or specific rule IDs like ['wcag-contrast', 'wcag-focus-indicator', 'wcag-disabled-no-context'].
`nodeId`	No	Node ID to lint (defaults to current page)
`maxDepth`	No	Maximum tree depth to traverse (default: 10)
`maxFindings`	No	Maximum findings before stopping (default: 100)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.46.0Nov 6, 2026

TDQS

A3.9/5.0

Behavior4/5

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

No annotations, so the description carries the burden, and it does well: discloses the rule set, the default subset, severity levels (critical/warning/info), conformance level tagging (a/aa/aaa/best-practice), and a prerequisite (requires Desktop Bridge plugin). It doesn't describe performance/execution cost or error behavior, keeping it short of a 5.

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

Conciseness3/5

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

Purpose and default scope are front-loaded, but the body is a dense enumeration of ten WCAG rules plus a long aside on 1.4.12 that reads as much like documentation as a routing signal. It's information-rich but heavier than needed for tool selection.

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

Completeness4/5

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

For a 4-optional-param audit tool with no output schema and no annotations, the description covers prerequisites (Desktop Bridge), the rule taxonomy, default behavior, and the shape of findings (categorized, severity + conformance level). Enough for an agent to call it correctly; only error/edge behavior is unaddressed.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description adds real semantic meaning by explaining the rule groups, the default when omitted, allowed group shorthands (['wcag'], ['all'], ['best-practice']), and specific rule-ID examples. It also clarifies the non-normative nature of the best-practice hints, which the schema does not.

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

Purpose4/5

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

States a specific verb+resource: 'Run comprehensive accessibility (WCAG 2.2) and design quality checks' on a page or node tree, and enumerates the rule categories. It's clear what it does, but it doesn't distinguish itself from close siblings like figma_audit_component_accessibility or figma_audit_design_system_report, which also audit design.

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

Usage Guidelines4/5

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

Explicitly states the default audit scope (WCAG + design-system + layout, best-practice excluded) and how to opt into best-practice via rules, plus natural-language usage examples. It also names figma_scan_code_accessibility as the alternative for the code-side 1.4.12 concern, though it doesn't route against the other audit siblings.

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

Deploy Server

figma_lint_design

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools