figlens

Overview Schema Source Related Servers Discussions Admin

export_batch

Export many nodes from a saved Figma .fig file in one call, one file per item, instead of repeated export calls for icons and photos.

Instructions

Export many nodes of one file in a single call, one file per item; use it instead of repeated export calls for a screen's icons and photos. Each item takes the options export takes (node, out, bounds, scale, quality, maxKb, maxSize, hide; the format follows out's extension) except matchDir. Create the output directories first. At most 64 items, distinct out paths, all inside the configured roots; a malformed item or a path outside the roots fails the whole call before anything is written. Items then export in order: one that fails (a missing or hidden node, a file over maxKb) is reported with its error and the others still export, so check each entry's error. Returns a manifest, no inline images: per item node, path, width, height, bytes, quality, layoutBox, renderBox and warnings, or node, path and error; warnings say when the drawn area reaches past the layout box (a badge or shadow), as export's do. Once the files written reach 256 MiB, the remaining items fail with a budget error; export them in another call.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "file": "<file>",
      "items": "<items>"
    },
    "name": "export_batch"
  }
}

Input Schema

Name	Required	Description	Default
`file`	Yes	the saved .fig: a local path (absolute recommended), or gs://bucket/object using gcloud; remote sources are unavailable with --root
`items`	Yes	1-64 objects {node, out, bounds?, scale?, quality?, maxKb?, maxSize?, hide?}, each as the export tool's parameters of those names

Output Schema

Name	Required	Description
`count`	Yes
`items`	Yes	in request order: node, path and either the export fields (width, height, bytes, quality, layoutBox, renderBox, warnings) or error
`failed`	Yes	items with an error; the others were written

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.11.3Nov 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does: it discloses the validate-then-write all-or-nothing phase ('a malformed item or a path outside the roots fails the whole call before anything is written') versus the per-item partial-failure phase afterwards, the in-order execution, the 256 MiB write budget, and the warning semantics. These are exactly the traits an agent cannot infer from schema or annotations.

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?

Front-loaded with purpose and the sibling comparison, then constraints, then failure semantics, then budget — a sensible ordering. It is dense (a single long paragraph) and the return-manifest sentence partly restates the output schema, so a minor trim is possible, but nearly every sentence earns its place for a complex batched tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and the description does not depend on it, yet still covers what an agent needs: directory creation, root/path validation, the 64-item cap, per-item error checking, warning meaning, and the write budget with a recovery path. Nothing required to invoke it correctly is missing despite having no annotations.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real relational meaning: each item takes the same options as the sibling export except matchDir, the format follows out's extension, out paths must be distinct and inside the configured roots, and maxKb failures are item-level rather than call-level. It stops short of explaining scale/maxSize interaction, which the schema already covers.

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 verb and resource plus scope ('export many nodes of one file in a single call, one file per item'), and explicitly positions itself against the sibling single-node 'export' tool by saying to use it instead of repeated export calls. An agent can distinguish it from export without opening the schema.

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

Usage Guidelines5/5

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

Names the alternative ('repeated export calls') and the condition that selects this tool (a screen's icons and photos), plus a required precondition ('Create the output directories first') and a redirect for the budget case ('export them in another call'). Routing guidance is explicit rather than inferred.

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

Deploy Server