Skip to main content
Glama

figma_create_chart

Render scatter, line, donut, pie, bar, and histogram charts directly in Figma with a single data call. Supports categorical Y bands, multi-series lines, stacked bars, annotations, and DS variable integration for colors and typography.

Instructions

Render a chart directly in Figma. All data is sent in one call — no per-element round trips. Supported chart types: • scatter / jitter — scatter plot with categorical Y bands • line — line chart with optional area fill, smooth curves, multi-series • donut / pie — donut or pie chart with legend and optional center label • bar / histogram — vertical bar chart with optional stacked segments; supports annotation vlines

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chartTypeYes
parentNodeIdNo
nameNo
widthNo
heightNo
barsNoBar chart data. Each item: { label: string, value: number, color?: string (DS hex) }.
annotationsNoVertical annotation lines on a bar chart. Each item: { x: number, label?: string, color?: string }.
dataNoScatter/jitter plot data points. Each item: { x: number, y: string (category), label?: string, color?: string }.
xDomainNo[min, max] for X axis.
categoriesNoDonut/pie/scatter/bar segment definitions. Keys are segment names, values are { value: number, color: string (DS hex), colorVariable?: string (DS variable path) }.
categoryVariablesNoDS variable paths per category. Keys match categories keys, values are DS color variable paths (e.g., {"Pass": "Component colors/Utility/Success/utility-success-500"}). Tried first; hex fallback from categories if binding fails.
categoryOrderNoRender order for categories (donut/pie/scatter).
dotSizeNo
jitterNo
xTicksNoExplicit X axis tick values.
tickSuffixNoSuffix appended to every tick label (e.g. "%", "ms").
xLabelNo
seriesNoLine chart series. Each item: { name: string, data: [{ x: number, y: number }], color?: string (DS hex), smooth?: boolean, area?: boolean }.
yDomainNo[min, max] for Y axis.
yTicksNoExplicit Y axis tick values.
xTickSuffixNo
yTickSuffixNo
yLabelNo
sizeNo
innerRadiusNo
centerLabelNo
centerSubLabelNo
legendPositionNoLegend placement for donut/pie charts. "right" (default) places legend beside the chart. "bottom" places it below.
bgVariableNoDS variable path for chart outer frame background (e.g., "Colors/Background/bg-secondary"). Replaces hardcoded #F9FAFB.
radiusVariableNoDS radius variable path for chart outer frame (e.g., "Radius/radius-md"). Replaces hardcoded 8px.
gridVariableNoDS variable path for grid line color (e.g., "Colors/Border/border-secondary"). Replaces hardcoded #E7EAEE.
labelFillVariableNoDS variable path for chart label text color (e.g., "Colors/Text/text-tertiary (600)"). Replaces hardcoded #6D778C.
labelTextStyleIdNoDS text style key for chart labels. Applied to all axis/legend labels.
fontFamilyNoFont family for chart labels (overrides session default).
Behavior4/5

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

The description adds the important behavioral trait of single-call data submission beyond annotations. However, it does not explicitly state that the tool creates a new node in the Figma document, though it's implied. Annotations do not contradict.

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?

The description is concise with two sentences and a bullet list, front-loading the purpose and using clear formatting with no unnecessary words.

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

Completeness3/5

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

For a complex tool with 34 parameters and no output schema, the description provides a good overview but lacks details on many parameters and return values, leaving gaps for selecting correct parameters.

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?

Given 56% schema description coverage, the description adds some value by listing chart types and mentioning features like annotation vlines, but it does not explain parameter relationships to chart types in depth. Baseline 3 is appropriate.

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?

The description clearly states 'Render a chart directly in Figma' and lists specific chart types (scatter, line, donut, etc.), distinguishing it from sibling tools that create shapes or frames.

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 description mentions 'All data is sent in one call — no per-element round trips,' implying efficiency, but does not explicitly state when to use this tool versus alternatives or when not to use it.

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

Install Server

Other Tools

Latest Blog Posts

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/miapre/mimic-ai'

If you have feedback or need assistance with the MCP directory API, please join our Discord server