Skip to main content
Glama
shinjiyu

figma-meta-mcp

by shinjiyu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

figma-meta-mcp

Lightweight Figma MCP in the same mental model as ae-meta-mcp (ae_exec) and CocosMetaMCP (cocosmcp_exec): the Cursor agent runs JavaScript inside a running Figma via figma_exec.

Cursor Agent  ──stdio MCP──▶  Node (MCP + bridge :3851)
                                   ▲
                                   │ WebSocket /plugin
                              Figma Development plugin (UI + main)
                                   │
                              figma.* Plugin API

This path does not use the Figma REST API + Personal Access Token, so it avoids the Viewer-seat REST monthly rate limits. You need the Figma desktop app and the local Development plugin panel open.

Repo: shinjiyu/figma_mcp

Tools (MVP)

Tool

Description

figma_health

Bridge up? Plugin WebSocket connected?

figma_exec

Run arbitrary Plugin-API JS in the main thread; return JSON

figma_selection_info

Summarize current page + selection bounds

Related MCP server: figma-opencode-mcp

Requirements

Install

git clone https://github.com/shinjiyu/figma_mcp.git
cd figma_mcp
npm install

Wire Cursor

npm run setup:cursor

Paste the printed snippet into ~/.cursor/mcp.json, then toggle figma-meta-mcp off/on under Cursor Settings → MCP.

Example:

{
  "mcpServers": {
    "figma-meta-mcp": {
      "command": "node",
      "args": ["D:/workspace/figma_mcp/mcp/index.mjs"],
      "env": {
        "FIGMA_MCP_PORT": "3851"
      }
    }
  }
}

Import the Figma plugin

  1. Start Cursor so MCP (and the bridge on 127.0.0.1:3851) is running.

  2. Open your design file in the Figma desktop app.

  3. Menu: Plugins → Development → Import plugin from manifest…

  4. Select plugin/manifest.json from this repo.

  5. Run Plugins → Development → figma-meta-mcp and keep the panel open.

The panel should show Connected · plugin channel ready.

Verify

  1. figma_health → { ok: true, pluginConnected: true }

  2. figma_selection_info → current page + selection

  3. figma_exec:

return {
  file: figma.root.name,
  page: figma.currentPage.name,
  count: figma.currentPage.children.length,
};

Writing figma_exec code

  • Runs in the plugin main thread with global figma.

  • Write an async body; use return for the payload.

  • Return plain JSON (id / name / type / x / y / width / height). Live node proxies are auto-shrunk when possible, but prefer mapping yourself.

  • Need document bytes for a node? await figma.getNodeByIdAsync(id) (dynamic-page).

See skills/figma-plugin-api/SKILL.md.

Layout

mcp/      stdio MCP server (index, core, context)
bridge/   HTTP + WebSocket host used by the plugin UI
plugin/   Figma Development plugin (manifest, code.js, ui.html)
scripts/  setup-cursor.mjs
skills/   agent notes for Plugin API
examples/ cursor-mcp.json

Env

Variable

Default

Meaning

FIGMA_MCP_PORT

3851

Bridge listen port

FIGMA_MCP_HOST

(unset)

Default: bind loopback only (127.0.0.1 + ::1). Set only to override.

FIGMA_MCP_CORS_ORIGINS

Figma + null + localhost

Comma-separated Origin allowlist (not *)

FIGMA_MCP_EXEC_TIMEOUT_MS

30000

Per-job timeout

Not in scope (yet)

  • Official remote Figma MCP OAuth (mcp.figma.com) — use that separately if you want cloud tools

  • REST PAT wrappers — intentionally avoided for quota reasons

  • Recipe/promote layer (CocosMetaMCP-style) — add later if needed

License

MIT

Available Tools

3 tools
figma_execA

Execute JavaScript inside the running Figma plugin main thread (like ae_exec / cocosmcp_exec / Blender execute_blender_code). The code runs with access to the global figma Plugin API. Write an async body; the final expression / return value is JSON-serialized back. Prefer plain data (id/name/type/x/y/width/height). Avoid returning live node proxies. Example: return figma.currentPage.selection.map(n => ({ id: n.id, name: n.name, type: n.type }));

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesPlugin-main JavaScript body. Can use await. Return JSON-serializable data.

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses the execution context (main thread, global figma API), async support, JSON serialization of return values, and warns against returning live node proxies. This is valuable behavioral context beyond just 'execute code', though it omits error handling or timeout behavior.

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 compact and well-structured, front-loading the core purpose and then providing essential details, warnings, and an illustrative example. Every sentence earns its place without redundancy.

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 generic code execution tool, the description covers the essential aspects: execution environment, API access, async body, return serialization, and data handling guidance. It lacks explicit error handling or side-effect caveats, but these are not critical for a straightforward exec tool, and the example makes it actionable.

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 schema covers the single 'code' parameter with a description, and the tool description adds more: async body, JSON-serializable return, and an example. This enriches the parameter meaning beyond the schema, so a 4 is appropriate despite high schema coverage.

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's function: 'Execute JavaScript inside the running Figma plugin main thread.' It uses a specific verb and resource, and the analogy to ae_exec/cocosmcp_exec differentiates it from the sibling tools (figma_health, figma_selection_info), which are specialized for health checks and selection info.

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

Usage Guidelines4/5

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

The description makes the usage context clear: it's for running arbitrary JavaScript with access to the Figma plugin API. It implies this tool is for custom logic beyond the simpler sibling tools, but it does not explicitly state when not to use it or name alternatives directly. The example with selection shows a typical use case.

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

figma_healthA

Check whether the local Figma bridge is up and whether the Development plugin is connected.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description must disclose behavioral traits. It does state the two conditions it checks, which is transparent about its scope. However, it does not mention side effects (though 'check' implies none), return format, error behavior, or what happens if connectivity fails. For a zero-parameter read-only health check, this is adequate but not rich.

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 clear sentence with no redundancy. It front-loads the verb 'Check' and the object, making it immediately scannable. Every word earns its place.

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?

The tool is simple (zero params, no output schema), so the description covers the main function. However, it does not explain the return value or status format, which the agent might need to interpret the health check result. Given the lack of an output schema, a brief note on the response would improve completeness.

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, so the baseline is 4. The description adds no parameter details, but none are needed since the schema is empty and coverage is 100%. The description correctly focuses on the tool's behavior rather than inputs.

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's function: checking whether the local Figma bridge is up and whether the Development plugin is connected. The verb 'Check' plus the specific resources (bridge, plugin) makes the purpose unambiguous and distinguishes it from siblings like figma_exec (execution) and figma_selection_info (selection details).

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 mention that this should be run before other Figma tools to verify connectivity, nor does it reference sibling tools or any exclusion scenarios. The intended usage is only implied by the tool name 'figma_health', not stated.

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

figma_selection_infoA

Summarize the current page and selection (id/name/type/bounds).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. 'Summarize' implies a read-only operation, but it does not explicitly state that it has no side effects, whether it requires authentication, or how it handles empty selections. This leaves some ambiguity.

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, focused sentence that immediately communicates the core function and the data returned. Every word earns its place with no unnecessary detail.

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 tool with no parameters and no output schema, the description provides essential details about what is summarized and the attributes included. It could clarify the exact return structure or edge-case behavior, but it is otherwise adequate.

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 the description's mention of the current page and selection is sufficient context. The baseline of 4 applies because there are no parameters to document.

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 summarizes the current page and selection, listing the specific attributes (id/name/type/bounds). This distinguishes it from siblings like figma_health (health checks) and figma_exec (execution).

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 versus alternatives. The context implies it is for retrieving selection information, but it does not name alternatives or specify when not to use it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedfigma_exec
    • First observedfigma_health
    • First observedfigma_selection_info
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored across 3 tools

Disambiguation5/5

The three tools serve clearly distinct functions: health check, arbitrary code execution, and selection introspection. There is no overlap in purpose, even though figma_selection_info could be replicated via figma_exec; it is presented as a convenience wrapper with a distinct scope.

Naming Consistency4/5

All tool names share the figma_ prefix, but the second part is not uniformly verb_noun. figma_health and figma_selection_info are noun phrases, while figma_exec is a verb. This is a minor inconsistency, but the pattern is still predictable and readable.

Tool Count4/5

Three tools is a small but reasonable set for a bridge server. The health and selection tools handle occasional meta needs, while figma_exec provides the core general-purpose capability. It is slightly on the lean side, but not insufficient.

Completeness5/5

figma_exec offers arbitrary access to the Figma Plugin API, making the tool surface effectively complete for any operation. The other two tools cover operational status and a common convenience need. There are no obvious dead ends or missing core workflows.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • figma-mcp-write-server

    oO
    F
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that provides write access to Figma through the Plugin API, enabling AI agents to create, modify, and manage Figma designs programmatically.
    23
    -

  • Figma Native MCP

    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.
    MIT