de en es ja ko zh

Figma Bridge MCP

Name: Figma Bridge MCP
Author: Halil-KAPLAN

by Halil-KAPLAN

Overview Schema Related Servers Score Discussions

JavaScript

Local

Figma Bridge MCP

Figma Bridge MCP es un servidor local del Model Context Protocol (MCP) que conecta clientes de IA compatibles con MCP a la aplicación de escritorio de Figma. Permite que un asistente de IA inspeccione el documento actual de Figma o FigJam, exporte nodos y realice cambios controlados a través de la API de plugins de Figma.

Vista previa del plugin

Plugin de Figma Bridge mostrando una conexión activa

La ventana del plugin muestra el estado de la conexión del puente, los eventos de conexión recientes y un botón de reconexión manual. Mantén esta ventana abierta mientras tu cliente MCP trabaja con Figma.

Related MCP server: Figma Native MCP

Características

Inspecciona la página actual, las capas seleccionadas, los nodos individuales, los estilos locales, las variables y los componentes.
Exporta nodos de Figma como PNG, SVG o PDF directamente al disco.
Actualiza el texto y los colores de relleno sólido.
Crea, mueve, redimensiona y elimina nodos.
Ejecuta JavaScript avanzado a través de la API de plugins de Figma.
Usa IDs de nodo copiados de las URL de Figma en formato 1:23 o 1-23.
Conecta múltiples procesos de clientes MCP a través de un servidor puente local compartido.
Usa la aplicación de escritorio de Figma para Windows desde agentes de IA que se ejecutan de forma nativa en Windows o dentro de WSL2.
Trabaja con cualquier cliente MCP que admita servidores stdio, incluidos Codex, Claude Code y los clientes MCP de VS Code.

Cómo funciona

┌──────────────────────────────┐
│ 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    │
└──────────────────────────────┘

El primer proceso server.js que adquiere el puerto 3055 se convierte en el puente principal. Si otro cliente MCP inicia otra instancia, ese proceso automáticamente entra en modo proxy y reenvía sus comandos al puente principal. Cuando hay varios plugins de Figma conectados, los comandos se envían al plugin conectado más recientemente.

Requisitos

Node.js y npm. Se recomienda la versión LTS actual de Node.js.
La aplicación de escritorio de Figma.
Un cliente MCP con soporte para servidores stdio.

Instala Node.js en el mismo entorno donde el cliente de IA lanzará el servidor MCP: instala Node.js de Windows para clientes nativos de Windows o Node.js de Linux dentro de WSL para clientes WSL. El servidor en sí es independiente de la plataforma. start.bat se incluye solo como un ayudante opcional para Windows.

Instalación

Clona este repositorio e instala su dependencia:

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

También puedes descargar el repositorio como archivo ZIP, extraerlo, abrir una terminal en el directorio extraído y ejecutar npm install.

Soporte para Windows y WSL2

Figma Bridge MCP admite tanto el desarrollo nativo de Windows como el desarrollo con WSL2. Figma siempre se ejecuta como la aplicación de escritorio de Windows; el servidor MCP se ejecuta en el mismo entorno que el agente de IA que lo lanza.

Entorno de desarrollo	Dónde se ejecutan Node.js y este repositorio	Ruta utilizada en la configuración de MCP	Aplicación de Figma
Windows nativo	Windows	`C:\ruta\a\figma-bridge-mcp\server.js`	Figma Desktop para Windows
Terminal WSL2	Linux WSL2	`/home/usuario/figma-bridge-mcp/server.js`	Figma Desktop para Windows
VS Code abierto normalmente en Windows	Windows, a menos que el agente esté configurado explícitamente para usar WSL	Ruta de Windows	Figma Desktop para Windows
VS Code Remote - WSL	Linux WSL2	Ruta de Linux WSL	Figma Desktop para Windows

Cómo funciona la conexión WSL2

Cuando server.js se ejecuta dentro de WSL2, abre el puente WebSocket en el puerto 3055. Windows reenvía las aplicaciones de red de WSL a localhost, por lo que el plugin de Figma para Windows aún puede conectarse a:

ws://localhost:3055

El flujo completo de WSL es:

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 documenta el acceso de Windows a WSL a través de localhost en Acceso a aplicaciones de red con WSL.

Configuración nativa de Windows

Usa un repositorio almacenado en el sistema de archivos de Windows e instala las dependencias con Node.js de Windows:

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

El comando MCP debe usar la copia de Node.js de Windows y una ruta de Windows a server.js.

Configuración de WSL2

Para el desarrollo con WSL, mantén el repositorio en el sistema de archivos de Linux e instala las dependencias dentro de WSL:

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

Abre el proyecto WSL en VS Code con:

code .

Confirma que VS Code muestra WSL: <distribución> en el indicador de estado remoto y que su terminal integrada usa rutas como /home/usuario/.... Consulta el tutorial de WSL de VS Code para el flujo de trabajo Remote - WSL.

Mientras el puente se ejecuta en WSL, puedes probar el acceso desde Windows con:

Test-NetConnection localhost -Port 3055

TcpTestSucceeded debe ser True.

Mantén el agente y el servidor MCP en el mismo entorno

El comando node y la ruta de server.js se resuelven en el entorno donde se ejecuta el agente de IA:

Un agente nativo de Windows necesita Node.js de Windows y una ruta de Windows.
Un agente que se ejecuta en WSL necesita Node.js instalado en WSL y una ruta de Linux.
Una ventana de VS Code Remote - WSL debe configurar el servidor MCP desde su terminal integrada de WSL.
No uses una ruta C:\... en una configuración de MCP de WSL ni una ruta /home/... en una configuración de MCP nativa de Windows.

Para un comportamiento más predecible, usa una instalación canónica por entorno y configura todos los agentes en ese entorno para que lancen el mismo archivo server.js. Se admiten múltiples procesos MCP en el mismo entorno: el primero se convierte en el puente principal y los procesos posteriores se conectan automáticamente a través de él.

Usa Figma Bridge MCP en Figma

Figma Bridge MCP incluye un plugin de desarrollo local de Figma. No es necesario instalarlo desde la comunidad de Figma. El plugin se ejecuta dentro del documento abierto de Figma o FigJam y retransmite los comandos MCP entre el servidor puente local y la API de plugins de Figma.

Instala el plugin una vez

Los plugins de desarrollo deben importarse con la aplicación de escritorio de Figma:

Abre la aplicación de escritorio de Figma en macOS o Windows.
Crea o abre cualquier archivo de Figma Design o FigJam.
Abre el menú de Figma en la esquina superior izquierda.
Selecciona Plugins → Development → Import new plugin from manifest....
Navega hasta este repositorio y selecciona plugin/manifest.json.
Figma agrega Figma Bridge a la sección Development del menú de Plugins.

El manifest solo necesita importarse una vez en cada computadora. Consulta la guía de plugins de desarrollo de Figma para obtener más información sobre cómo importar plugins locales.

Ejecuta el plugin en cada sesión

Abre el archivo de Figma Design o FigJam que deseas que el agente de IA inspeccione o edite.
Inicia o recarga tu cliente MCP configurado. Normalmente lanzará server.js automáticamente. Puedes ejecutar npm start manualmente para diagnósticos.
En Figma, selecciona Plugins → Development → Figma Bridge.
Mantén la ventana del plugin abierta mientras el agente de IA usa Figma.
Espera hasta que el plugin muestre Connected to bridge ✓.

El plugin se conecta a ws://localhost:3055. Si el servidor MCP aún no se está ejecutando, el plugin permanece en Connecting... y reintenta automáticamente. Por lo tanto, puedes iniciar el plugin de Figma o el cliente MCP primero.

El documento abierto es el objetivo activo. Si cambias de documento, ejecuta el plugin en el documento que deseas que use el agente. Comandos como figma_get_selection operan en las capas seleccionadas actualmente en ese documento.

Permite que un agente de IA use Figma a través de MCP

Después de que el plugin muestre Connected to bridge ✓, cualquier agente de IA configurado que admita servidores MCP stdio puede descubrir y llamar a las herramientas de Figma Bridge MCP. El agente no se conecta directamente a tu cuenta de Figma y no requiere un token de acceso de Figma. Las solicitudes siguen esta ruta:

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

El plugin ejecuta la operación solicitada a través de la API de plugins de Figma y devuelve el resultado al agente a través de la misma conexión. El agente puede entonces inspeccionar el resultado, continuar con otra herramienta o explicar los cambios que realizó.

Agrega Figma Bridge MCP a una aplicación de IA

Figma Bridge MCP es un servidor MCP stdio local. La aplicación de IA lo lanza con este comando:

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

La ruta debe ser válida en el entorno donde se ejecuta la aplicación de IA. Normalmente no necesitas ejecutar npm start por separado porque el cliente MCP inicia y gestiona server.js por sí mismo.

Codex CLI y extensión de Codex IDE

Codex ejecutándose en Windows

Ejecuta este comando en PowerShell o en la terminal de Windows de VS Code:

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

Codex ejecutándose en WSL2

Ejecuta este comando en la terminal de WSL o en la terminal integrada de VS Code Remote - WSL:

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

Verifica la configuración:

codex mcp list

Dentro de Codex, usa /mcp para inspeccionar el servidor conectado y sus herramientas. Codex CLI y la extensión de Codex IDE comparten config.toml cuando se ejecutan en el mismo host, por lo que agregar el servidor desde la terminal también lo hace disponible para la extensión en ese entorno.

La configuración equivalente de Codex es:

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

En Windows, la extensión de Codex IDE también puede ejecutar Codex dentro de WSL habilitando esta configuración de VS Code:

"chatgpt.runCodexInWindowsSubsystemForLinux": true

Cuando esa configuración está habilitada, instala Node.js y Figma Bridge MCP dentro de WSL y usa la ruta de WSL en la configuración de MCP de Codex. En una ventana de VS Code Remote - WSL, Codex ya se ejecuta con el entorno del proyecto WSL.

Consulta la documentación oficial de MCP de Codex para la configuración de MCP y la documentación de WSL de Codex para el flujo de trabajo de WSL.

Claude Code CLI y extensión de VS Code

Los servidores MCP de Claude Code se agregan de manera más confiable desde una terminal. La extensión de VS Code puede entonces gestionar y usar el servidor configurado.

Claude Code ejecutándose en Windows

Ejecuta este comando en PowerShell o en la terminal de Windows de VS Code:

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

Claude Code ejecutándose en WSL2

Ejecuta este comando en la terminal de WSL o en la terminal integrada de VS Code Remote - WSL:

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

Verifica la configuración:

claude mcp list

En Claude Code CLI o en el panel de chat de VS Code, usa /mcp para ver la conexión y las herramientas disponibles. Cuando VS Code está conectado a través de Remote - WSL, ejecuta claude mcp add desde la terminal integrada de WSL para que el comando y la ruta de Linux se almacenen en la configuración de Claude Code de WSL.

Consulta la documentación oficial de MCP de Claude Code y la documentación de VS Code de Claude Code.

`.vscode/mcp.json` de VS Code

Algunos clientes MCP de VS Code leen los servidores del espacio de trabajo desde .vscode/mcp.json. Usa la configuración que coincida con el host de la extensión.

VS Code nativo de Windows:

{
  "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"]
    }
  }
}

Otros clientes de IA de terminal y escritorio

Cualquier cliente de IA que admita servidores MCP stdio locales puede usar Figma Bridge MCP. Busca una configuración de MCP Servers, Tools o Integrations y agrega un servidor con:

Nombre: figma-bridge-mcp
Transporte: stdio
Comando: node
Argumentos: la ruta absoluta a server.js

Un formato JSON común es:

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

El nombre exacto del archivo de configuración y la clave de nivel superior (mcpServers o servers) dependen del cliente. Las aplicaciones de terminal siguen la misma regla de entorno: usa una ruta de Windows cuando la aplicación se ejecuta en Windows y una ruta de Linux cuando se ejecuta en WSL.

Úsalo con un agente de IA

Después de instalar el plugin de Figma y configurar tu cliente MCP:

Abre el documento de destino en la aplicación de escritorio de Figma.
Ejecuta Plugins → Development → Figma Bridge y mantén su ventana abierta.
Inicia o recarga el agente de IA para que lance el servidor MCP y descubra sus herramientas.
Pide al agente que verifique la conexión. Debería llamar a figma_status e informar que el plugin está conectado.
Pide al agente que inspeccione o modifique el documento abierto usando lenguaje natural.

Por ejemplo:

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.

Cuando un ID de nodo proviene de una URL de Figma como node-id=2057-6604, puedes pasar 2057-6604 o 2057:6604 al puente.

El agente de IA decide qué herramientas MCP llamar según tu solicitud. También puedes nombrar explícitamente una herramienta cuando necesites una operación concreta, como figma_get_selection, figma_export_node o figma_set_text.

Herramientas MCP disponibles

Conexión e inspección

Herramienta	Entradas	Descripción
`figma_status`	Ninguna	Informa si un plugin de Figma está conectado
`figma_get_page`	Ninguna	Devuelve la página actual y sus hijos directos
`figma_get_node`	`nodeId`	Devuelve las propiedades de un nodo y sus hijos directos
`figma_get_selection`	Ninguna	Devuelve información detallada sobre los nodos seleccionados
`figma_get_styles`	Ninguna	Enumera los estilos locales de relleno, texto y efectos
`figma_get_variables`	Ninguna	Enumera las colecciones, modos y variables de variables locales
`figma_get_components`	Ninguna	Enumera los componentes de la página actual

Exportación

Herramienta	Entradas	Descripción
`figma_export_node`	`nodeId`, opcional `format`, `scale`, `outputPath`	Exporta un nodo como `PNG`, `SVG` o `PDF`, escribe el archivo y devuelve su ruta

El formato de exportación predeterminado es PNG y la escala predeterminada es 1. scale se aplica solo a PNG y PDF; la exportación SVG no admite restricción de escala y la ignora.

La exportación se escribe en disco en lugar de devolverse como base64 en línea: un PNG modesto supone cientos de kilobytes de base64, lo que resulta costoso para que un cliente de IA lo lleve en su contexto e inutilizable como imagen. La herramienta devuelve la ruta del archivo en su lugar.

outputPath puede ser una ruta de archivo completa o un directorio en el que escribir. Sin él, el archivo se guarda en ./figma-exports/ relativo al directorio de trabajo del proceso del cliente MCP; define FIGMA_BRIDGE_EXPORT_DIR para cambiar ese valor predeterminado. Los nombres de archivo generados combinan el nombre de la capa con el ID del nodo, por ejemplo hero-banner-5005-2330.svg.

Las exportaciones SVG de hasta 16 KB también se devuelven en línea como código fuente, de modo que un icono puede usarse sin una segunda lectura. Los SVG más grandes se referencian solo por ruta.

Edición

Herramienta	Entradas	Descripción
`figma_set_text`	`nodeId`, `text`	Reemplaza el contenido de un nodo de texto
`figma_set_fill`	`nodeId`, `hex`	Reemplaza los rellenos de un nodo con un color hexadecimal sólido
`figma_create_frame`	`name`, `width`, `height`, opcional `x`, opcional `y`	Crea un marco en la página actual
`figma_create_text`	`text`, opcional `x`, opcional `y`, opcional `fontSize`, opcional `parentId`	Crea un nodo de texto Inter Regular en la página actual o en un nodo padre
`figma_delete_node`	`nodeId`	Elimina un nodo
`figma_move_node`	`nodeId`, `x`, `y`	Cambia la posición de un nodo
`figma_resize_node`	`nodeId`, `width`, `height`	Cambia las dimensiones de un nodo

Avanzado

Herramienta	Entradas	Descripción
`figma_run_js`	`code`	Ejecuta JavaScript con acceso al objeto `figma` de la API del plugin

figma_run_js está pensado para operaciones no cubiertas por las herramientas dedicadas. El código proporcionado se ejecuta dentro del sandbox del plugin de Figma y puede modificar el documento abierto.

El fragmento se envuelve en una función asíncrona antes de ejecutarse, por lo que await y return funcionan ambos en el nivel superior del código que pasas:

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

Ejecutar el servidor manualmente

El inicio manual es útil para diagnósticos, pero no es necesario cuando tu cliente MCP está configurado para lanzar el servidor.

npm start

En Windows, también puedes hacer doble clic en start.bat.

Salida de registro esperada de un servidor principal:

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

Si otro proceso de Figma Bridge ya posee el puerto, el nuevo proceso entra en modo proxy. Esto es lo esperado:

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

Estructura del proyecto

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

La única dependencia npm en tiempo de ejecución es ws, que proporciona la implementación del servidor y cliente WebSocket.

Solución de problemas

`No Figma plugin connected`

Usa la aplicación de escritorio de Figma, no la versión de navegador.
Abre el archivo de Figma o FigJam con el que quieras trabajar.
Ejecuta Plugins → Development → Figma Bridge.
Mantén abierta la ventana del plugin.
Espera unos segundos al intento de reconexión automática del plugin.
Confirma que el plugin muestra Connected to bridge ✓.

El plugin se queda en `Connecting...`

Confirma que el cliente MCP ha iniciado server.js, o ejecuta npm start temporalmente para diagnósticos.
Confirma que el puerto 3055 no está bloqueado por un firewall o una herramienta de seguridad.
Comprueba si una aplicación no relacionada ya está usando el puerto 3055.
Recarga el plugin después de que el servidor del puente se inicie.

Figma en Windows no puede alcanzar el puente que se ejecuta en WSL2

Confirma que el servidor está escuchando dentro de WSL:

ss -ltnp | grep 3055

Luego prueba el puerto reenviado desde PowerShell de Windows:

Test-NetConnection localhost -Port 3055

Si TcpTestSucceeded es False:

Confirma que estás usando WSL2 con wsl --list --verbose en PowerShell.
Actualiza WSL con wsl --update y luego reinícialo con wsl --shutdown.
Reinicia el cliente MCP y vuelve a ejecutar el plugin de Figma.
Comprueba si una VPN, un firewall, una herramienta de seguridad de puntos finales o un proceso no relacionado está bloqueando el puerto 3055.
Confirma que Node.js y npm install se ejecutaron dentro de WSL y no solo en Windows.

No reemplaces la URL del plugin con una IP de máquina virtual de WSL. El reenvío de localhost de Windows a WSL es la ruta de conexión prevista y evita depender de una IP que puede cambiar después de reiniciar WSL.

El servidor MCP no se detecta

Confirma que Node.js está disponible:
```
node --version
```
Confirma que las dependencias están instaladas:
```
npm install
```
Usa una ruta absoluta a server.js.
Escapa correctamente las barras invertidas de Windows en JSON.
Reinicia o recarga el cliente MCP después de cambiar su configuración.
Revisa los registros del servidor del cliente MCP en busca de errores de Node.js o de ruta.

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

Este mensaje es normal cuando otra instancia de Figma Bridge ya está en ejecución. Si el proxy no puede conectarse, detén el proceso no relacionado que usa el puerto 3055 o cambia el puerto de forma coherente en server.js, plugin/ui.html y plugin/manifest.json.

Un comando agota el tiempo de espera

Confirma que el plugin sigue abierto y conectado.
Confirma que el documento de destino sigue abierto en Figma.
Comprueba que el ID del nodo existe en el documento actual.
Reintenta la solicitud después de reconectar el plugin. Las solicitudes del puente agotan el tiempo de espera después de 30 segundos.

Limitaciones actuales

El puente está diseñado para uso local y usa el puerto WebSocket fijo 3055.
El plugin de desarrollo de Figma debe permanecer abierto durante una sesión.
Los comandos se dirigen al plugin conectado más recientemente cuando hay varias ventanas de plugin abiertas.
figma_get_page devuelve los hijos directos de la página en lugar de expandir recursivamente todo el árbol del documento. Usa figma_get_node para más detalle.
Las exportaciones las escribe en disco el proceso del servidor MCP que recibió la llamada, por lo que el archivo se guarda junto al cliente que lo solicitó y no en el puente principal.
No hay capa de autenticación entre el servidor WebSocket local y el plugin.

Seguridad

Figma Bridge MCP está pensado para desarrollo local. No expongas el puerto 3055 a redes no confiables. Conecta únicamente clientes MCP en los que confíes y revisa los comandos antes de permitir que modifiquen archivos de diseño importantes.

La herramienta figma_run_js puede ejecutar JavaScript arbitrario en el sandbox del plugin de Figma. Es lo bastante potente como para inspeccionar o modificar el documento abierto y solo debe usarse con indicaciones y clientes MCP de confianza.

Desarrollo

Instala las dependencias e inicia el servidor:

npm install
npm start

Los cambios en server.js requieren reiniciar el proceso del servidor MCP. Los cambios en los archivos de plugin/ requieren recargar o volver a ejecutar el plugin de desarrollo en Figma.

Licencia

Este repositorio no incluye actualmente una licencia. Añade un archivo LICENSE antes de distribuir o aceptar contribuciones de terceros.

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 19 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

Vista previa del plugin

Características

Cómo funciona

Requisitos

Instalación

Soporte para Windows y WSL2

Cómo funciona la conexión WSL2

Configuración nativa de Windows

Configuración de WSL2

Mantén el agente y el servidor MCP en el mismo entorno

Usa Figma Bridge MCP en Figma

Instala el plugin una vez

Ejecuta el plugin en cada sesión

Permite que un agente de IA use Figma a través de MCP

Agrega Figma Bridge MCP a una aplicación de IA

Codex CLI y extensión de Codex IDE

Codex ejecutándose en Windows

Codex ejecutándose en WSL2

Claude Code CLI y extensión de VS Code

Claude Code ejecutándose en Windows

Claude Code ejecutándose en WSL2

.vscode/mcp.json de VS Code

Otros clientes de IA de terminal y escritorio

Úsalo con un agente de IA

Herramientas MCP disponibles

Conexión e inspección

Exportación

Edición

Avanzado

Ejecutar el servidor manualmente

Estructura del proyecto

Solución de problemas

No Figma plugin connected

El plugin se queda en Connecting...

Figma en Windows no puede alcanzar el puente que se ejecuta en WSL2

El servidor MCP no se detecta

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

Un comando agota el tiempo de espera

Limitaciones actuales

Seguridad

Desarrollo

Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`.vscode/mcp.json` de VS Code

`No Figma plugin connected`

El plugin se queda en `Connecting...`

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