Skip to main content
Glama
Sign In
Figxel

Figxel

by AvYour
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Check a design for defects

figma_check_layout
Read-only

After each section and before calling anything done: a designer's last look, in numbers (figma_export_node shows the picture).

Instructions

After each section and before calling anything done: a designer's last look, in numbers (figma_export_node shows the picture). Per node, with a number and fix: text overflowing, collapsed, overlapping or covered; content clipped or sticking out; a fill child in a hug parent; stacked frames; placeholder copy; low contrast (WCAG); zero-size, empty or default-named nodes; text off or cut by a slide. audit adds: tokens (unbound values), names (duplicates), fonts (expectFonts), board (FigJam), craft (finish: sizes, edges, near-touches, contrast; safeArea, minTextSize), tells (generated look; warning if the brief avoids it), handoff (share bound), a role's: a11y (targets, focus, labels), states, copy, system (format, scale, grid), deck (words, headlines, floor), mark (size, versions, clear space), icons (canvas, stroke, pixels), library (modes, aliases). briefId: against that brief's numbers. ok: true = no errors or warnings. Default: the selection, then the page (Slides: focused slide). Reads only.

Input Schema

NameRequiredDescriptionDefault
auditNoQA passes to add: tokens, names, fonts, board, craft (finish defects), tells (the generated look; info, a warning where a page or top brief avoids it, and run by default under one), handoff (how much is bound to the system), a11y, states, copy, system, deck, mark, icons, library (a role's sign-off checks; with briefId, the brief's numbers).
limitNoMax findings returned. Default 100.
nodeIdNoThe frame or section to check. Defaults to every selected node, then the page.
briefIdNoThe node a brief is stored on (figma_set_brief returns it): the role audits measure against its platform, viewport, screens, system, room, applications, grid and platforms, and craft takes its minTextSize and safeArea. At page or top gear its `avoid` kinds are warnings, and tells run by default where its role's sign-off judges them or it avoids one. A motion brief judges layout where the viewer sees it (restPose). Default: the brief in force, unless the checked node is another brief's work (its own record, its top-level frame's, or a brief listing it), which wins; audit.brief names the one used.
nodeIdsNoSeveral roots in one call, e.g. a batch of 3–5 slides. Not with nodeId.
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
maxNodesNoStop after this many nodes. Default 3000.
safeAreaNo"x,y,width,height" in the root's coordinates (its top-left is 0,0), from the brief — no presets. Text, logos and CTAs outside it are flagged. Implies craft.
expectFontsNoFont families the design should use, e.g. ["Inter"]; implies the fonts audit.
minSeverityNoHide findings below this level. Default "info".
minTextSizeNoSmallest readable text in px of the frame: the device's floor × frame width ÷ device width, e.g. 28 or more on a 1080-wide story. Implies craft.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.3.0
    • changedInput schema / properties / audit / description
      Previous value: -"QA passes to add: tokens, names, fonts, board, craft (finish defects), tells (the generated look; info only), handoff (how much is bound to the system)."New value: +"QA passes to add: tokens, names, fonts, board, craft (finish defects), tells (the generated look; info, a warning where a page or top brief avoids it, and run by default under one), handoff (how much is bound to the system), a11y, states, copy, system, deck, mark, icons, library (a role's sign-off checks; with briefId, the brief's numbers)."
    • changedInput schema / properties / audit / items / enum
      Previous value: -[
-  "tokens",
-  "names",
-  "fonts",
-  "board",
-  "craft",
-  "tells",
-  "handoff"
-]New value: +[
+  "tokens",
+  "names",
+  "fonts",
+  "board",
+  "craft",
+  "tells",
+  "handoff",
+  "a11y",
+  "states",
+  "copy",
+  "system",
+  "deck",
+  "mark",
+  "icons",
+  "library"
+]
    • changedInput schema / properties / audit / maxItems
      Previous value: -7New value: +15
    • addedInput schema / properties / briefId
      Added value: +{
+  "description": "The node a brief is stored on (figma_set_brief returns it): the role audits measure against its platform, viewport, screens, system, room, applications, grid and platforms, and craft takes its minTextSize and safeArea. At page or top gear its `avoid` kinds are warnings, and tells run by default where its role's sign-off judges them or it avoids one. A motion brief judges layout where the viewer sees it (restPose). Default: the brief in force, unless the checked node is another brief's work (its own record, its top-level frame's, or a brief listing it), which wins; audit.brief names the one used.",
+  "type": "string"
+}
  2. First observedv0.1.1

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly/non-destructive, so the bar is lower, yet the description still adds value: default scope (selection, then page, focused slide in Slides), the `ok: true` success signal, that every finding carries a number and a fix, and the effect of `audit` passes. It does not describe how truncated results are signalled when `limit`/`maxNodes` are hit, which is the main remaining gap.

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?

It is compact and the when-to-run clause is front-loaded, but the body is a single telegraphed run-on of semicolon-delimited jargon ("a fill child in a hug parent", "board (FigJam)", "tells") that is hard to parse on first read. Important scope defaults are buried at the tail end rather than placed where an agent will scan for them.

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 an 11-parameter QA tool with no output schema and no required parameters, the description covers the essentials: what is checked, what the audit passes add, how the target and brief are resolved, and what `ok` means. Only the shape of the findings payload and truncation behaviour are left implicit.

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 11 parameters, and the description largely restates the audit pass list and brief defaults. The one genuinely additive point is the brief-precedence rule (a node that is another brief's work wins over the default brief); otherwise it adds little beyond the structured fields.

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?

The description establishes a specific verb (check) and resource (per-node layout findings) and explicitly distinguishes itself from figma_export_node ("shows the picture"), naming concrete defect classes such as overflow, clipping, contrast and zero-size nodes. The framing "a designer's last look, in numbers" is metaphorical rather than literal, but the enumerated defect list leaves no doubt about what the tool produces.

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?

"After each section and before calling anything done" gives an explicit trigger point, and the parenthetical routing to figma_export_node separates it from the visual-inspection sibling. It stops short of stating when this tool should not be used or that it never repairs findings, although "Reads only" implies the latter.

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