Skip to main content
Glama
enesjakozh
ArchimedesCrypto

Figma MCP Server with Chunking

by ArchimedesCrypto
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

청킹을 사용한 Figma MCP 서버

대장간 배지

Figma API와 상호 작용하기 위한 MCP(Model Context Protocol) 서버로, 대용량 Figma 파일을 처리하기 위한 메모리 효율적인 청킹 및 페이지 분할 기능을 제공합니다.

개요

이 MCP 서버는 내장된 메모리 관리 기능을 통해 Figma API에 대한 강력한 인터페이스를 제공합니다. 작업을 관리 가능한 단위로 나누고 필요한 경우 페이지 매김을 구현하여 대용량 Figma 파일을 효율적으로 처리하도록 설계되었습니다.

주요 특징

  • 구성 가능한 한계를 갖춘 메모리 인식 처리

  • 대용량 파일에 대한 청크 데이터 검색

  • 모든 목록 작업에 대한 페이지 매김 지원

  • 노드 유형 필터링

  • 진행 상황 추적

  • 구성 가능한 청크 크기

  • 중단된 작업에 대한 재개 기능

  • 디버그 로깅

  • 구성 파일 지원

Related MCP server: Figma MCP Server

설치

Smithery를 통해 설치

Smithery를 통해 Claude Desktop용 Chunking을 사용하여 Figma MCP 서버를 자동으로 설치하려면:

지엑스피1

수동 설치

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

get_components

청킹 지원이 있는 구성 요소를 검색합니다.

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

get_styles

청킹 지원으로 스타일을 검색합니다.

{
  "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 통해 구성 가능한 청크 크기

  • 메모리 사용량 모니터링

  • 메모리 압력에 따른 자동 청크 크기 조정

  • 청크별 진행 상황 추적

  • 커서를 사용한 재개 기능

모범 사례

  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 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.

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