Skip to main content
Glama
enesjakozh
ArchimedesCrypto

Figma MCP Server with Chunking

by ArchimedesCrypto
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Servidor MCP de Figma con fragmentación

insignia de herrería

Un servidor de Protocolo de Contexto de Modelo (MCP) para interactuar con la API de Figma, con capacidades de fragmentación y paginación que ahorran memoria para manejar archivos grandes de Figma.

Descripción general

Este servidor MCP proporciona una interfaz robusta para la API de Figma con funciones integradas de gestión de memoria. Está diseñado para gestionar archivos Figma de gran tamaño de forma eficiente, dividiendo las operaciones en fragmentos manejables e implementando paginación cuando sea necesario.

Características principales

  • Procesamiento consciente de la memoria con límites configurables

  • Recuperación de datos fragmentados para archivos grandes

  • Soporte de paginación para todas las operaciones de listado

  • Filtrado de tipo de nodo

  • Seguimiento del progreso

  • Tamaños de fragmentos configurables

  • Capacidad de reanudación de operaciones interrumpidas

  • Registro de depuración

  • Compatibilidad con archivos de configuración

Related MCP server: Figma MCP Server

Instalación

Instalación mediante herrería

Para instalar Figma MCP Server con Chunking para Claude Desktop automáticamente a través de Smithery :

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

Instalación manual

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

# Install dependencies
npm install

# Build the project
npm run build

Configuración

Variables de entorno

  • FIGMA_ACCESS_TOKEN : Su token de acceso a la API de Figma

Archivo de configuración

Puede proporcionar configuración a través de un archivo JSON usando el indicador --config :

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

Uso:

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

Herramientas

obtener_datos_del_archivo (Nuevo)

Recupera datos de archivos de Figma con fragmentación y paginación que ahorran memoria.

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

Respuesta:

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

lista_archivos

Enumera archivos con soporte de paginación.

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

obtener_versiones_de_archivo

Recupera el historial de versiones en fragmentos.

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

obtener comentarios del archivo

Recupera comentarios con paginación.

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

obtener_información_del_archivo

Recupera información de archivo con recorrido de nodo fragmentado.

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

obtener_componentes

Recupera componentes con soporte de fragmentación.

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

obtener_estilos

Recupera estilos con soporte de fragmentación.

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

obtener_nodos_de_archivo

Recupera nodos específicos con soporte de fragmentación.

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

Gestión de la memoria

El servidor implementa varias estrategias para administrar la memoria de manera eficiente:

Estrategia de fragmentación

  • Tamaños de fragmentos configurables a través de pageSize

  • Monitoreo del uso de memoria

  • Ajuste automático del tamaño de los fragmentos según la presión de la memoria

  • Seguimiento del progreso por fragmento

  • Capacidad de reanudar el uso de cursores

Mejores prácticas

  1. Comience con tamaños de fragmentos más pequeños (50-100 nodos) y ajústelos según el rendimiento.

  2. Supervisar el uso de la memoria a través de los metadatos de respuesta

  3. Utilice el filtrado de tipo de nodo cuando sea posible para reducir la carga de datos

  4. Implementar paginación para grandes conjuntos de datos

  5. Utilice la función de reanudación para archivos muy grandes

Opciones de configuración

  • pageSize : Número de nodos por fragmento (predeterminado: 100)

  • maxMemoryMB : Uso máximo de memoria en MB (predeterminado: 512)

  • nodeTypes : Filtra tipos de nodos específicos

  • depth : controla la profundidad transversal para estructuras anidadas

Registro de depuración

El servidor incluye un registro de depuración completo:

// 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

Manejo de errores

El servidor proporciona mensajes de error detallados y sugerencias:

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

Solución de problemas

Problemas comunes

  1. Errores de memoria

    • Reducir el tamaño del fragmento

    • Utilice el filtrado de tipo de nodo

    • Implementar paginación

    • Especifique valores de profundidad más pequeños

  2. Problemas de rendimiento

    • Monitorizar el uso de la memoria

    • Ajustar el tamaño de los fragmentos

    • Utilice filtros de tipo de nodo adecuados

    • Implementar el almacenamiento en caché para datos a los que se accede con frecuencia

  3. Límites de la API

    • Implementar limitación de velocidad

    • Utilice la paginación

    • Almacenar en caché las respuestas cuando sea posible

Modo de depuración

Habilite el registro de depuración para obtener información detallada:

# Set debug environment variable
export DEBUG=true

Contribuyendo

¡Agradecemos sus contribuciones! Lea nuestras normas de contribución y envíe solicitudes de incorporación de cambios a nuestro repositorio.

Licencia

Este proyecto está licenciado bajo la licencia MIT: consulte el archivo de LICENCIA para obtener más detalles.

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