Logospell

export_icons

Idempotent

Export an existing image set as icons, free: every subject at the base size you name and at every density the web, iOS, Android and Flutter need, laid out as each expects (web files with @2x and @3x and an srcset line, an iOS asset catalog with one imageset per icon, Android res/ density buckets, Flutter asset folders with the pubspec lines), plus a viewer and a ledger. 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 icons come from the set's full-resolution source, so an icon is the set as it is currently delivered, scaled: its size, canvas, sizing and margin all carry (edit_image_set changes them), while no pixel comes from a delivered image. Files up to 3x the 1x size (4x on Android) are always delivered; 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. Large base sizes cost real megabytes for files the ledger will mark soft; 48 to 128 is the usual range. How large a set's icons can be was fixed when it was generated, by its subject count: every generation result and list_recent_generations state the batch's crisp base size, and the ledger says where a larger size went past the source. Not available for illustrations, or for sets generated before editing existed (they have no source).

Input Schema

TableJSON Schema

Name	Required	Description
`format`	No	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.
`quality`	No	1 to 100 for webp and jpg; ignored for png. Left out, the set's current quality (90 when it has none).
`iconSize`	Yes	The base size: one even number from 16 to 256 that each platform reads in its own unit (CSS px on the web, pt on iOS, dp on Android). It sizes the batch, not each file: every icon is the set's delivered image scaled so the batch's longest side is this number, so nothing exceeds it, a set delivered on one canvas gives icons that all match it, and a set whose images wrap their own subjects gives icons that differ the same way. The export holds files up to 3x it (4x on Android).
`generation`	Yes	The 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

TableJSON Schema

Name	Required	Description
`format`	No
`ledger`	No	The 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, subject, density and pixel size. Also inside the zip as ledger.json.
`zipURL`	No	The export zip; fetch and extract it as your first action after the call, the link expires with the set.
`quality`	No
`iconSize`	No
`expiresAt`	No
`generation`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 29, 2026

addedOutput schema / properties / ledger / description

Added value: +"The 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, subject, density and pixel size. Also inside the zip as ledger.json."

changedOutput schema / properties / ledger / properties / sizing / description

Previous value: -"The set's sizing the export followed: relative or fit."New value: +"The set's sizing the export followed: relative or fill."

Changed1 schema field changedSep 3, 2026

changedOutput schema / properties / zipURL / description

Previous value: -"The export zip; fetch and extract it as your first action after the call, the link is short-lived (it expires with the set)."New value: +"The export zip; fetch and extract it as your first action after the call, the link expires with the set."

AddedSep 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare non-destructive, idempotent, closed-world behavior, but the description adds substantial operational detail: free, batch-per-call, source-based scaling, no delivered pixels, guaranteed density files, ledger softness, and cost implications. It discloses what is written and when output may be soft, going well beyond annotation hints without contradiction.

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?

The core purpose is front-loaded in the first sentence, and most clauses convey unique constraints about platform outputs and export behavior. However, it is a single dense paragraph with some redundancy, so it is not maximally tight for a 4-parameter 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?

Given the existence of an output schema, the description need not explain return values. It covers the key usage and behavioral context: source basis, limitations, cost, softness, and platform deliverables. The definition is complete for an agent to call it correctly.

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. The description adds practical parameter guidance not in the schema, such as the usual 48–128 base-size range, one-batch/one-size-per-call constraints, and how names carry size to avoid collisions; it adds little for format or quality beyond what the schema already provides.

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: export an existing image set as icons, with clear platform scope (web, iOS, Android, Flutter). It also distinguishes itself from mutation siblings like edit_image_set by focusing on exporting from existing source rather than creating or modifying a set.

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?

Provides clear context: one export per call, one batch and one base size per call, and explicit exclusions for illustrations and pre-editing sets. It names list_recent_generations and edit_image_set for supporting tasks, but does not name a sibling alternative to use instead for the export operation itself.

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

All Logospell tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?