What can you do with this server?

This server is a local MCP bridge that connects AI assistants to the Figma desktop app, allowing inspection, editing, and automation of the current Figma or FigJam document via the Figma Plugin API. * Connection & inspection: Check plugin status (figma_status), get current page structure (figma_get_page), retrieve detailed node info (figma_get_node), get selected nodes (figma_get_selection), list local styles, variables, and components (figma_get_styles, figma_get_variables, figma_get_components). * Export: Export nodes as PNG, SVG, or PDF to disk (figma_export_node), with optional scale and output path. * Editing: Change text content (figma_set_text), set solid fill colors (figma_set_fill), create frames and text nodes (figma_create_frame, figma_create_text), delete nodes (figma_delete_node), move (figma_move_node), resize (figma_resize_node). * Advanced: Run arbitrary JavaScript with access to the figma Plugin API (figma_run_js), enabling operations not covered by dedicated tools. * Multi-client support: Allows multiple MCP client processes to connect through a shared bridge, with automatic proxy mode.

Which integrations are available for this server?

Provides tools for inspecting the current Figma or FigJam document, exporting nodes as PNG/SVG/PDF, updating text and fill colors, creating/moving/resizing/deleting nodes, and running advanced JavaScript through the Figma Plugin API.

How do I use Figma Bridge MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Figma Bridge MCP list the layers on the current page" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko zh

Figma Bridge MCP

by Halil-KAPLAN

Overview Schema Related Servers Score Discussions

JavaScript

Local

Figma Bridge MCP

Figma Bridge MCP is a local Model Context Protocol (MCP) server that connects MCP-compatible AI clients to the Figma desktop app. It lets an AI assistant inspect the current Figma or FigJam document, export nodes, and make controlled changes through the Figma Plugin API.

Plugin Preview

Figma Bridge plugin showing an active connection

The plugin window shows the bridge connection status, recent connection events, and a manual reconnect button. Keep this window open while your MCP client is working with Figma.

Related MCP server: Figma Native MCP

Features

Inspect the current page, selected layers, individual nodes, local styles, variables, and components.
Export Figma nodes as PNG, SVG, or PDF straight to disk.
Update text and solid fill colors.
Create, move, resize, and delete nodes.
Run advanced JavaScript through the Figma Plugin API.
Use node IDs copied from Figma URLs in either 1:23 or 1-23 format.
Connect multiple MCP client processes through a shared local bridge server.
Use the Windows Figma desktop app from AI agents running natively on Windows or inside WSL2.
Work with any MCP client that supports stdio servers, including Codex, Claude Code, and VS Code MCP clients.

How It Works

┌──────────────────────────────┐
│ MCP client                   │
│ Codex, Claude Code, VS Code  │
└──────────────┬───────────────┘
               │ MCP over stdio
┌──────────────▼───────────────┐
│ server.js                    │
│ Node.js MCP/WebSocket bridge │
└──────────────┬───────────────┘
               │ ws://localhost:3055
┌──────────────▼───────────────┐
│ Figma Bridge plugin          │
│ ui.html ↔ code.js            │
└──────────────┬───────────────┘
               │ Figma Plugin API
┌──────────────▼───────────────┐
│ Open Figma or FigJam file    │
└──────────────────────────────┘

The first server.js process that acquires port 3055 becomes the primary bridge. If another MCP client starts another instance, that process automatically enters proxy mode and forwards its commands to the primary bridge. When multiple Figma plugins are connected, commands are sent to the most recently connected plugin.

Requirements

Node.js and npm. The current Node.js LTS release is recommended.
The Figma desktop app.
An MCP client with stdio server support.

Install Node.js in the same environment where the AI client will launch the MCP server: install Windows Node.js for native Windows clients or Linux Node.js inside WSL for WSL clients. The server itself is platform-independent. start.bat is included only as an optional Windows helper.

Installation

Clone this repository and install its dependency:

git clone https://github.com/Halil-KAPLAN/figma-bridge-mcp.git
cd figma-bridge-mcp
npm install

You can also download the repository as a ZIP file, extract it, open a terminal in the extracted directory, and run npm install.

Windows and WSL2 Support

Figma Bridge MCP supports both Windows-native development and WSL2 development. Figma always runs as the Windows desktop application; the MCP server runs in the same environment as the AI agent that launches it.

Development environment	Where Node.js and this repository run	Path used in MCP configuration	Figma application
Native Windows	Windows	`C:\path\to\figma-bridge-mcp\server.js`	Windows Figma Desktop
WSL2 terminal	WSL2 Linux	`/home/user/figma-bridge-mcp/server.js`	Windows Figma Desktop
VS Code opened normally on Windows	Windows, unless the agent is explicitly configured to use WSL	Windows path	Windows Figma Desktop
VS Code Remote - WSL	WSL2 Linux	WSL Linux path	Windows Figma Desktop

How the WSL2 connection works

When server.js runs inside WSL2, it opens the WebSocket bridge on port 3055. Windows forwards WSL networking applications to localhost, so the Windows Figma plugin can still connect to:

ws://localhost:3055

The complete WSL flow is:

AI agent in WSL
    → starts server.js in WSL over stdio
    → WSL WebSocket server listens on port 3055
    → Windows exposes the WSL service through localhost:3055
    → Figma Desktop plugin connects from Windows
    → the agent can inspect and edit the open Figma document

Microsoft documents Windows-to-WSL access through localhost in Accessing network applications with WSL.

Native Windows setup

Use a repository stored on the Windows file system and install dependencies with Windows Node.js:

git clone https://github.com/Halil-KAPLAN/figma-bridge-mcp.git
cd figma-bridge-mcp
npm install

The MCP command must use the Windows copy of Node.js and a Windows path to server.js.

WSL2 setup

For WSL development, keep the repository in the Linux file system and install dependencies inside WSL:

mkdir -p ~/code
cd ~/code
git clone https://github.com/Halil-KAPLAN/figma-bridge-mcp.git
cd figma-bridge-mcp
npm install

Open the WSL project in VS Code with:

code .

Confirm that VS Code displays WSL: <distribution> in the remote status indicator and that its integrated terminal uses paths such as /home/user/.... See the VS Code WSL tutorial for the Remote - WSL workflow.

While the bridge is running in WSL, you can test access from Windows with:

Test-NetConnection localhost -Port 3055

TcpTestSucceeded should be True.

Keep the agent and MCP server in the same environment

The node command and the server.js path are resolved by the environment where the AI agent is running:

A Windows-native agent needs Windows Node.js and a Windows path.
An agent running in WSL needs Node.js installed in WSL and a Linux path.
A VS Code Remote - WSL window should configure the MCP server from its WSL integrated terminal.
Do not use a C:\... path in a WSL MCP configuration or a /home/... path in a native Windows MCP configuration.

For the most predictable behavior, use one canonical installation per environment and configure all agents in that environment to launch the same server.js file. Multiple MCP processes in the same environment are supported: the first becomes the primary bridge and later processes automatically proxy through it.

Use Figma Bridge MCP in Figma

Figma Bridge MCP includes a local Figma development plugin. It does not need to be installed from the Figma Community. The plugin runs inside the open Figma or FigJam document and relays MCP commands between the local bridge server and the Figma Plugin API.

Install the plugin once

Development plugins must be imported with the Figma desktop app:

Open the Figma desktop app on macOS or Windows.
Create or open any Figma Design or FigJam file.
Open the Figma menu in the upper-left corner.
Select Plugins → Development → Import new plugin from manifest....
Browse to this repository and select plugin/manifest.json.
Figma adds Figma Bridge to the Development section of the Plugins menu.

The manifest only needs to be imported once on each computer. See Figma's development plugin guide for more information about importing local plugins.

Run the plugin for each session

Open the Figma Design or FigJam file that you want the AI agent to inspect or edit.
Start or reload your configured MCP client. It will normally launch server.js automatically. You can run npm start manually for diagnostics.
In Figma, select Plugins → Development → Figma Bridge.
Keep the plugin window open while the AI agent is using Figma.
Wait until the plugin displays Connected to bridge ✓.

The plugin connects to ws://localhost:3055. If the MCP server is not running yet, the plugin remains on Connecting... and retries automatically. You can therefore start the Figma plugin or the MCP client first.

The open document is the active target. If you switch documents, run the plugin in the document that you want the agent to use. Commands such as figma_get_selection operate on the layers currently selected in that document.

Let an AI agent use Figma through MCP

After the plugin shows Connected to bridge ✓, any configured AI agent that supports stdio MCP servers can discover and call the Figma Bridge MCP tools. The agent does not connect directly to your Figma account and does not require a Figma access token. Requests follow this path:

AI agent → MCP tool → server.js → Figma plugin → Figma document

The plugin executes the requested operation through the Figma Plugin API and returns the result to the agent over the same connection. The agent can then inspect the result, continue with another tool, or explain the changes it made.

Add Figma Bridge MCP to an AI Application

Figma Bridge MCP is a local stdio MCP server. The AI application launches it with this command:

node /absolute/path/to/figma-bridge-mcp/server.js

The path must be valid in the environment where the AI application runs. You normally do not need to run npm start separately because the MCP client starts and manages server.js itself.

Codex CLI and Codex IDE extension

Codex running on Windows

Run this command in PowerShell or the VS Code Windows terminal:

codex mcp add figma-bridge-mcp -- node C:\path\to\figma-bridge-mcp\server.js

Codex running in WSL2

Run this command in the WSL terminal or the VS Code Remote - WSL integrated terminal:

codex mcp add figma-bridge-mcp -- node /home/user/code/figma-bridge-mcp/server.js

Verify the configuration:

codex mcp list

Inside Codex, use /mcp to inspect the connected server and its tools. Codex CLI and the Codex IDE extension share config.toml when they run on the same host, so adding the server from the terminal also makes it available to the extension in that environment.

The equivalent Codex configuration is:

[mcp_servers.figma-bridge-mcp]
command = "node"
args = ["/absolute/path/to/figma-bridge-mcp/server.js"]

On Windows, the Codex IDE extension can also run Codex inside WSL by enabling this VS Code setting:

"chatgpt.runCodexInWindowsSubsystemForLinux": true

When that setting is enabled, install Node.js and Figma Bridge MCP inside WSL and use the WSL path in the Codex MCP configuration. In a VS Code Remote - WSL window, Codex already runs with the WSL project environment.

See the official Codex MCP documentation for MCP configuration and the Codex WSL documentation for the WSL workflow.

Claude Code CLI and VS Code extension

Claude Code MCP servers are most reliably added from a terminal. The VS Code extension can then manage and use the configured server.

Claude Code running on Windows

Run this command in PowerShell or the VS Code Windows terminal:

claude mcp add --transport stdio --scope user figma-bridge-mcp -- node C:\path\to\figma-bridge-mcp\server.js

Claude Code running in WSL2

Run this command in the WSL terminal or the VS Code Remote - WSL integrated terminal:

claude mcp add --transport stdio --scope user figma-bridge-mcp -- node /home/user/code/figma-bridge-mcp/server.js

Verify the configuration:

claude mcp list

In Claude Code CLI or the VS Code chat panel, use /mcp to view the connection and available tools. When VS Code is connected through Remote - WSL, run claude mcp add from the WSL integrated terminal so the command and Linux path are stored in the WSL Claude Code configuration.

See the official Claude Code MCP documentation and Claude Code VS Code documentation.

VS Code `.vscode/mcp.json`

Some VS Code MCP clients read workspace servers from .vscode/mcp.json. Use the configuration that matches the extension host.

Windows-native VS Code:

{
  "servers": {
    "figma-bridge-mcp": {
      "type": "stdio",
      "command": "node",
      "args": ["C:\\path\\to\\figma-bridge-mcp\\server.js"]
    }
  }
}

VS Code Remote - WSL:

{
  "servers": {
    "figma-bridge-mcp": {
      "type": "stdio",
      "command": "node",
      "args": ["/home/user/code/figma-bridge-mcp/server.js"]
    }
  }
}

Other terminal and desktop AI clients

Any AI client that supports local stdio MCP servers can use Figma Bridge MCP. Look for an MCP Servers, Tools, or Integrations setting and add a server with:

Name: figma-bridge-mcp
Transport: stdio
Command: node
Arguments: the absolute path to server.js

A common JSON format is:

{
  "mcpServers": {
    "figma-bridge-mcp": {
      "type": "stdio",
      "command": "node",
      "args": ["/absolute/path/to/figma-bridge-mcp/server.js"]
    }
  }
}

The exact configuration filename and the top-level key (mcpServers or servers) depend on the client. Terminal applications follow the same environment rule: use a Windows path when the application runs in Windows and a Linux path when it runs in WSL.

Use It with an AI Agent

After installing the Figma plugin and configuring your MCP client:

Open the target document in the Figma desktop app.
Run Plugins → Development → Figma Bridge and keep its window open.
Start or reload the AI agent so it launches the MCP server and discovers its tools.
Ask the agent to check the connection. It should call figma_status and report that the plugin is connected.
Ask the agent to inspect or modify the open document using natural language.

For example:

Check whether the Figma plugin is connected.
Show the structure of the current Figma page.
Get the details of node 2057:6604.
Export node 2057:6604 as a PNG at 2x scale.
Change the selected heading to "Welcome back".
List all local components on the current page.

When a node ID comes from a Figma URL such as node-id=2057-6604, you can pass either 2057-6604 or 2057:6604 to the bridge.

The AI agent decides which MCP tools to call based on your request. You can also explicitly name a tool when you need a specific operation, such as figma_get_selection, figma_export_node, or figma_set_text.

Available MCP Tools

Connection and inspection

Tool	Inputs	Description
`figma_status`	None	Reports whether a Figma plugin is connected
`figma_get_page`	None	Returns the current page and its direct children
`figma_get_node`	`nodeId`	Returns a node's properties and direct children
`figma_get_selection`	None	Returns detailed information about the currently selected nodes
`figma_get_styles`	None	Lists local paint, text, and effect styles
`figma_get_variables`	None	Lists local variable collections, modes, and variables
`figma_get_components`	None	Lists components on the current page

Export

Tool	Inputs	Description
`figma_export_node`	`nodeId`, optional `format`, `scale`, `outputPath`	Exports a node as `PNG`, `SVG`, or `PDF`, writes the file, and returns its path

The default export format is PNG and the default scale is 1. scale applies to PNG and PDF only; SVG export takes no scale constraint and ignores it.

The export is written to disk rather than returned as inline base64 — a modest PNG is hundreds of kilobytes of it, which is expensive for an AI client to carry in its context and unusable as an image. The tool returns the file path instead.

outputPath may be a full file path or a directory to write into. Without it the file lands in ./figma-exports/ relative to the working directory of the MCP client process; set FIGMA_BRIDGE_EXPORT_DIR to change that default. Generated file names combine the layer name with the node ID, for example hero-banner-5005-2330.svg.

SVG exports up to 16 KB are also returned inline as source, so an icon can be used without a second read. Larger SVGs are referenced by path only.

Editing

Tool	Inputs	Description
`figma_set_text`	`nodeId`, `text`	Replaces the content of a text node
`figma_set_fill`	`nodeId`, `hex`	Replaces a node's fills with one solid hex color
`figma_create_frame`	`name`, `width`, `height`, optional `x`, optional `y`	Creates a frame on the current page
`figma_create_text`	`text`, optional `x`, optional `y`, optional `fontSize`, optional `parentId`	Creates an Inter Regular text node on the current page or in a parent node
`figma_delete_node`	`nodeId`	Deletes a node
`figma_move_node`	`nodeId`, `x`, `y`	Changes a node's position
`figma_resize_node`	`nodeId`, `width`, `height`	Changes a node's dimensions

Advanced

Tool	Inputs	Description
`figma_run_js`	`code`	Runs JavaScript with access to the `figma` Plugin API object

figma_run_js is intended for operations not covered by the dedicated tools. The supplied code runs inside the Figma plugin sandbox and may modify the open document.

The snippet is wrapped in an async function before it runs, so await and return both work at the top level of the code you pass:

const node = figma.getNodeById("1:2");
await node.exportAsync({ format: "SVG" });
return node.name;

Running the Server Manually

Manual startup is useful for diagnostics, but is not required when your MCP client is configured to launch the server.

npm start

On Windows, you can also double-click start.bat.

Expected log output from a primary server:

[figma-bridge-mcp] Starting Figma Bridge MCP Server...
[figma-bridge-mcp] PRIMARY mode — listening at ws://localhost:3055
[figma-bridge-mcp] MCP stdio ready

If another Figma Bridge process already owns the port, the new process enters proxy mode. This is expected:

[figma-bridge-mcp] Port is in use; switching to proxy mode...
[figma-bridge-mcp] Connected to the primary server

Project Structure

figma-bridge-mcp/
├── plugin/
│   ├── code.js          # Commands executed in the Figma plugin sandbox
│   ├── ui.html          # Plugin UI and WebSocket client
│   └── manifest.json    # Figma development plugin manifest
├── server.js            # MCP stdio server and WebSocket bridge
├── start.bat            # Optional Windows launcher
├── package.json         # Node.js package metadata and scripts
└── README.md

The only runtime npm dependency is ws, which provides the WebSocket server and client implementation.

Troubleshooting

`No Figma plugin connected`

Use the Figma desktop app, not the browser version.
Open the Figma or FigJam file you want to work with.
Run Plugins → Development → Figma Bridge.
Keep the plugin window open.
Wait a few seconds for the plugin's automatic reconnect attempt.
Confirm that the plugin displays Connected to bridge ✓.

The plugin stays on `Connecting...`

Confirm that the MCP client has started server.js, or run npm start temporarily for diagnostics.
Confirm that port 3055 is not blocked by a firewall or security tool.
Check whether an unrelated application is already using port 3055.
Reload the plugin after the bridge server starts.

Windows Figma cannot reach the bridge running in WSL2

Confirm that the server is listening inside WSL:

ss -ltnp | grep 3055

Then test the forwarded port from Windows PowerShell:

Test-NetConnection localhost -Port 3055

If TcpTestSucceeded is False:

Confirm that you are using WSL2 with wsl --list --verbose in PowerShell.
Update WSL with wsl --update, then restart it with wsl --shutdown.
Restart the MCP client and rerun the Figma plugin.
Check whether a VPN, firewall, endpoint security tool, or unrelated process is blocking port 3055.
Confirm that Node.js and npm install were run inside WSL rather than only on Windows.

Do not replace the plugin URL with a WSL virtual-machine IP. Windows-to-WSL localhost forwarding is the intended connection path and avoids depending on an IP address that can change after WSL restarts.

The MCP server is not detected

Confirm that Node.js is available:
```
node --version
```
Confirm that dependencies are installed:
```
npm install
```
Use an absolute path to server.js.
Escape Windows backslashes correctly in JSON.
Restart or reload the MCP client after changing its configuration.
Check the MCP client's server logs for Node.js or path errors.

`Port is in use; switching to proxy mode...`

This message is normal when another Figma Bridge instance is already running. If the proxy cannot connect, stop the unrelated process using port 3055 or change the port consistently in server.js, plugin/ui.html, and plugin/manifest.json.

A command times out

Confirm that the plugin is still open and connected.
Confirm that the target document is still open in Figma.
Check that the node ID exists in the current document.
Retry the request after reconnecting the plugin. Bridge requests time out after 30 seconds.

Current Limitations

The bridge is designed for local use and uses the fixed WebSocket port 3055.
The Figma development plugin must remain open during a session.
Commands target the most recently connected plugin when multiple plugin windows are open.
figma_get_page returns the page's direct children rather than recursively expanding the entire document tree. Use figma_get_node for more detail.
Exports are written to disk by the MCP server process that received the call, so the file lands next to the client that asked for it rather than on the primary bridge.
There is no authentication layer between the local WebSocket server and plugin.

Security

Figma Bridge MCP is intended for local development. Do not expose port 3055 to untrusted networks. Only connect MCP clients you trust, and review commands before allowing them to modify important design files.

The figma_run_js tool can execute arbitrary JavaScript in the Figma plugin sandbox. It is powerful enough to inspect or modify the open document and should only be used with trusted prompts and trusted MCP clients.

Development

Install dependencies and start the server:

npm install
npm start

Changes to server.js require restarting the MCP server process. Changes to files under plugin/ require reloading or rerunning the development plugin in Figma.

License

This repository does not currently include a license. Add a LICENSE file before distributing or accepting third-party contributions.

Available Tools

16 tools

figma_create_frameC

Create a new frame on current page

ParametersJSON Schema

Name	Required	Description	Default
`x`	No
`y`	No
`name`	Yes
`width`	Yes
`height`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only states the basic purpose without disclosing behavioral traits like side effects, prerequisites (e.g., current page selection), constraints (e.g., duplicate names), or error conditions.

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?

Single sentence is concise and front-loaded, but it under-informs. Conciseness traded for completeness; minimal viable size for a simple tool.

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

Completeness2/5

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

No output schema, no behavioral details, and no parameter descriptions. For a creation tool, missing context on return value (e.g., node ID), potential conflicts, and required context (current page existence).

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

Parameters1/5

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

Schema description coverage is 0%, so description must explain parameters. It does not mention any parameter roles, valid ranges, or relationships (e.g., x,y for positioning). No added meaning beyond schema names.

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?

Description clearly states verb 'create', resource 'frame', and context 'on current page'. It distinguishes from sibling tools like figma_create_text by specifying the resource type.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. Siblings include creation, deletion, and modification tools, but description offers no context for selection.

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

figma_create_textD

Create a text node

ParametersJSON Schema

Name	Required	Description	Default
`x`	No
`y`	No
`text`	Yes
`fontSize`	No
`parentId`	No

TDQS

D1.8/5.0

Behavior2/5

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

No annotations exist, and the description does not disclose any behavioral traits (e.g., whether it replaces existing nodes, requires a parent, or side effects). 'Create a text node' implies insertion but lacks detail.

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

Conciseness2/5

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

The description is extremely concise at 4 words, but it under-specifies the tool. Conciseness should not come at the cost of missing critical information; here, brevity hurts usability.

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

Completeness1/5

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

Given the tool's complexity (5 parameters, no output schema, no annotations), the description is entirely insufficient. The agent has no idea what creating a 'text node' entails in Figma or how to use the parameters correctly.

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

Parameters1/5

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

The description provides zero parameter information. All five parameters are documented only in the schema, with 0% coverage in the description, requiring the agent to infer meaning from parameter names alone.

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

Purpose3/5

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

The description 'Create a text node' clearly states the action and resource, but lacks scope or differentiation from sibling tools like 'figma_set_text' which also deals with text nodes. It is specific but not distinctive.

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

Usage Guidelines1/5

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

No usage guidelines provided. The description does not indicate when to use this tool, prerequisites, or alternatives, leaving the agent without decision support.

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

figma_delete_nodeC

Delete a node by ID

ParametersJSON Schema

Name	Required	Description	Default
`nodeId`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

The description says 'delete' but does not disclose whether deletion is permanent, what happens to child nodes, or if any permissions are required. With no annotations, the description should compensate, but it omits critical behavioral details.

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?

The description is very concise, using a single sentence. However, for a simple delete operation, this brevity is acceptable and not wasteful. A bit more context would not hurt.

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

Completeness2/5

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

Given a single parameter and no output schema, the description is incomplete. It does not explain side effects, error conditions (e.g., node not found), or return value (presumably empty or success). More context is needed for reliable invocation.

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

Parameters2/5

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

The only parameter (nodeId) lacks description in the schema, and the tool description provides no additional meaning (e.g., expected format like UUID or node path). Schema coverage is 0%, but the description adds nothing beyond the schema.

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 the action ('delete') and the resource ('node'), which is precise within the Figma context. It distinguishes this tool from sibling tools like figma_create_frame or figma_move_node, as deletion is a unique operation.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives or when not to use it. There are no prerequisites, restrictions, or mentions of related tools (e.g., figma_get_node to verify existence before deletion).

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

figma_export_nodeC

Export a node as PNG/SVG (returns base64)

ParametersJSON Schema

Name	Required	Default
`scale`	No
`format`	No	PNG
`nodeId`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only notes base64 return, lacking details on side effects, permissions, error handling (e.g., missing node), or whether operation is read-only.

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

Conciseness2/5

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

Very short (1 sentence) but at the expense of missing important details like additional formats and parameter info. Conciseness should not sacrifice necessary clarity.

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

Completeness2/5

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

With 3 parameters, no output schema, and no annotations, the description is too minimal. It fails to explain scale, full format options, or output structure, making it inadequate for confident tool selection.

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

Parameters1/5

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

Schema coverage 0% and description adds no parameter explanations. Scale, format enum (including hidden PDF), and nodeId are not described. For 3 parameters, this is insufficient.

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?

Description clearly states 'Export a node' and specifies PNG/SVG formats and base64 output. However, it omits PDF (present in enum), which slightly reduces completeness. Differentiates from sibling tools like figma_get_node by emphasizing export/rendering.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs siblings (e.g., figma_get_node for properties vs export for images). The purpose is implied but not explicitly contrasted with alternatives.

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

figma_get_componentsB

Get all local components

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, permissions, or side effects. The tool likely performs a read operation, but this is not explicitly stated.

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?

The description is a single sentence with no unnecessary words, achieving high conciseness. However, it is so minimal that some context is sacrificed for brevity.

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

Completeness2/5

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

Given no output schema and no annotations, the description fails to explain the return format, scope (e.g., current document? page?), or examples. It is too incomplete for a tool that likely returns a list of components.

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?

There are no parameters, and schema coverage is 100%. The description does not need to add parameter-level detail, but it could clarify what 'local components' means. The baseline for zero parameters is 4, which is met.

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 uses a specific verb-resource pair ('Get all local components'), making the purpose clear. However, it does not distinguish from siblings like figma_get_styles or figma_get_variables, which are similar in structure. The term 'components' could be ambiguous without context.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It only states the action, leaving the agent to infer usage context from the name alone.

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

figma_get_nodeB

Get detailed info about a specific node by ID

ParametersJSON Schema

Name	Required	Description	Default
`nodeId`	Yes	Node ID (e.g. "1:2" or "1-2")

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must fully convey behavioral traits. It only states 'Get detailed info' without specifying what that entails (e.g., geometry, properties, children), permissions, rate limits, or whether it's read-only. More detail is needed for safe invocation.

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 a single sentence with no unnecessary words. It is concise and front-loaded with the action and resource.

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

Completeness2/5

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

The description lacks output details (no output schema). Given the complexity of Figma nodes, stating that it returns 'detailed info' is vague. More context about the response (e.g., 'returns node properties, children, geometry') would improve completeness.

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 baseline is 3. The description itself adds no additional meaning beyond the schema, but the schema already documents the nodeId parameter with examples. The tool description does not compensate beyond the schema.

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 the verb 'Get', the resource 'detailed info about a specific node', and the method 'by ID'. It effectively distinguishes from siblings like figma_get_page and figma_get_components.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives (e.g., figma_get_selection for selected nodes, figma_get_page for all nodes on a page). This omission may lead to suboptimal tool selection.

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

figma_get_pageA

Get all frames/nodes on the current page

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/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. It does not disclose behavioral traits such as whether all nested frames are returned, pagination limits, or any destructive actions. The tool name implies a read operation, but this is not explicitly stated.

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 a single, front-loaded sentence with no wasted words. It directly communicates the tool's purpose without redundancy.

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?

Given no output schema and no parameters, the description is adequate but fails to explain the return format (e.g., list of node IDs or full objects). The agent may be uncertain about the structure of the result.

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?

There are zero parameters, so the schema coverage is trivially 100%. The description does not need to add parameter semantics, achieving the baseline score of 4.

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 'Get all frames/nodes on the current page' uses a clear verb ('Get') and specifies the resource ('all frames/nodes on the current page'). It distinguishes itself from siblings like figma_get_node (single node) and figma_get_selection (selected nodes).

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not state prerequisites, when not to use, or mention related tools like figma_get_node for single nodes.

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

figma_get_selectionA

Get currently selected nodes in Figma

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It fails to disclose what happens when no selection exists (empty result vs. error) or whether the selection is live. The description is too minimal for a read operation.

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 a single, short sentence with no wasted words. It is perfectly concise and front-loaded.

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 parameterless tool with no output schema, the description is mostly complete. It could improve by noting behavior when no nodes are selected or indicating that multiple nodes may be returned. Still, it covers the core action adequately.

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?

The tool has zero parameters, so schema coverage is 100% trivially. The description adds value by specifying 'currently selected' which implies real-time state, but does not elaborate on return format or node identification.

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 'Get currently selected nodes in Figma,' which is a specific verb+resource. It distinguishes from siblings like figma_get_node (which retrieves a specific node by ID) by focusing on the user's current selection.

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 gives no guidance on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., a selection must exist) or when to use sibling tools like figma_get_node or figma_get_page.

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

figma_get_stylesB

Get all local styles (colors, text, effects)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description must carry full behavioral burden. It does not explicitly state that this is a read-only operation, nor does it mention potential side effects, return format, or access requirements. The word 'Get' implies read-only, but detailed transparency is lacking.

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?

The description is a single, concise sentence that is front-loaded. It is not verbose, but could benefit from slight expansion about return format or read-only nature. Still, it is efficient.

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?

Given no parameters, output schema, or annotations, the description covers the basic function. However, it omits context like return type (list of style objects) and whether it is a read operation. For a simple tool, it is minimally adequate.

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% (no parameters). The description adds no parameter information, but baseline is 3 due to high coverage. No additional value beyond schema.

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?

Description clearly states the tool gets all local styles and specifies the types (colors, text, effects), making the purpose highly specific. It effectively distinguishes from siblings like figma_get_components and figma_get_variables.

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 usage is implied: use when you need local styles. However, no explicit when-not or alternatives are mentioned, and sibling tools are not compared.

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

figma_get_variablesA

Get all local variables and variable collections

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states the basic read operation without disclosing any behavioral traits (e.g., what happens if no variables, whether it returns all collections, side effects, or permissions needed).

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?

The description is a single, concise sentence with no fluff. It is appropriately sized for a zero-parameter tool, though it could be slightly more informative about what constitutes 'local variables'.

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?

Given the absence of an output schema and annotations, the description is minimal. It does not describe the return format or structure, leaving the agent to infer the response. For a tool with no parameters, it is adequate but not complete.

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?

There are zero parameters, and the schema description coverage is 100%. With no parameters, the description does not need to add param semantics, and the baseline score of 4 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 'Get all local variables and variable collections', with a specific verb ('Get') and resource ('local variables and variable collections'), distinguishing it from sibling tools like figma_get_components or figma_get_styles.

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?

No explicit guidance on when to use this tool vs alternatives like figma_get_components or figma_get_styles. The purpose is implied, but no when-to-use or when-not-to-use context is provided.

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

figma_move_nodeC

Move a node to new x,y position

ParametersJSON Schema

Name	Required	Description	Default
`x`	Yes
`y`	Yes
`nodeId`	Yes

TDQS

C2.3/5.0

Behavior2/5

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

No behavioral traits disclosed beyond the implied mutation. No mention of side effects, authorization needs, undoability, or return values. Description carries the full burden due to absent annotations.

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

Conciseness2/5

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

Extremely short (one sentence) but under-specified. Being concise is positive, but the content is too minimal to be useful; lacks structure and essential details.

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

Completeness1/5

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

Given the sibling tools and lack of output schema, the description is grossly incomplete. No info on coordinates system, error handling, return value, or usage constraints. Inadequate for an agent to invoke correctly.

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

Parameters1/5

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

Schema coverage is 0% for parameter descriptions. The description only reiterates 'new x,y position' without clarifying coordinate meaning (absolute/relative, units) or the role of nodeId. Fails to add value beyond schema.

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 clearly states the verb 'move' and the resource 'node', specifying the action to new x,y coordinates. It distinguishes from siblings like figma_resize_node or figma_create_frame, but lacks specificity on the coordinate system or units.

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

Usage Guidelines2/5

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

No guidance provided on when to use this tool versus alternatives (e.g., figma_resize_node does not move) or prerequisites (e.g., node must exist, must be on a page). Missing explicit context for selection.

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

figma_resize_nodeC

Resize a node

ParametersJSON Schema

Name	Required	Description	Default
`width`	Yes
`height`	Yes
`nodeId`	Yes

TDQS

C2.1/5.0

Behavior1/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as whether the operation is reversible, requires permissions, or triggers side effects.

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

Conciseness2/5

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

The description is extremely concise at 3 words, but this brevity comes at the cost of missing critical information. It is not appropriately sized for the tool's complexity.

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

Completeness1/5

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

Given the lack of annotations and output schema, and the need to document three parameters, the description is wholly insufficient for an agent to use the tool correctly.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no meaning to the parameters (nodeId, width, height). It does not explain units, valid ranges, or how parameters affect the resize operation.

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 'Resize a node' uses a specific verb and resource, clearly indicating the action. It is distinct from sibling tools like figma_move_node or figma_set_fill, though it does not explicitly differentiate them.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. There is no context about prerequisites, constraints, or typical use cases.

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

figma_run_jsC

Run arbitrary Figma Plugin API JavaScript code (advanced)

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only states that code is run, but does not mention safety, permissions, side effects, or execution context (e.g., sandboxing). This is insufficient for a code execution tool.

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?

The description is a single concise sentence with no extraneous information. It is front-loaded and efficient, though it could benefit from additional context without becoming verbose.

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

Completeness2/5

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

Given the complexity of running arbitrary code and the absence of an output schema, the description is minimal. It does not explain return values, error handling, or limitations, leaving the agent with insufficient information to use the tool effectively.

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

Parameters2/5

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

With 0% schema description coverage, the description must add meaning to the 'code' parameter. It mentions it is JavaScript code, but provides no syntax, examples, return value, or constraints. This does not adequately compensate for the lack of schema descriptions.

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 the tool runs arbitrary Figma Plugin API JavaScript code, which is a specific action. It distinguishes itself from sibling tools that perform specific operations like creating frames or getting nodes.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. While it's implied for cases not covered by sibling tools, there are no explicit conditions, prerequisites, or exclusions.

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

figma_set_fillC

Change fill color of a node (hex color)

ParametersJSON Schema

Name	Required	Description	Default
`hex`	Yes	Hex color e.g. "#FF0000"
`nodeId`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are present, so the description carries full burden. It indicates a write operation ('change') but does not disclose whether it overwrites existing fills, works on all node types, or is reversible. Missing behavioral context for a mutation tool.

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?

The description is a single sentence, which is concise but lacks structure. It could be expanded to include usage guidance without becoming verbose. The brevity leads to omissions.

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

Completeness2/5

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

Given the low schema coverage, no annotations, and no output schema, the description should provide more context. It does not specify the effect on multiple fills, error conditions, or return value, making it incomplete for practical use.

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

Parameters2/5

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

Schema description coverage is 50% (nodeId lacks description). The description only mentions hex color format, which is already in the schema. It does not explain what nodeId represents or how to obtain it, leaving a gap.

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 clearly states the action ('Change fill color') and the resource ('a node') with the hex format specified. It distinguishes from sibling tools that handle different operations (create, delete, move, etc.), but does not explicitly differentiate from other color-related modifications.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., node exists, is selected) or exclusions (e.g., for text nodes use figma_set_text).

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

figma_set_textB

Change text content of a text node

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`nodeId`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided; description only states the action (change text) without disclosing side effects, reversibility, or what happens on success/failure.

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?

Single sentence, no extraneous words, perfectly concise.

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

Completeness2/5

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

Given no output schema and no annotations, description fails to explain return values, success/failure indicators, or any constraints (e.g., max text length). Requires significant inference from the agent.

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

Parameters1/5

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

Schema description coverage is 0% and description adds no meaning to parameters beyond their names (nodeId, text). No guidance on format, constraints, or where to get nodeId.

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?

Description uses specific verb 'change' and resource 'text content of a text node', clearly distinguishing from siblings like figma_create_text (create new) and figma_get_node (read).

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?

No explicit when-to-use or when-not-to-use guidance, but intent is obvious from name and description. Lacks alternatives or prerequisites.

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

figma_statusA

Check if Figma plugin is connected

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states the basic purpose without disclosing the return value, error behavior, or side effects. For a status check, minimal behavioral information is given.

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 a single sentence that directly states the purpose with no unnecessary words. It is front-loaded and efficiently conveys the tool's function.

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?

Given the simplicity (no parameters, no output schema, no annotations), the description is minimal. It would benefit from specifying what the tool returns (e.g., true/false for connectivity) to fully inform the agent. Currently adequate but not complete.

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?

The tool has zero parameters, and schema coverage is 100% trivially. According to rubric, 0 parameters yields a baseline of 4. No additional parameter info is needed.

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 'Check if Figma plugin is connected' uses a specific verb and resource, clearly indicating a status check. It distinguishes itself from siblings, which are all about creating, modifying, or retrieving Figma objects.

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 does not explicitly state when to use this tool versus alternatives. It implies usage for verifying connectivity before other Figma operations, but lacks explicit when-not or alternative guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

16 tool updatesv1.0.0Jul 14, 2026
- First observedfigma_create_frame
- First observedfigma_create_text
- First observedfigma_delete_node
- First observedfigma_export_node
- First observedfigma_get_components
- First observedfigma_get_node
- First observedfigma_get_page
- First observedfigma_get_selection
- First observedfigma_get_styles
- First observedfigma_get_variables
- First observedfigma_move_node
- First observedfigma_resize_node
- First observedfigma_run_js
- First observedfigma_set_fill
- First observedfigma_set_text
- First observedfigma_status

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0

Disambiguation5/5

Each tool targets a distinct action on a specific resource (e.g., create_frame vs. create_text, get_node vs. get_page). There is no obvious overlap or ambiguity between tools.

Naming Consistency5/5

All tools follow the consistent pattern of `figma_verb_noun` (e.g., figma_create_frame, figma_delete_node, figma_get_selection). No mixing of styles or irregular names.

Tool Count5/5

With 16 tools, the server covers a broad range of operations without being overwhelming. The count aligns well with the scope of a Figma bridge.

Completeness4/5

The tool surface covers creation, deletion, manipulation (move, resize, fill), reading (node, page, styles, variables), export, and advanced JS execution. Minor gaps like setting strokes or effects are present, but core workflows are well-supported.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Figma MCP ServerOAuth
com.figma.mcp
The Figma MCP server brings Figma design context directly into your AI workflow.
Developer Tools Content Management Systems
31,960
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
slimaOAuth
io.github.slima-ai
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
Developer Tools
21

Related MCP Servers

figma-opencode-mcp
Design Tools Developer Tools
laivannha0202
A
license
A
quality
D
maintenance
Local-first MCP server that connects AI coding agents to the currently open Figma file through a local plugin bridge, requiring no Figma API token.
Updated 3 months ago (2026-06-12 15:25 UTC)
8
MIT
Figma Native MCP
Design Tools Developer Tools
tomasmarekk
A
license
Not graded
quality
C
maintenance
A local MCP server that lets MCP clients inspect and edit the Figma document currently open in the Figma desktop app using a local bridge and development plugin.
Updated 2 months ago (2026-07-16 09:47 UTC)
MIT
figma-mcp-rust
Design Tools Developer Tools
alvinindra
A
license
Not graded
quality
A
maintenance
An MCP server that enables AI tools to read and write Figma designs via a plugin bridge, bypassing the Figma REST API and rate limits.
Updated 18 days ago (2026-08-19 10:34 UTC)
31
MIT
figma-meta-mcp
Design Tools Code Execution
shinjiyu
A
license
A
quality
C
maintenance
Figma MCP server that lets agents execute arbitrary JavaScript inside a running Figma desktop app via a local development plugin, enabling real-time document inspection and manipulation while avoiding REST API rate limits.
Updated a month ago (2026-08-05 10:30 UTC)
3
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Halil-KAPLAN/figma-bridge-mcp'

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

Figma Bridge MCP

Plugin Preview

Features

How It Works

Requirements

Installation

Windows and WSL2 Support

How the WSL2 connection works

Native Windows setup

WSL2 setup

Keep the agent and MCP server in the same environment

Use Figma Bridge MCP in Figma

Install the plugin once

Run the plugin for each session

Let an AI agent use Figma through MCP

Add Figma Bridge MCP to an AI Application

Codex CLI and Codex IDE extension

Codex running on Windows

Codex running in WSL2

Claude Code CLI and VS Code extension

Claude Code running on Windows

Claude Code running in WSL2

VS Code .vscode/mcp.json

Other terminal and desktop AI clients

Use It with an AI Agent

Available MCP Tools

Connection and inspection

Export

Editing

Advanced

Running the Server Manually

Project Structure

Troubleshooting

No Figma plugin connected

The plugin stays on Connecting...

Windows Figma cannot reach the bridge running in WSL2

The MCP server is not detected

Port is in use; switching to proxy mode...

A command times out

Current Limitations

Security

Development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

VS Code `.vscode/mcp.json`

`No Figma plugin connected`

The plugin stays on `Connecting...`

`Port is in use; switching to proxy mode...`