Skip to main content
Glama
jornobam

Figma Export MCP

by jornobam

Execute confirmed export plan

execute_export_plan
Idempotent

Start a background job to export Figma assets, upload them to Yandex Disk, and verify results, returning a job ID for tracking.

Instructions

Starts an idempotent background export/upload/verify job and quickly returns its job ID.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
digestYes
plan_idYes
idempotency_keyYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
errorNo
schema_versionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.8/5.0
Behavior4/5

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

The description adds 'background' and 'quickly returns its job ID', explaining the asynchronous non-blocking behavior that is not captured by the annotations. It repeats idempotentHint but also reinforces it in plain language; no statement contradicts the annotations.

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?

A single front-loaded sentence that immediately states the action, async nature, and return behavior. There is no filler or duplicated boilerplate.

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?

Given the output schema, the return value is already specified, and the description covers async behavior and the job concept. However, it omits the workflow precondition that the plan must be confirmed, and it doesn't point to follow-up tools such as get_export_status for monitoring, so agents must infer this from sibling tool names.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Description provides no per-parameter meaning for plan_id, digest, or idempotency_key; with schema description coverage at 0%, this is a real gap. The only hints are indirect: 'idempotent' points to idempotency_key and 'verify' to digest, but the agent cannot tell how to construct or validate these values from the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action ('Starts') on a unique resource type (a confirmed export plan / background export/upload/verify job) and tells the agent it returns a job ID. This clearly separates it from siblings like preview_export_plan, confirm_export_plan, and get_export_status, which describe different phases of the workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'confirmed export plan' in the title and 'Starts ... job' imply this is the execution step after confirmation, but the description itself never states a precondition or names alternatives (e.g., use preview_export_plan to validate, get_export_status to poll). Usage context is implied by the workflow rather than made explicit.

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