figma-antigravity-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| figma_auth_loginA | LOCAL TOOL — Starts interactive one-click OAuth authorization with Figma. Do what: Launches the user's default browser automatically to approve Figma Remote MCP connection, and returns a clickable Markdown URL directly in the chat interface. Expected output: JSON containing { auth_url, markdown_link, instructions } so the user can click directly or let the opened browser complete login. Use this whenever authentication is missing, expired, or when the user wants to connect their Figma account. |
| figma_auth_statusA | LOCAL TOOL — Checks current Figma authentication status. Do what: Inspects active access tokens, user seat, expiry time, and secure storage location. Expected output: JSON containing { authenticated, user, email, expires_at, is_expired, storage_path }. |
| figma_get_current_contextA | LOCAL TOOL — Call this FIRST before any other Figma tool when the user has not explicitly provided a Figma URL or fileKey. Do what: Detects which Figma file the user currently has open in Figma desktop app, returning fileKey, nodeId, and instructions. Expected output: JSON with { authentication, figma_desktop_open_file: { fileKey, fileName, nodeId, url }, instructions[] }. |
| whoamiA | Do what: Returns the authenticated user identity (handle, email), all plans/teams, and available seats. Expected output: { handle, email, plans: [{ name, key, role, seat }] }. MUST call this if experiencing permission errors or before calling create_new_file to resolve planKey. |
| get_metadataA | Do what: Returns XML document outline for a Figma design file — node IDs, layer names, types, positions, sizes. Expected output: XML string of the document tree rooted at nodeId (or list of pages when nodeId is omitted). Use this to explore unfamiliar files before calling get_design_context. Prefer get_design_context for design-to-code. IMPORTANT: Only works on /design/ files. When nodeId is omitted, lists top-level pages only. |
| get_design_contextA | Do what: Primary READ tool for design-to-code. Returns layout, styles, component props, reference code snippet, screenshot, and asset URLs for a node. Expected output: { code (string), screenshot (URL), assets (map of download URLs), metadata }. Always prefer this over get_metadata for design inspection. Call figma_get_current_context first if you do not know the fileKey. IMPORTANT: nodeId is REQUIRED — extract from URL ?node-id=1-2 as "1:2". Never guess or pass empty. |
| get_variable_defsA | Do what: Returns all design variables (tokens) referenced by a node — colors, spacing, typography values with their names and resolved values. Expected output: Map of variable names to resolved values e.g. { "p1-orange": "#ED9E4A" }. Use to extract the design system token palette before writing code or creating new nodes. |
| get_screenshotC | Do what: Renders a PNG screenshot of any node and returns a short-lived CDN URL + curl download command. Expected output: { url (string CDN URL), curl (string), metadata: { width, height, original_width, original_height } }. IMPORTANT: Both fileKey and nodeId are REQUIRED. |
| download_assetsA | Do what: Downloads rendered exports and raw source images/SVGs for a single node. Expected output: { export: { url, format }, rawImages: [{ url, format }], svgAssets: [{ url }] }. Use when: you need the rendered PNG/SVG/PDF of a node, or want to extract embedded raster fills for cross-file transfer. |
| upload_assetsA | Do what: Uploads images (PNG, JPG, GIF, WebP) or SVGs into a Figma file. Returns single-use upload URLs. POST raw bytes to each returned URL. Expected output: { uploads: [{ uploadUrl, targetNodeId?, commitUrl? }] }. |
| use_figmaA | Do what: PRIMARY WRITE TOOL. Executes arbitrary JavaScript against the Figma Plugin API sandbox to create, edit, delete, or query any design element. Expected output: Return value of the executed code (JSON-serializable). Mutations are applied live to the Figma canvas. CRITICAL RULES:
|
| create_new_fileA | Do what: Creates a new blank Figma design, FigJam, or Slides file in the user's drafts (or a specified project). Expected output: { fileKey (string), url (string) } — the new file's key and direct URL. IMPORTANT: Requires planKey from whoami. Do NOT call if the user already has a file open — use use_figma instead. |
| generate_diagramB | Do what: Creates a flowchart, sequence diagram, state diagram, gantt chart, or ER diagram in FigJam from Mermaid.js syntax. Expected output: { url (string) } — direct URL to the created FigJam diagram. MUST show this URL as a markdown link. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Most tools target clearly distinct actions—auth, context detection, reading, exporting, uploading, writing, and file/diagram creation—and the descriptions actively steer between get_metadata and get_design_context. However, get_screenshot and download_assets both render node exports, and figma_auth_status/whoami both surface user identity, creating mild ambiguity.
The majority of tools follow a clear verb_noun snake_case pattern like get_metadata, upload_assets, and create_new_file, with the figma_ auth/context cluster staying internally consistent. The bare whoami and the generic use_figma break the pattern slightly, but the overall convention remains predictable.
13 tools is within the healthy range for a Figma integration, covering auth, current-context, inspection, assets, writing, file creation, and diagrams. It is slightly heavier than necessary because get_screenshot overlaps with the export side of download_assets and whoami partially duplicates figma_auth_status.
The set covers the full design-to-code lifecycle: authentication, detecting the active file, reading metadata and variables, extracting screenshots/assets, uploading assets, and mutating designs via use_figma. Creating new files and generating diagrams round out the surface with no obvious dead ends.