Which integrations are available for this server?

Allows AI agents to programmatically create, modify, and manage Figma design elements, including frames, shapes, text, styling, effects, layout, components, boolean operations, and export.

How do I use Figma MCP Write Bridge?

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 MCP Write Bridge Create a 200x300 rectangle named 'Card' with blue fill" 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.

Figma MCP Write Bridge

by firasmj

Overview Schema Related Servers Score Discussions

TypeScript

Local

Figma MCP Write Bridge

A Model Context Protocol (MCP) server that enables AI coding agents to manipulate Figma documents programmatically through a WebSocket bridge and Figma plugin.

Overview

This project provides a local MCP server that exposes write/manipulation tools for running Figma documents. It allows AI assistants and LLMs to create, modify, and manage Figma design elements programmatically via a lightweight plugin bridge.

Architecture

AI Client (VS Code) ←→ MCP Server (stdio) ←→ WebSocket Bridge ←→ Figma Plugin

MCP Server (server.ts): Runs locally and exposes tools via the Model Context Protocol over stdio
WebSocket Bridge: Enables communication between the server and Figma plugin
Figma Plugin: Executes Figma API operations and returns results

Related MCP server: Figma MCP Server

Features

Node Creation

Create frames, rectangles, ellipses, lines, polygons, and stars
Add text with customizable fonts and styling
Place images from base64-encoded data

Node Management

Find and select nodes by name or type
Rename, delete, duplicate nodes
Resize and rotate elements
Position nodes precisely
Group and ungroup nodes

Styling & Effects

Set fills and strokes with hex color support
Configure corner radius, opacity, and blend modes
Add drop shadows, inner shadows, and blur effects
Manage layout grids

Layout

Configure Auto Layout
Set child constraints
Control spacing and alignment

Text Manipulation

Edit text content
Apply text styles (font family, size, weight, spacing)
Set text colors

Components & Boolean Operations

Create components and instances
Detach instances
Perform boolean operations (union, subtract, intersect, exclude)

Data & Export

Export nodes as PNG, JPG, or SVG
Manage plugin data (JSON storage)
Batch apply properties to multiple nodes

Installation

Prerequisites

Node.js 18+ installed
Figma desktop app or browser access
An MCP-compatible AI client (e.g., VS Code with Copilot)

Setup

Clone the repository

git clone https://github.com/yourusername/figma-mcp-write-bridge.git
cd figma-mcp-write-bridge

Install dependencies
```
npm install
```
Import the Figma plugin
- Open Figma
- Go to Plugins → Development → Import plugin from manifest
- Select plugin/manifest.json from this project

Usage

Starting the Server

npm start

This will:

Start the WebSocket server on ws://127.0.0.1:3055
Initialize the MCP server listening on stdio
Wait for the Figma plugin to connect

Running the Figma Plugin

Open a Figma document
Go to Plugins → Development → MCP Figma Write Bridge
The plugin runs with a hidden UI to establish the WebSocket connection
You should see [bridge] Plugin connected in the server logs

Connecting Your AI Client

Configure your MCP client (e.g., VS Code) to use this server:

{
  "mcpServers": {
    "figma-write": {
      "command": "node",
      "args": [
        "--loader",
        "tsx",
        "/path/to/figma-mcp-write-bridge/server.ts"
      ]
    }
  }
}

Or using npm:

{
  "mcpServers": {
    "figma-write": {
      "command": "npm",
      "args": ["start"],
      "cwd": "/path/to/figma-mcp-write-bridge"
    }
  }
}

Available Tools

Creation Tools

create_frame - Create a new frame
create_rectangle - Create a rectangle with optional corner radius
create_ellipse - Create an ellipse
create_line - Create a line
create_polygon - Create a polygon with specified number of sides
create_star - Create a star shape
add_text - Add text with font styling
place_image_base64 - Place an image from base64 data

Node Management

find_nodes - Find nodes by name or type
select_nodes - Select specific nodes
get_selection - Get currently selected nodes
rename_node - Rename a node
delete_node - Delete a node
duplicate_node - Duplicate a node
resize_node - Resize a node
rotate_node - Rotate a node
set_position - Set absolute position
group_nodes - Group multiple nodes
ungroup - Ungroup a group node

Styling

set_fill - Set fill color
set_stroke - Configure stroke properties
set_corner_radius - Set corner radius (uniform or per-corner)
set_opacity - Set opacity
set_blend_mode - Set blend mode
add_effect - Add visual effects (shadows, blurs)
clear_effects - Remove all effects

Layout

layout_grid_add - Add layout grid
layout_grid_clear - Clear layout grids
set_auto_layout - Configure Auto Layout
set_constraints - Set child constraints

Text

set_text_content - Edit text content
set_text_style - Apply text styling
set_text_color - Set text color

Components

create_component - Create a component
create_instance - Create component instance
detach_instance - Detach instance from component

Advanced

boolean_op - Boolean operations on vector nodes
export_node - Export as PNG/JPG/SVG
set_plugin_data / get_plugin_data - Store/retrieve JSON data

Example Usage

Once connected, you can ask your AI assistant to:

"Create a blue rectangle 200x100 at position 50,50"

"Add a text saying 'Hello World' with Arial font size 24"

"Group the selected nodes and name it 'Header'"

"Export the frame as PNG"

or even:

"Create a full landing page design with both desktop and mobile layouts with the theme ... and describe the idea in mind"

The AI will use the appropriate MCP tools to execute these operations in your Figma document.

Development

Project Structure

figma-mcp-write-bridge/
├── server.ts              # MCP server & WebSocket bridge
├── plugin/
│   ├── plugin.js          # Figma plugin implementation
│   ├── ui.html            # Hidden UI for WebSocket access
│   └── manifest.json      # Plugin manifest
├── package.json
└── tsconfig.json

Adding New Tools

Implement the action in plugin/plugin.js:

async function myNewAction(input) {
  const { param1, param2 } = input;
  // Figma API operations
  return { result: "success" };
}

Add to the dispatcher in handleAction():

case "my_new_action": return myNewAction(input);

Register the MCP tool in server.ts:

registerTool(
  "my_new_tool",
  z.object({ param1: z.string(), param2: z.number() }),
  "Description of what this tool does",
  "my_new_action"
);

Debugging

Server logs: Check stderr output from npm start
Plugin logs: Open Figma → Plugins → Development → Open Console
WebSocket connection: Look for [bridge] Plugin connected message
Timeouts: Default 15s timeout for operations (configurable in sendToPlugin())

Limitations

Single client connection (one plugin instance at a time)
Operations must complete within 15 seconds
Requires Figma desktop app or browser access
Network access must be allowed in Figma plugin settings

Troubleshooting

"Figma plugin not connected" error

Ensure the Figma plugin is running (Plugins → Development → MCP Figma Write Bridge)
Check that the server is running (npm start)
Verify WebSocket connection logs

Plugin times out

Check Figma console for errors
Ensure the action is implemented in plugin.js
Verify the replyTo id matches in responses

Font loading errors

Font must be available in Figma
Font name and style must match exactly
Text operations automatically load fonts before modification

Contributing

Contributions are welcome! Please:

Fork the repository
Create a feature branch
Make your changes
Test thoroughly with a running Figma instance
Submit a pull request

License

MIT License - see LICENSE file for details

Acknowledgments

Built with the Model Context Protocol SDK
Uses Figma Plugin API

Support

For issues, questions, or feature requests, please open an issue on GitHub.

Available Tools

11 tools

add_icon_placeholderadd_icon_placeholderC

Insert a simple icon placeholder (circle or square) into a frame or page.

ParametersJSON Schema

Name	Required	Description	Default
`frameId`	No
`x`	No
`y`	No
`size`	No
`shape`	No
`hex`	No

TDQS

C2.7/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 such as whether the operation is destructive, requires permissions, or returns anything. It only states the basic action without any operational details.

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 concise sentence, but it lacks necessary details. While front-loaded, it is too sparse to be effective.

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 6 parameters, no output schema, and no annotations, the description is insufficient. It does not explain what happens after insertion, any side effects, or return values, leaving the agent underinformed.

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%, yet the description adds no parameter details beyond mentioning shape options. Parameters like frameId, x, y, size, and hex are completely unexplained, leaving the agent with no guidance on their semantics.

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 inserts an icon placeholder (circle or square) into a frame or page, using a specific verb and resource, and distinguishes it from sibling tools like 'rectangle' which might create general shapes.

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 like 'rectangle' or 'add_text'. No context on appropriate shapes or when placeholders are needed.

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

add_textadd_textC

Add a text node (loads font) at optional position.

ParametersJSON Schema

Name	Required	Default
`text`	Yes
`x`	No
`y`	No
`fontFamily`	No	Inter
`fontStyle`	No	Regular
`fontSize`	No

TDQS

C2.9/5.0

Behavior3/5

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

The description discloses that font loading occurs ('loads font'), which is a notable behavioral trait. However, without annotations, it lacks details on side effects, error conditions, or performance implications. It captures some transparency but not comprehensively.

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 front-loads the key action. It is efficient, though slightly more detail could improve clarity without sacrificing 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 6 parameters, no output schema, and no annotations, the description is too minimal. It does not explain return values, default behaviors beyond position, or error handling, leaving the agent underinformed.

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 compensate. It only adds meaning for the 'x' and 'y' parameters by mentioning 'optional position', but does not explain 'fontFamily', 'fontStyle', or 'fontSize' defaults, leaving significant gaps.

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 'Add' and the resource 'text node', and mentions the side effect of loading a font. It is specific and understandable, but does not explicitly differentiate from sibling tools like 'add_icon_placeholder' or 'create_frame'.

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 such as 'create_frame' or 'set_text_color'. The description does not include usage context, prerequisites, or exclusions.

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

clear_pageclear_pageA

Delete all nodes on the current page (use carefully!).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior3/5

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

Discloses the destructive nature (delete all nodes) and includes a warning. Without annotations, the description carries full burden; it doesn't mention undo, recovery, or effects on other pages, leaving gaps.

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?

Extremely concise: one sentence with a parenthetical warning. Front-loaded, no wasted words. Slightly could be improved with more structure.

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

Completeness3/5

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

For a destructive tool with no parameters and no output schema, the lack of details on recovery, scope (current page only), and side effects makes it somewhat incomplete. Adequate but could be more informative.

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?

No parameters in schema, so description coverage is 100% by default. Baseline score of 4 applies; description doesn't need to add parameter info.

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?

Clearly states the action: 'Delete all nodes on the current page'. Specific verb+resource, and distinct from sibling tools which are more targeted (e.g., add_text, rectangle).

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?

Only provides a cautionary note ('use carefully!'), but no explicit guidance on when to use this tool versus alternatives, or any prerequisites or restrictions.

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

create_framecreate_frameC

Create a frame with width/height and optional name/position.

ParametersJSON Schema

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

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It only says 'Create a frame' without explaining side effects, return value, or constraints like coordinate system or interaction with existing elements.

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 unnecessary words. However, it could be slightly expanded to improve clarity without losing conciseness.

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 5 parameters, no output schema, and no annotations, the description is too sparse. It lacks essential context about coordinate system, behavior, and expected output, making it insufficient for an agent to reliably use the tool.

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 coverage is 0%, yet the description only mentions width/height and optional name/position. It does not explain the meaning or constraints of x,y (e.g., origin, units) or how name is used, adding minimal value.

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 (create) and resource (frame), listing key parameters (width, height, optional name/position). However, it does not differentiate from sibling tools like 'rectangle' or 'group_nodes', which could be ambiguous.

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, nor any context about prerequisites, exclusions, 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.

find_text_nodesfind_text_nodesA

Return all text nodes on the current page with nodeId and content.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations provided. Description is minimal, not disclosing potential performance or scope of 'all text nodes' (e.g., large pages).

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 with no wasted words. Directly communicates purpose and output.

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

Completeness4/5

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

With no output schema, description specifies return fields (nodeId, content). Sufficient for a simple query tool.

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?

No parameters exist, so schema coverage is complete. Baseline of 4 applies; 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?

Clearly states it returns all text nodes on the current page with nodeId and content. Distinct from sibling tools that modify or create elements.

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 or not use. Context implies it's for reading text nodes, but alternatives are not discussed.

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

group_nodesgroup_nodesC

Group the given nodes into a single group.

ParametersJSON Schema

Name	Required	Description	Default
`nodeIds`	Yes
`name`	No

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It only states the action without revealing what happens to the nodes, whether it creates a new parent node, or any 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.

Conciseness5/5

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

The description is a single, efficient sentence with no unnecessary words, perfectly concise for a simple operation.

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 no output schema, no annotations, and two undocumented parameters, the description is far too minimal. An agent lacks critical context about parameter meanings, return values, and constraints.

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 does not explain the purpose of 'nodeIds' or 'name'. An agent cannot infer that 'name' is an optional label for the group.

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 'Group the given nodes into a single group' clearly states the action (group) and resource (nodes). It is specific and distinct from sibling tools like add_icon_placeholder or create_frame.

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, no prerequisites, and no exclusions. The usage is implied but not explained.

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

rectanglerectangleB

Create a rectangle with optional fill color/position/cornerRadius.

ParametersJSON Schema

Name	Required	Description	Default
`width`	Yes
`height`	Yes
`hex`	No
`x`	No
`y`	No
`cornerRadius`	No

TDQS

B3.3/5.0

Behavior3/5

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

Discloses optional fill color, position, and cornerRadius, but lacks details on default behavior, return value, or side effects. With no annotations, description carries full burden but is minimally adequate.

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?

Single sentence, concise and direct. No fluff, but could be slightly more structured.

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?

Lacks details on return, error handling, or system context. For a tool with 6 parameters and no output schema, the description is too brief to be fully complete.

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 coverage is 0%, so description must compensate. It groups optional parameters (fill color, position, cornerRadius) but does not explain individual parameter meanings beyond their names. Adds some value but not comprehensive.

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 'Create a rectangle' with specific verb and resource. It distinguishes from siblings like create_frame and add_text by focusing on rectangle creation.

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. Does not provide context such as prerequisites 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.

set_fillset_fillC

Apply a solid fill color (optionally opacity) to a node that supports fills.

ParametersJSON Schema

Name	Required	Description	Default
`nodeId`	Yes
`hex`	Yes
`opacity`	No

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior. It does not mention side effects (e.g., overwriting existing fill), error handling for unsupported nodes, or return value. The minimal description fails to inform about behavioral traits.

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 short with one sentence, but it is not earning its place due to lack of detail. It is appropriately concise but under-specified.

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 tool has 3 parameters, no output schema, and no annotations, the description fails to provide necessary context like success/failure behavior, prerequisites (node existence, fill support), or return format. It is incomplete.

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 0%, so the description must compensate. It only adds vague context ('optionally opacity') but does not explain hex format (e.g., #RRGGBB) or the exact meaning of opacity range, leaving ambiguity.

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 (apply fill color) and the resource (node that supports fills). It is specific enough to distinguish from sibling tools like set_text_color or add_text, though it could clarify what kind of nodes support fills.

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 alternative tools or any prerequisites. It lacks context about error conditions or appropriate usage scenarios.

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

set_interaction_dataset_interaction_dataC

Store interaction mapping in pluginData for a node (non-prototype).

ParametersJSON Schema

Name	Required	Description	Default
`nodeId`	Yes
`event`	No
`targetId`	No

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavioral traits. It only states the action (store) and target (pluginData for non-prototype nodes), but omits critical details such as potential side effects, overwrite behavior, required permissions, or error states. This is insufficient 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.

Conciseness4/5

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

The description is a single, concise 9-word sentence that front-loads the core action and constraint. It could benefit from additional detail without becoming verbose, but it avoids redundancy and is efficient in space.

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 schema descriptions, no output schema, and three parameters, the description is severely incomplete. It fails to explain parameter purposes, return value (none), or prerequisites. The tool cannot be reliably invoked based on this description alone.

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 the description must compensate by explaining the parameters. However, it mentions no parameter details; it does not clarify what event, targetId, or nodeId represent or how they relate to the interaction mapping. This leaves the agent without necessary input information.

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 stores interaction mapping in pluginData for a node, specifying it is for non-prototype nodes. This is a specific verb-resource pair that distinguishes it from sibling tools like add_text or create_frame, which handle visual elements.

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 implies usage is for non-prototype nodes but provides no explicit guidance on when to use this tool versus alternatives. No sibling tools are mentioned as alternatives, and no context signals like prerequisites or use cases are given.

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

set_positionset_positionC

Move a node to (x,y).

ParametersJSON Schema

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

TDQS

C2.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 must bear full weight. It only states the action but omits behavioral details like what happens if the nodeId is invalid, whether coordinates are absolute or relative, or if there are bounds.

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 concise but too terse, lacking necessary details. It is front-loaded but insufficient for a complete understanding.

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?

With 3 parameters, no output schema, and no annotations, the description fails to cover return values, error behavior, or context relative to sibling tools. It is inadequate for effective 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 description coverage is 0%, and the description adds no meaning beyond parameter names. It does not explain nodeId's scope or the coordinate system/units for x and y.

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 'Move a node to (x,y)' clearly states the specific action (move) and resource (node) with coordinates, distinguishing it from sibling tools that perform different operations like adding text or grouping 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, such as other node manipulation tools. No prerequisites or coordinate system details are provided.

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

set_text_colorset_text_colorC

Set the fill color of a text node.

ParametersJSON Schema

Name	Required	Description	Default
`nodeId`	Yes
`hex`	Yes
`opacity`	No

TDQS

C2.7/5.0

Behavior2/5

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

Without annotations, the description should disclose behavioral traits, but it only restates the tool's purpose. It does not mention side effects, permissions, or whether the operation is reversible.

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, succinct sentence with no redundant information. It is appropriately sized for the tool's apparent simplicity.

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 presence of a sibling tool 'set_fill' and no output schema, the description lacks information to fully contextualize the tool's use case and behavior. It is minimally viable but incomplete.

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%, and the description adds no explanation for any parameter. The 'opacity' parameter's range (0-1) is defined in the schema but not described, leaving the agent to guess its meaning.

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 (set) and the resource (fill color of a text node). However, it does not distinguish from the sibling tool 'set_fill', which likely has a similar purpose but possibly for different node types.

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 like 'set_fill' or when not to use it. The agent is left to infer 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.

Tool Schema Changelog

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

11 tool updatesv0.1.0May 28, 2026
- First observedadd_icon_placeholder
- First observedadd_text
- First observedclear_page
- First observedcreate_frame
- First observedfind_text_nodes
- First observedgroup_nodes
- First observedrectangle
- First observedset_fill
- First observedset_interaction_data
- First observedset_position
- First observedset_text_color

Install Server

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

TDQS

B3.2/5.0

Disambiguation5/5

Each tool has a distinct purpose (icon, text, frame, rectangle, grouping, fill, etc.), with no overlapping functionality. The only minor overlap is between set_fill and set_text_color, but they target different node types (general vs. text).

Naming Consistency4/5

Most tools follow verb_noun pattern (add_text, create_frame, set_fill, etc.), but 'rectangle' is a noun-only outlier, breaking the consistent convention.

Tool Count5/5

11 tools cover core write operations for Figma (creating shapes, text, icons, grouping, styling, positioning, and interaction data), which is well-scoped for a write bridge without being excessive.

Completeness3/5

Missing operations like deleting individual nodes, updating node content (beyond color/fill), adding strokes, or reading node hierarchy. The surface covers creation and basic modification but lacks full lifecycle support.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

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 COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42

Related MCP Servers

Figma MCP Server
Developer Tools App Automation Content Management Systems
mohammeduvaiz
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that connects AI tools and LLMs to Figma designs, enabling them to extract design data, analyze design systems, and generate development documentation.
Updated a year ago (2025-03-17 17:28 UTC)
1,701
2
MIT
Figma MCP Server
Developer Tools Content Management Systems App Automation
sichang824
A
license
Not graded
quality
D
maintenance
A server implementation that enables interaction with Figma API through Model Context Protocol (MCP), supporting plugin and widget development with WebSocket communication capabilities.
Updated a year ago (2025-08-29 01:12 UTC)
1,701
3
MIT
Figma MCP Server
Developer Tools Content Management Systems App Automation
kdoronin
F
license
Not graded
quality
D
maintenance
A Python implementation of the Model Context Protocol server that enables AI assistants to interact with Figma through WebSocket connections, allowing them to read, analyze, and export design data.
Updated a year ago (2025-09-08 20:15 UTC)
21
-
Devign MCP
Design Tools Autonomous Agents
SodiqOgundairo
F
license
Not graded
quality
D
maintenance
Enables any AI model to create, read, and edit Figma designs in real time through the Model Context Protocol.
Updated 5 months ago (2026-03-31 11:10 UTC)
-

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/firasmj/Figma-MCP-Write-Bridge'

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