en es ja ko zh

Figma MCP Server with Chunking

Name: Figma MCP Server with Chunking
Author: ArchimedesCrypto

by ArchimedesCrypto

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

具有分块功能的 Figma MCP 服务器

铁匠徽章

用于与 Figma API 交互的模型上下文协议 (MCP) 服务器，具有处理大型 Figma 文件的内存高效分块和分页功能。

概述

此 MCP 服务器提供强大的 Figma API 接口，并内置内存管理功能。它旨在通过将操作分解为可管理的块并在必要时实现分页，从而高效处理大型 Figma 文件。

主要特点

具有可配置限制的内存感知处理
大文件的分块数据检索
所有列表操作均支持分页
节点类型过滤
进度追踪
可配置的块大小
恢复中断操作的能力
调试日志记录
配置文件支持

Related MCP server: Figma MCP Server

安装

通过 Smithery 安装

要通过Smithery自动安装 Figma MCP Server 和 Claude Desktop 的 Chunking：

npx -y @smithery/cli install @ArchimedesCrypto/figma-mcp-chunked --client claude

手动安装

# Clone the repository
git clone [repository-url]
cd figma-mcp-chunked

# Install dependencies
npm install

# Build the project
npm run build

配置

环境变量

FIGMA_ACCESS_TOKEN ：您的 Figma API 访问令牌

配置文件

您可以使用--config标志通过 JSON 文件提供配置：

{
  "mcpServers": {
    "figma": {
      "env": {
        "FIGMA_ACCESS_TOKEN": "your-access-token"
      }
    }
  }
}

用法：

node build/index.js --config=path/to/config.json

工具

get_file_data（新）

使用内存高效的分块和分页检索 Figma 文件数据。

{
  "name": "get_file_data",
  "arguments": {
    "fileKey": "your-file-key",
    "accessToken": "your-access-token",
    "pageSize": 100,          // Optional: nodes per chunk
    "maxMemoryMB": 512,       // Optional: memory limit
    "nodeTypes": ["FRAME", "COMPONENT"],  // Optional: filter by type
    "cursor": "next-page-token",  // Optional: resume from last position
    "depth": 2                // Optional: traversal depth
  }
}

回复：

{
  "nodes": [...],
  "memoryUsage": 256.5,
  "nextCursor": "next-page-token",
  "hasMore": true
}

列表文件

列出支持分页的文件。

{
  "name": "list_files",
  "arguments": {
    "project_id": "optional-project-id",
    "team_id": "optional-team-id"
  }
}

获取文件版本

分块检索版本历史记录。

{
  "name": "get_file_versions",
  "arguments": {
    "file_key": "your-file-key"
  }
}

获取文件评论

检索带有分页的评论。

{
  "name": "get_file_comments",
  "arguments": {
    "file_key": "your-file-key"
  }
}

获取文件信息

使用分块节点遍历检索文件信息。

{
  "name": "get_file_info",
  "arguments": {
    "file_key": "your-file-key",
    "depth": 2,               // Optional: traversal depth
    "node_id": "specific-node-id"  // Optional: start from specific node
  }
}

获取组件

检索具有分块支持的组件。

{
  "name": "get_components",
  "arguments": {
    "file_key": "your-file-key"
  }
}

获取样式

检索具有分块支持的样式。

{
  "name": "get_styles",
  "arguments": {
    "file_key": "your-file-key"
  }
}

获取文件节点

检索具有分块支持的特定节点。

{
  "name": "get_file_nodes",
  "arguments": {
    "file_key": "your-file-key",
    "ids": ["node-id-1", "node-id-2"]
  }
}

内存管理

服务器实施了几种策略来有效地管理内存：

分块策略

通过pageSize配置块大小
内存使用情况监控
根据内存压力自动调整块大小
每个块的进度跟踪
使用游标恢复功能

最佳实践

从较小的块大小（50-100 个节点）开始，并根据性能进行调整
通过响应元数据监控内存使用情况
尽可能使用节点类型过滤来减少数据负载
为大型数据集实现分页
对非常大的文件使用恢复功能

配置选项

pageSize ：每个块的节点数（默认值：100）
maxMemoryMB ：最大内存使用量（MB）（默认值：512）
nodeTypes ：过滤特定的节点类型
depth ：控制嵌套结构的遍历深度

调试日志

该服务器包括全面的调试日志记录：

// Debug log examples
[MCP Debug] Loading config from config.json
[MCP Debug] Access token found xxxxxxxx...
[MCP Debug] Request { tool: 'get_file_data', arguments: {...} }
[MCP Debug] Response size 2.5 MB

错误处理

服务器提供了详细的错误信息和建议：

// Memory limit error
"Response size too large. Try using a smaller depth value or specifying a node_id.""

// Invalid parameters
"Missing required parameters: fileKey and accessToken"

// API errors
"Figma API error: [detailed message]"

故障排除

常见问题

内存错误
- 减少块大小
- 使用节点类型过滤
- 实现分页
- 指定较小的深度值
性能问题
- 监视内存使用情况
- 调整块大小
- 使用适当的节点类型过滤器
- 对频繁访问的数据实施缓存
API 限制
- 实施速率限制
- 使用分页
- 尽可能缓存响应

调试模式

启用调试日志以获取详细信息：

# Set debug environment variable
export DEBUG=true

贡献

欢迎贡献代码！请阅读我们的贡献指南，并向我们的代码库提交 Pull Request。

执照

该项目根据 MIT 许可证获得许可 - 有关详细信息，请参阅 LICENSE 文件。

Available Tools

7 tools

get_componentsB

Get components from a Figma file

ParametersJSON Schema

Name	Required	Description	Default
`file_key`	Yes	Figma file key

TDQS

B3.1/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 for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format/components are included. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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 zero wasted words. It's appropriately sized for a simple retrieval tool and immediately communicates the core functionality without unnecessary elaboration.

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 single-parameter read tool, the description is minimally adequate but has clear gaps. With no annotations and no output schema, it doesn't explain what 'components' are, what format they're returned in, or any behavioral constraints. The description meets basic requirements but leaves important contextual questions unanswered.

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 the schema already fully documents the single 'file_key' parameter. The description doesn't add any parameter semantics beyond what's in the schema, such as explaining what a 'Figma file key' represents or providing examples. The baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Get') and target resource ('components from a Figma file'), making the tool's purpose immediately understandable. However, it doesn't differentiate this tool from its siblings like 'get_file_nodes' or 'get_file_data', which likely retrieve different types of file content.

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. With siblings like 'get_file_nodes' and 'get_file_data' that might retrieve similar file content, there's no indication of what distinguishes 'components' from other file elements or when this specific retrieval is appropriate.

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

get_file_commentsC

Get comments on a Figma file

ParametersJSON Schema

Name	Required	Description	Default
`file_key`	Yes	Figma file key

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't add any context beyond that—such as whether it's read-only, requires authentication, has rate limits, returns paginated results, or what the output format might be. This leaves significant gaps for an agent to understand how to interact with it effectively.

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 wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's purpose.

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 lack of annotations and output schema, the description is incomplete for a tool that likely returns structured data (comments). It doesn't explain what the output includes (e.g., comment text, authors, timestamps) or any behavioral traits, leaving the agent with insufficient context to use the tool effectively beyond the basic parameter.

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?

The input schema has 100% description coverage, with the 'file_key' parameter clearly documented as a 'Figma file key'. The description doesn't add any extra meaning beyond this, such as examples or format details, but since the schema already provides adequate information, a baseline score of 3 is appropriate.

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 ('Get') and resource ('comments on a Figma file'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its siblings like 'get_file_data' or 'get_file_nodes', which might also retrieve file-related information but focus on different aspects.

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 doesn't mention scenarios where this is appropriate (e.g., for reviewing feedback) or when to choose other tools like 'get_file_data' for different file metadata, leaving the agent to infer usage 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.

get_file_dataC

Get Figma file data with chunking and pagination

ParametersJSON Schema

Name	Required	Description
`cursor`	No	Pagination cursor for continuing from a previous request
`depth`	No	Maximum depth to traverse in the node tree
`excludeProps`	No	Properties to exclude from node data
`file_key`	Yes	Figma file key
`maxMemoryMB`	No	Maximum memory usage in MB
`maxResponseSize`	No	Maximum response size in MB (defaults to 50)
`nodeTypes`	No	Filter nodes by type
`pageSize`	No	Number of nodes per page
`summarizeNodes`	No	Return only essential node properties to reduce response size

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It hints at pagination and chunking but doesn't explain how these work, what the response format looks like, error conditions, rate limits, or authentication needs. For a tool with 9 parameters and no annotations, this leaves significant gaps in understanding its behavior.

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, efficient sentence that gets straight to the point. It's appropriately sized and front-loaded with the core purpose, though it could be slightly more structured by separating key features.

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 (9 parameters, no annotations, no output schema), the description is incomplete. It doesn't address the tool's output format, error handling, or how pagination and chunking interact with parameters like 'pageSize' and 'maxResponseSize'. For a data retrieval tool with rich parameters, more context is needed.

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?

The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond what's in the schema—it doesn't clarify parameter interactions, defaults, or usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Get') and resource ('Figma file data'), making the purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'get_file_nodes' or 'get_file_versions', which likely retrieve similar data but with different scopes or formats.

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 mentions 'chunking and pagination' but provides no explicit guidance on when to use this tool versus alternatives like 'get_file_nodes' or 'get_file_comments'. There's no mention of prerequisites, exclusions, or specific scenarios where this tool is preferred over siblings.

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

get_file_nodesC

Get specific nodes from a Figma file

ParametersJSON Schema

Name	Required	Description	Default
`file_key`	Yes	Figma file key
`ids`	Yes	Array of node IDs to retrieve

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It doesn't mention whether this is a read-only operation, what permissions are required, whether there are rate limits, what happens with invalid node IDs, or what format the returned nodes have. 'Get' implies retrieval but lacks 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.

Conciseness5/5

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

The description is extremely concise at just 6 words, front-loading the essential purpose without any wasted language. Every word contributes directly to understanding what the tool does, making it efficient and scannable despite its 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?

For a tool with 2 required parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address key operational aspects like authentication requirements, error conditions, response format, or how this differs from similar retrieval tools. The agent would need to guess about many behavioral characteristics.

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?

The schema has 100% description coverage, so parameters are fully documented in structured fields. The description adds no additional parameter context beyond what's in the schema - it doesn't explain what constitutes a valid 'file_key', how to obtain node IDs, or whether the IDs array has size limits. Baseline 3 is appropriate when schema does the heavy lifting.

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 ('Get') and resource ('specific nodes from a Figma file'), making the purpose immediately understandable. However, it doesn't distinguish this tool from siblings like 'get_file_data' or 'get_components' - all could involve retrieving elements from Figma files, so the differentiation is incomplete.

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. With siblings like 'get_file_data', 'get_components', and 'get_styles' available, there's no indication whether this is for general node retrieval versus specialized component/style fetching, or whether it's preferred over 'get_file_data' for specific use cases.

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

get_file_versionsC

Get version history of a Figma file

ParametersJSON Schema

Name	Required	Description	Default
`file_key`	Yes	Figma file key

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves version history, implying a read-only operation, but lacks details on permissions required, rate limits, pagination, error handling, or what the output format looks like (e.g., list of versions with metadata). This leaves significant gaps for an agent to understand how to interact with it effectively.

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, direct sentence with no unnecessary words, making it highly concise and front-loaded. It immediately communicates the core functionality without any fluff, which is ideal for quick comprehension by an AI agent.

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 lack of annotations and output schema, the description is incomplete for a tool that likely returns structured data (e.g., a list of file versions). It doesn't explain what information is included in the version history (e.g., timestamps, user names, change descriptions) or how to interpret the results, leaving the agent with insufficient context to use the tool effectively beyond the basic parameter.

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?

The input schema has 100% description coverage, with the 'file_key' parameter clearly documented as 'Figma file key'. The description adds no additional semantic context beyond what the schema provides, such as format examples or where to find the file key. With high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.

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 ('Get version history') and the resource ('of a Figma file'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'get_file_data' or 'get_file_nodes', but the specific focus on version history provides some implicit distinction.

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 doesn't mention prerequisites (e.g., needing a valid file key), exclusions, or comparisons to sibling tools like 'get_file_data' for general file information or 'get_file_nodes' for node-specific data.

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

get_stylesC

Get styles from a Figma file

ParametersJSON Schema

Name	Required	Description	Default
`file_key`	Yes	Figma file key

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states a read operation ('Get'), implying it's likely safe, but doesn't mention permissions, rate limits, pagination, or what 'styles' encompasses (e.g., text styles, color styles). This leaves significant gaps for a tool with no annotation coverage.

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 zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.

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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'styles' includes, the return format, or any behavioral traits like error handling. For a tool with no structured support, more context is needed to be fully helpful.

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?

The schema description coverage is 100%, with the single parameter 'file_key' documented as 'Figma file key'. The description adds no additional meaning beyond this, such as format examples or where to find the key. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.

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 ('Get') and resource ('styles from a Figma file'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_components' or 'get_file_nodes', which also retrieve specific elements from Figma files, so it lacks sibling distinction.

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 like 'get_components' or 'get_file_data'. It doesn't specify context, prerequisites, or exclusions, leaving the agent to infer usage based on tool names alone.

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

list_filesC

List files in a project or team

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	No	Project ID to list files from
`team_id`	No	Team ID to list files from

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 carries the full burden. It states the action ('List files') but lacks behavioral details such as pagination, sorting, filtering options, rate limits, permissions required, or what the output format looks like. This is a significant gap for a tool with no annotation coverage.

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 zero waste. It is appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.

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 annotations, no output schema, and a tool that likely returns a list of files, the description is incomplete. It doesn't explain return values, behavioral traits, or usage context beyond the basic scope, leaving gaps for an AI agent to understand how to invoke it effectively.

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 the schema already documents both parameters ('project_id' and 'team_id'). The description implies these are used for scoping but adds no syntax, format, or usage details beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('List') and resource ('files'), and specifies the scope ('in a project or team'). However, it doesn't differentiate from sibling tools like 'get_file_data' or 'get_file_versions', which might also retrieve file-related information but with different purposes.

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 like 'get_file_data' or 'get_file_versions'. It mentions the context ('project or team') but offers no explicit when/when-not instructions or prerequisites for selecting between 'project_id' and 'team_id'.

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.

7 tool updatesv1.0.0Mar 25, 2025
- First observedget_components
- First observedget_file_comments
- First observedget_file_data
- First observedget_file_nodes
- First observedget_file_versions
- First observedget_styles
- First observedlist_files

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

A3.5/5.0

Scored 2026-04-18 10:55 across 7 tools

Disambiguation5/5

Each tool has a clearly distinct purpose targeting different aspects of Figma files: components, comments, file data, nodes, versions, styles, and file listing. There is no overlap in functionality, making tool selection straightforward for an agent.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with 'get_' or 'list_' prefixes (e.g., get_components, list_files). The naming is uniform and predictable, enhancing readability and usability.

Tool Count5/5

With 7 tools, the server is well-scoped for a Figma integration, covering essential operations like retrieving file data, components, styles, comments, and versions. Each tool serves a specific purpose without being excessive or insufficient.

Completeness4/5

The toolset provides strong read-only coverage for Figma files, including data, components, styles, comments, versions, and file listing. However, it lacks write operations (e.g., creating or updating files, components, or comments), which could limit full lifecycle management, though agents can work around this for many use cases.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
Studex MCP ServerOAuth
io.github.itshivams
Model Context Protocol server for Studex tools, notifications, and profile integrations
Developer Tools
1
todo.vu AOAuth
io.github.mooball
Model Context Protocol server for todo.vu task management and time tracking.
Payments & Billing Project Management Workplace & Productivity
2
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
238

Related MCP Servers

mcp-figma
Developer Tools Content Management Systems App Automation
clavia-labs
F
license
B
quality
Not graded
maintenance
A Model Context Protocol server that provides access to Figma API functionality, allowing AI assistants like Claude to interact with Figma files, comments, components, and team resources.
Updated 2 years ago (2025-03-03 11:49 UTC)
18
857 npm
4
-
Figma MCP Server
Content Management Systems Developer Tools App Automation
deepsuthar496
F
license
B
quality
D
maintenance
A Model Context Protocol server that integrates with Figma's API, allowing interaction with Figma files, comments, components, projects, and webhook management.
Updated a year ago (2025-04-04 12:18 UTC)
5
2,189 npm
-
Cursor Talk to Figma MCP
Developer Tools App Automation
paragdesai1
A
license
B
quality
D
maintenance
Implements a Model Context Protocol integration between Cursor AI and Figma, allowing Cursor to programmatically read and modify Figma designs.
Updated a year ago (2025-04-21 01:35 UTC)
33
1,084 npm
MIT
Figma MCP Write Bridge
Design Tools Developer Tools
firasmj
A
license
B
quality
D
maintenance
A Model Context Protocol server that enables AI agents to programmatically create, modify, and manage Figma documents via a WebSocket bridge and Figma plugin.
Updated 9 months ago (2026-01-09 20:49 UTC)
11
6
MIT

具有分块功能的 Figma MCP 服务器

概述

主要特点

安装

通过 Smithery 安装

手动安装

配置

环境变量

配置文件

工具

get_file_data（新）

列表文件

获取文件版本

获取文件评论

获取文件信息

获取组件

获取样式

获取文件节点

内存管理

分块策略

最佳实践

配置选项

调试日志

错误处理

故障排除

常见问题

调试模式

贡献

执照

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches