Skip to main content
Glama
kicholiz

Figma Write Bridge MCP

by kicholiz

get_style_guide

Extract a usage style guide from a Figma page or node subtree to audit colors, variables, fonts, spacing, radii, strokes, and opacities.

Instructions

Extract a usage style guide from the current page (or rootNodeId subtree): counts of distinct solid colors (hex), color variable bindings, font family/style combos, font sizes, line heights, spacing/gap/padding values, corner radii, stroke weights, and opacities.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rootNodeIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. 'Extract' implies a read-only aggregation and the description details the returned dimensions, but it never states that nothing is mutated, nor does it cover permissions, cost, or performance on large subtrees.

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

Conciseness4/5

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

A single dense sentence with the scope stated first and the enumerated outputs after. Every item in the list is substantive rather than filler, though the enumeration is long enough to be slightly heavy.

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?

With no output schema and no annotations, the description does the heavy lifting by spelling out the aggregated dimensions and the scope selector. It is close to complete for a read/aggregation tool, missing only an explicit read-only statement and any note on output shape.

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?

There is one parameter (rootNodeId) with 0% schema description coverage, so the schema alone is uninformative. The description compensates by explaining that the extraction targets the current page or the rootNodeId subtree, giving the parameter real meaning, though it doesn't specify format or behavior when the id is invalid.

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 ('Extract') and resource ('usage style guide') and enumerates exactly what is aggregated (solid colors, font combos, spacing, radii, stroke weights, opacities), which is genuinely distinct from siblings like get_styles or get_document_info. It does not, however, name or contrast any alternative tool, so sibling differentiation is left to inference.

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

Usage Guidelines3/5

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

The parenthetical '(or rootNodeId subtree)' tells the agent the scope of extraction from the current page, which implies when the tool is relevant. There is no explicit when-to-use/when-not guidance and no mention of which sibling to prefer for related tasks.

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