Adds comments to ClickUp tasks and notifies the responsible person as part of the orchestration skill.
Exports frames from Figma as PNG images using the Figma API.
Uploads exported files to Google Drive with automatic folder navigation and creation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@figma-drive Export frames from Figma file 042FZHjPyx1TWMO4kzx1ai and upload to Google Drive"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Claude Code Plugin que exporta frames do Figma e faz upload automatico para o Google Drive. Criado para o time de design da Stark.
git clone https://github.com/angelostark/stark-figma-drive-mcp.git
cd stark-figma-drive-mcp
npm install && npm run buildCrie um arquivo .env na raiz (ou configure as variaveis de ambiente):
Variavel | Descricao |
| Personal Access Token do Figma (gerar aqui) |
| Caminho para o |
Aponte o Claude Code para a pasta do repositorio clonado. O arquivo .claude-plugin/plugin.json sera detectado automaticamente, registrando:
MCP Server figma-drive — tools de export e upload
Skill /figma-export-para-drive — orquestra o fluxo completo (Figma + Drive + ClickUp)
No Claude Code, a skill /figma-export-para-drive deve aparecer na lista de skills disponiveis e as tools export_figma_frames, upload_to_drive e figma_to_drive devem estar acessiveis.
Related MCP server: Figma MCP Server
Tool | Descricao |
| Exporta frames do Figma como PNG em alta qualidade |
| Upload para o Google Drive com navegacao automatica de pastas |
| Pipeline completo: Figma export + Drive upload |
/figma-export-para-driveCole o link do Figma quando solicitado. A skill cuida de tudo: export, upload, comentario no ClickUp e notificacao do responsavel.
Exportar frames:
export_figma_frames({
fileKey: "042FZHjPyx1TWMO4kzx1ai",
nodeIds: ["1038:6", "1038:16"],
prefix: "2026-03-17-Stark"
})Upload para Drive:
upload_to_drive({
clientName: "Stark",
date: "2026-03-17",
files: ["/tmp/figma_exports/2026-03-17-Stark-card-01.png"]
})Pipeline completo:
figma_to_drive({
fileKey: "042FZHjPyx1TWMO4kzx1ai",
nodeIds: ["1038:6"],
frameName: "2026-03-17 - Stark"
})O upload navega automaticamente:
Clientes / [cliente] / Cronograma de Conteudo / Artes / [ano] / [mes] / [data]Pastas inexistentes sao criadas automaticamente.
stark-figma-drive-mcp/
├── .claude-plugin/
│ └── plugin.json # Metadata + MCP server config
├── skills/
│ └── figma-export-para-drive/
│ └── SKILL.md # Skill de orquestracao
├── src/ # MCP server source
├── dist/ # Compilado
├── package.json
└── tsconfig.jsonnpm install
npm run buildNode.js 18+
Token do Figma (Personal Access Token)
Credenciais do Google (Service Account com acesso ao Drive)
Exporta frames do Figma como PNG em alta qualidade. Usa a API REST do Figma com batching automatico para evitar timeouts.
| Name | Required | Description | Default |
|---|---|---|---|
| fileKey | Yes | File key do Figma (segmento apos /design/ na URL) | |
| nodeIds | Yes | Node IDs para exportar (ex: ["1038:6", "1038:16"]) | |
| prefix | Yes | Prefixo dos arquivos exportados (ex: "2026-03-17-Stark") | |
| scale | No | Escala do export (default: 2) | |
| outputDir | No | Diretorio de saida | /tmp/figma_exports |
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 discloses automatic batching to avoid timeouts, which is a behavioral trait. However, it does not mention other relevant behaviors like API rate limits, authentication requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second gives implementation detail. No redundant content. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should indicate what the tool returns (e.g., file paths, success status). It mentions exporting to a directory but does not specify the return value. The schema covers all parameters adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds the file key extraction hint but does not explain node IDs or provide additional context beyond the schema. It adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports Figma frames as high-quality PNGs with automatic batching. It uses a specific verb and resource, but does not explicitly differentiate from sibling tools like figma_to_drive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The mention of automatic batching to avoid timeouts is a usage hint, but there is no when-not-to-use or reference to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pipeline completo: exporta frames do Figma e faz upload para o Google Drive. Parse automatico do nome do frame no formato "[DATA] - [NOME]" para determinar cliente e data.
| Name | Required | Description | Default |
|---|---|---|---|
| fileKey | Yes | File key do Figma | |
| nodeIds | Yes | Node IDs para exportar | |
| frameName | Yes | Nome do frame no formato "[DATA] - [NOME]" (ex: "2026-03-17 - Stark") | |
| scale | No | Escala do export (default: 2) | |
| credentialsPath | No | Caminho para o arquivo credentials.json do Google |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behaviors. It mentions automatic parsing of frame names but does not detail other behaviors such as authentication requirements (though credentialsPath is in schema), error handling, overwrite behavior, or what happens on success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that convey the core purpose. It is front-loaded with the primary action, though the language is informal and could be better structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a pipeline tool with no output schema, the description should provide more context on the overall process, return values, and potential side effects. It lacks completeness for effective agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter descriptions are complete in the schema. The description adds marginal context by reiterating the frame name format and parsing logic, but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a complete pipeline that exports frames from Figma and uploads to Google Drive, with automatic parsing of frame names. This distinguishes it from the sibling tools (export_figma_frames and upload_to_drive) which would handle each step separately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this combined pipeline versus the individual sibling tools. It implies usage for the combined workflow but lacks guidance on prerequisites, when-not-to-use, or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Faz upload de arquivos para o Google Drive do cliente. Navega automaticamente a hierarquia: Clientes > [cliente] > Cronograma de Conteudo > Artes > [ano] > [mes] > [data]. Cria pastas inexistentes.
| Name | Required | Description | Default |
|---|---|---|---|
| clientName | Yes | Nome da pasta do cliente no Drive (ex: "Stark") | |
| date | Yes | Data no formato YYYY-MM-DD (ex: "2026-03-17") | |
| files | No | Caminhos dos arquivos PNG para upload | |
| dryRun | No | Se true, apenas navega as pastas sem fazer upload | |
| credentialsPath | No | Caminho para o arquivo credentials.json do Google |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: automatic folder hierarchy navigation, creation of missing folders, dry-run functionality, and credential requirement. This provides sufficient transparency for a file upload tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three concise sentences, front-loaded with the main action, and no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description does not mention return values, error handling, file size limits, or permissions. While the tool is simple, more context could be provided for robustness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds minimal meaning beyond schema—it explains the folder hierarchy implied by clientName and date, but does not elaborate on file types or credentials path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool uploads files to a specific client's Google Drive folder, detailing the automatic navigation of a hierarchy and folder creation. It distinguishes from siblings (Figma-related tools) by focusing on Drive upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies when to use (when uploading to Drive with date hierarchy) but lacks explicit when-not-to-use or alternative tools. Siblings are different enough that confusion is minimal, but no guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The three tools are mostly distinct: export_figma_frames only exports, upload_to_drive only uploads, and figma_to_drive combines both with parsing. There is slight overlap due to figma_to_drive covering the other two, but descriptions clarify the pipeline's additional functionality.
Two tools follow verb_noun snake_case (export_figma_frames, upload_to_drive), but figma_to_drive breaks pattern by using a description phrase. Consistent otherwise.
Three tools is on the lower side but appropriate for a focused figma-to-drive integration. Each tool serves a clear purpose, and the pipeline reduces redundancy.
Covers the core export-upload workflow, but lacks features like listing frames or managing Drive files. The pipeline assumes a specific naming convention, which may limit flexibility.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search, read, preview, create, update, rename, arrange and trash sketches in your Google Drive.
Sync Lightroom, Figma, Dropbox & Canva assets to WordPress and Shopify via natural language.
Sync Lightroom, Figma, Dropbox & Canva assets to WordPress and Shopify via natural language.
Give Claude only the Google Drive files you choose. Every action logged.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/angelostark/stark-figma-drive-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
