Skip to main content
Glama

Figma MCP Server

A Model Context Protocol (MCP) server that provides integration with Figma's API through Claude and other MCP-compatible clients. Currently supports read-only access to Figma files and projects, with server-side architecture capable of supporting more advanced design token and theme management features (pending Figma API enhancements or plugin development).

Project Status

Current Progress

  • Core Implementation: Successfully built a TypeScript server following the Model Context Protocol (MCP)

  • Claude Desktop Integration: Tested and functional with Claude Desktop

  • Read Operations: Working get-file and list-files tools for Figma file access

  • Server Architecture: Caching system, error handling, and stats monitoring implemented

  • Transport Protocols: Both stdio and SSE transport mechanisms supported

Potential Full Functionality

The server has been designed with code to support these features (currently limited by API restrictions):

  • Variable Management: Create, read, update, and delete design tokens (variables)

  • Reference Handling: Create and validate relationships between tokens

  • Theme Management: Create themes with multiple modes (e.g., light/dark)

  • Dependency Analysis: Detect and prevent circular references

  • Batch Operations: Perform bulk actions on variables and themes

With Figma plugin development or expanded API access, these features could be fully enabled.

Related MCP server: Figma MCP Server

Features

  • 🔑 Secure authentication with Figma API

  • 📁 File operations (read, list)

  • 🎨 Design system management

    • Variable creation and management

    • Theme creation and configuration

    • Reference handling and validation

  • 🚀 Performance optimized

    • LRU caching

    • Rate limit handling

    • Connection pooling

  • 📊 Comprehensive monitoring

    • Health checks

    • Usage statistics

    • Error tracking

Prerequisites

  • Node.js 18.x or higher

  • Figma access token with appropriate permissions

  • Basic understanding of MCP (Model Context Protocol)

Installation

npm install figma-mcp-server

Configuration

  1. Create a .env file based on .env.example:

# Figma API Access Token
FIGMA_ACCESS_TOKEN=your_figma_token

# Server Configuration
MCP_SERVER_PORT=3000

# Debug Configuration
DEBUG=figma-mcp:*
  1. For Claude Desktop integration:

The server can be configured in your Claude Desktop config file:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "figma": {
      "command": "node",
      "args": ["/ABSOLUTE/PATH/TO/figma-mcp-server/dist/index.js"],
      "env": {
        "FIGMA_ACCESS_TOKEN": "your_token_here"
      }
    }
  }
}

Important Notes:

  • Use ABSOLUTE paths, not relative paths

  • On Windows, use double backslashes (\\) in paths

  • Restart Claude Desktop after making configuration changes

Usage

Basic Usage

import { startServer } from 'figma-mcp-server';

const server = await startServer(process.env.FIGMA_ACCESS_TOKEN);

Available Tools

  1. get-file

    • Retrieve Figma file details

    {
      "name": "get-file",
      "arguments": {
        "fileKey": "your_file_key"
      }
    }
  2. list-files

    • List files in a Figma project

    {
      "name": "list-files",
      "arguments": {
        "projectId": "your_project_id"
      }
    }
  3. create-variables

    • Create design system variables

    {
      "name": "create-variables",
      "arguments": {
        "fileKey": "your_file_key",
        "variables": [
          {
            "name": "primary-color",
            "type": "COLOR",
            "value": "#0066FF"
          }
        ]
      }
    }
  4. create-theme

    • Create and configure themes

    {
      "name": "create-theme",
      "arguments": {
        "fileKey": "your_file_key",
        "name": "Dark Theme",
        "modes": [
          {
            "name": "dark",
            "variables": [
              {
                "variableId": "123",
                "value": "#000000"
              }
            ]
          }
        ]
      }
    }

API Documentation

Server Methods

  • startServer(figmaToken: string, debug?: boolean, port?: number)

    • Initializes and starts the MCP server

    • Returns: Promise

Tool Schemas

All tool inputs are validated using Zod schemas:

const CreateVariablesSchema = z.object({
  fileKey: z.string(),
  variables: z.array(z.object({
    name: z.string(),
    type: z.enum(['COLOR', 'FLOAT', 'STRING']),
    value: z.string(),
    scope: z.enum(['LOCAL', 'ALL_FRAMES'])
  }))
});

Error Handling

The server provides detailed error messages and proper error codes:

  • Invalid token: 403 with specific error message

  • Rate limiting: 429 with reset time

  • Validation errors: 400 with field-specific details

  • Server errors: 500 with error tracking

Limitations & Known Issues

API Restrictions

  1. Read-Only Operations

    • Limited to read-only operations due to Figma API restrictions

    • Personal access tokens only support read operations, not write

    • Cannot modify variables, components, or styles through REST API with personal tokens

    • Write operations would require Figma plugin development instead

  2. Rate Limiting

    • Follows Figma API rate limits

    • Implement exponential backoff for better handling

  3. Cache Management

    • Default 5-minute TTL

    • Limited to 500 entries

    • Consider implementing cache invalidation hooks

  4. Authentication

    • Only supports personal access tokens

    • No support for team-level permissions or collaborative editing

    • OAuth implementation planned for future

  5. Technical Implementation

    • Requires absolute paths in configuration

    • Must compile TypeScript files before execution

    • Requires handling both local and global module resolution

Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes with tests

  4. Submit a pull request

Please follow our coding standards:

  • TypeScript strict mode

  • ESLint configuration

  • Jest for testing

  • Comprehensive error handling

License

MIT License - See LICENSE file for details

Troubleshooting

See TROUBLESHOOTING.md for a comprehensive troubleshooting guide.

Common Issues

  1. JSON Connection Errors

    • Use absolute paths in Claude Desktop configuration

    • Ensure the server is built (npm run build)

    • Verify all environment variables are set

  2. Authentication Issues

    • Verify your Figma access token is valid

    • Check the token has required permissions

    • Ensure the token is correctly set in configuration

  3. Server Not Starting

    • Check Node.js version (18.x+ required)

    • Verify the build exists (dist/index.js)

    • Check Claude Desktop logs:

      • macOS: ~/Library/Logs/Claude/mcp*.log

      • Windows: %APPDATA%\Claude\logs\mcp*.log

For more detailed debugging steps and solutions, refer to the troubleshooting guide.

Support

Available Tools

2 tools
get-fileA

Get details of a Figma file

ParametersJSON Schema
NameRequiredDescriptionDefault
fileKeyYesThe Figma file key

TDQS

A3.5/5.0
Behavior2/5

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

With no annotations, description carries full burden but only says 'get details'. No disclosure of what details include, authentication needs, or 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?

Single sentence, front-loaded with verb and resource, no wasted words.

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 simple one-parameter read tool, description is minimally complete but lacks specificity on what 'details' are returned.

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 100% with a single parameter documented. Description adds no extra meaning 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?

Description clearly states the action ('Get') and resource ('details of a Figma file'). It distinguishes from sibling 'list-files' which lists files.

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. Usage is implied but not clarified.

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

list-filesB

List files in a Figma project

ParametersJSON Schema
NameRequiredDescriptionDefault
projectIdYesThe Figma project ID

TDQS

B3.2/5.0
Behavior2/5

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

No annotations, and description lacks behavioral context. Does not inform about pagination, result format, or any constraints. Minimal transparency.

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, no redundancy. However, it might be too minimal; a little more detail would improve without harming conciseness.

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?

Covers basic purpose but lacks guidance on response format, limitations, or differentiation from sibling. Adequate but not 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?

Parameter is fully described in schema. Description does not add additional meaning or context (e.g., format of ID, where to find it). So baseline score of 3.

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 action (list) and resource (files in a Figma project). Distinguishes from sibling tool get-file which likely retrieves a single file.

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 usage guidelines provided; agent must infer from context alone. Does not mention when to use list versus get or any exclusions.

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

TDQS

B3.4/5.0
Disambiguation5/5

The two tools are clearly distinct: one retrieves details of a specific file, the other lists files in a project. There is no overlap or ambiguity.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern (get-file, list-files) using snake_case, making them predictable and readable.

Tool Count3/5

With only 2 tools, the server feels very thin for a full Figma integration. While the count is borderline, it is still usable for basic file listing and retrieval.

Completeness2/5

The server lacks critical operations such as creating, updating, or deleting files, and does not cover other common Figma resources like components or styles. This is a significant gap for expected Figma workflows.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/TimHolden/figma-mcp-server'

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