Skip to main content
Glama
enesjakozh
ArchimedesCrypto

Figma MCP Server with Chunking

by ArchimedesCrypto
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

チャンク化機能を備えたFigma MCPサーバー

鍛冶屋のバッジ

Figma API と対話するためのモデル コンテキスト プロトコル (MCP) サーバー。大規模な Figma ファイルを処理するためのメモリ効率の高いチャンク化とページ分割機能を備えています。

概要

このMCPサーバーは、メモリ管理機能を内蔵した堅牢なFigma APIインターフェースを提供します。操作を管理しやすいチャンクに分割し、必要に応じてページネーションを実装することで、大規模なFigmaファイルを効率的に処理できるように設計されています。

主な特徴

  • 設定可能な制限を備えたメモリを考慮した処理

  • 大きなファイルのチャンクデータ取得

  • すべてのリスト操作のページ区切りのサポート

  • ノードタイプのフィルタリング

  • 進捗状況の追跡

  • 設定可能なチャンクサイズ

  • 中断された操作を再開する機能

  • デバッグログ

  • 設定ファイルのサポート

Related MCP server: Figma MCP Server

インストール

Smithery経由でインストール

Smithery経由で Claude Desktop 用の Chunking 付き Figma MCP Server を自動的にインストールするには:

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

get_file_comments

ページ区切りでコメントを取得します。

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

get_components

チャンク化をサポートするコンポーネントを取得します。

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

get_styles

チャンク化をサポートするスタイルを取得します。

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

get_file_nodes

チャンク化をサポートする特定のノードを取得します。

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

メモリ管理

サーバーは、メモリを効率的に管理するためのいくつかの戦略を実装しています。

チャンキング戦略

  • pageSizeによるチャンクサイズの設定

  • メモリ使用量の監視

  • メモリ負荷に基づく自動チャンクサイズ調整

  • チャンクごとの進捗状況の追跡

  • カーソルを使用した再開機能

ベストプラクティス

  1. 小さなチャンクサイズ（50～100ノード）から始めて、パフォーマンスに基づいて調整します。

  2. レスポンスメタデータを通じてメモリ使用量を監視する

  3. 可能な場合はノードタイプフィルタリングを使用してデータ負荷を軽減します

  4. 大規模データセットのページ区切りを実装する

  5. 非常に大きなファイルの場合は再開機能を使用する

設定オプション

  • 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]"

トラブルシューティング

よくある問題

  1. メモリエラー

    • チャンクサイズを減らす

    • ノードタイプフィルタリングを使用する

    • ページネーションを実装する

    • より小さい深度値を指定する

  2. パフォーマンスの問題

    • メモリ使用量を監視する

    • チャンクサイズを調整する

    • 適切なノードタイプフィルターを使用する

    • 頻繁にアクセスされるデータのキャッシュを実装する

  3. APIの制限

    • レート制限を実装する

    • ページネーションを使用する

    • 可能な場合はレスポンスをキャッシュする

デバッグモード

詳細情報を取得するには、デバッグ ログを有効にします。

# Set debug environment variable
export DEBUG=true

貢献

貢献を歓迎します！貢献ガイドラインをお読みになり、リポジトリにプルリクエストを送信してください。

ライセンス

このプロジェクトは MIT ライセンスに基づいてライセンスされています - 詳細については LICENSE ファイルを参照してください。

Available Tools

7 tools
get_componentsB

Get components from a Figma file

ParametersJSON Schema
NameRequiredDescriptionDefault
file_keyYesFigma 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
NameRequiredDescriptionDefault
file_keyYesFigma 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
NameRequiredDescriptionDefault
cursorNoPagination cursor for continuing from a previous request
depthNoMaximum depth to traverse in the node tree
excludePropsNoProperties to exclude from node data
file_keyYesFigma file key
maxMemoryMBNoMaximum memory usage in MB
maxResponseSizeNoMaximum response size in MB (defaults to 50)
nodeTypesNoFilter nodes by type
pageSizeNoNumber of nodes per page
summarizeNodesNoReturn 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
NameRequiredDescriptionDefault
file_keyYesFigma file key
idsYesArray 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
NameRequiredDescriptionDefault
file_keyYesFigma 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
NameRequiredDescriptionDefault
file_keyYesFigma 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
NameRequiredDescriptionDefault
project_idNoProject ID to list files from
team_idNoTeam 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.

  1. 7 tool updatesv1.0.0
    • 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 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

Related MCP Connectors

Related MCP Servers

Appeared in Searches