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. Every set but an illustration 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: the size, canvas, sizing and margin of every set but an illustration set 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. Every set but an illustration set takes base sizes from 16 to 256 (48 to 128 is the usual range for icons), its crisp size set by how many images 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).

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": {
      "generation": "<generation>",
      "baseSize": "<baseSize>"
    },
    "name": "export_set"
  }
}

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 every set but an illustration 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 / baseSize / description
      Previous value: -"The 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)."New value: +"The 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 every set but an illustration 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)."
  2. 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."
  3. Added

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations it discloses substantial behavior: files are scaled from full-resolution source, never from delivered pixels; densities that exceed source pixels are still delivered but flagged 'soft' with a magnitude in the ledger; WebP exports produce PNG in the iOS tree; JPG is rejected against transparent backgrounds. Annotations (readOnly=false, idempotent=true, destructive=false) are consistent with this file-writing, non-destructive behavior.

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?

The purpose is front-loaded in sentence one, but the remainder is a dense wall of run-on sentences that repeatedly restates 'every set but an illustration set' and 'an illustration set' instead of structuring the rules into distinct points. The information mostly earns its place, yet the packaging makes it slower to parse than necessary.

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?

For a tool with four parameters, a 100%-covered schema, and an output schema, the description is amply complete: it covers sizing semantics, per-platform output conventions, edge cases (soft densities, WebP-to-PNG on iOS, JPG alpha rejection), and the unavailability case for legacy sets.

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 schema already documents all four parameters, but the description adds real meaning beyond it: baseSize sizes the batch rather than each file, the even-number/platform-unit convention, the crispBaseSize ceiling for illustration sets, and the format/transparency interaction. It stops short of adding anything about the `quality` parameter or the meaning of the generation id beyond what the schema says.

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?

The first sentence gives a specific verb and resource ('Export an existing set') and enumerates the target platforms and artifact shapes (srcset, iOS imageset, Android res/ buckets, Flutter asset folders), so an agent can immediately distinguish this from generate_*, edit_set, and the list_* siblings.

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?

It states operational boundaries clearly: one batch and one base size per call, a second size means a second call, and pre-editing sets have no source so they cannot be exported. It does not explicitly route the agent to alternatives (e.g., 'call edit_set first to change canvas'), so it stops short of full when/when-not/alternative guidance.

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