Skip to main content
Glama

export_set

Idempotent

Export an existing set for the web, iOS, Android and Flutter, free: every image at the base size you name and at every density each platform needs, laid out as each expects (web files with @2x and @3x and an srcset line, an iOS asset catalog with one imageset per image, Android res/ density buckets, Flutter asset folders with the pubspec lines), plus a viewer and a ledger. An image or character set exports as icons; an illustration set exports its scenes whole, for the illustrations in an app or site. One export per call: one batch of a set (a set that grew over several calls is exported batch by batch; the trees merge by folder) at one base size (a second size is a second call; names carry the size, so two sizes never collide). The files come from the set's full-resolution source, so each is the batch as it is currently delivered, scaled: an image or character set's size, canvas, sizing and margin all carry (edit_set changes them), and an illustration set's shape; no pixel comes from a delivered image. How large a batch exports crisp is its crispBaseSize: every generation and edit_set result states it, and list_recent_generations and get_generations report it. An image or character set takes base sizes from 16 to 256 (48 to 128 is the usual range for icons), its crisp size set by how many subjects or variations it holds at generation, and edits to its size, canvas, margin or sizing can move it; files up to 3x the 1x size (4x on Android) are always delivered, and where a density would enlarge a subject past its source pixels the ledger says so per tree ("soft": some blur) and by how much, never withholding a file. An illustration set takes base sizes from 16 up to its crispBaseSize, a quarter of the longest side its scenes were drawn at, so its export is always crisp. Not available for sets generated before editing existed (they have no source).

Input Schema

NameRequiredDescriptionDefault
formatNopng, webp, or jpg. Left out, the set's current format. iOS asset catalogs take no WebP, so a webp export's iOS tree is PNG at the same pixels (the ledger says so). jpg has no alpha: rejected while the set's background is transparent.
qualityNo1 to 100 for webp and jpg; ignored for png. Left out, the set's current quality (90 when it has none).
baseSizeYesThe base size: one even number that each platform reads in its own unit (CSS px on the web, pt on iOS, dp on Android), from 16 to 256 for an image or character set and from 16 to its crispBaseSize for an illustration set. It sizes the batch, not each file: every file is the batch's delivered image scaled so the batch's longest side is this number, so nothing exceeds it, a set delivered on one canvas gives files that all match it, and a set whose images wrap their own subjects gives files that differ the same way. The export holds files up to 3x it (4x on Android).
generationYesThe id of the set to export - the random segment of its download URL, as list_recent_generations returns it. One batch per call.

Output Schema

NameRequiredDescriptionDefault
formatNo
ledgerNoThe export's account of itself: per tree (web, ios, android, flutter) the densities, format, largest file and fidelity (crisp, or soft, meaning some blur, with the largest enlargement past source pixels), and every file with its tree, image name, density and pixel size. Also inside the zip as ledger.json.
zipURLNoThe export zip; fetch and extract it as your first action after the call, the link expires with the set.
qualityNo
baseSizeNo
expiresAtNo
generationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / format / description
      Previous value: -"png, webp, or jpg. Left out, the set's current format. iOS asset catalogs take no WebP, so a webp export's iOS tree is PNG at the same pixels (the ledger says so). jpg has no alpha: rejected for a transparent set unless the set is currently composed over a color."New value: +"png, webp, or jpg. Left out, the set's current format. iOS asset catalogs take no WebP, so a webp export's iOS tree is PNG at the same pixels (the ledger says so). jpg has no alpha: rejected while the set's background is transparent."
  2. Added

TDQS

A4.3/5.0
Behavior5/5

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

With readOnlyHint=false, destructiveHint=false and idempotentHint=true already declared, the description adds substantial behavior: files derive from the full-resolution source rather than delivered pixels, 3x/4x caps, the "soft" ledger annotation when a density exceeds source pixels, jpg rejection under a transparent background, and iOS WebP being downgraded to PNG. No statement conflicts with 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first clause, but the body is a dense, heavily parenthesized wall of text where base-size rules and crispness behavior are repeated across sentences. For a four-parameter export tool this is over-written, and several sentences re-document what the schema already states.

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, so return values need not be explained, and the description thoroughly covers batching, base-size ranges by set type, format/alpha interactions, and platform-specific layout. An agent has everything needed to call it correctly without opening other tools.

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 all four parameters are already documented in the schema, and much of the description's baseSize/format material restates it. The description's added value (one batch per call, size-collision avoidance, per-platform unit interpretation) is real but marginal against a fully covered schema, warranting the baseline 3.

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?

Opens with a precise verb+resource ("Export an existing set") and immediately names the target platforms and the artifacts produced (web files with srcset, iOS asset catalog, Android res/ buckets, Flutter folders). It further distinguishes behavior by set type (image/character = icons, illustration = scenes whole), so it is unmistakable against siblings like edit_set or the generate/extend tools.

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

Usage Guidelines4/5

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

Gives clear operational context: one export per call, one batch of a set, one base size per call, and a second size being a second call. It also states an exclusion ("Not available for sets generated before editing existed"). It never names a sibling as the alternative for a different task, so it stops short of a full 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources