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
`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. Dates show when Glama detected each change.

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 provide readOnlyHint=false and destructiveHint=false, so the definition adds substantial behavioral context: files up to 3x/4x are always delivered, soft enlargements are reported in the ledger, 'no pixel comes from a delivered image', large base sizes can cost real megabytes, and iOS trees fall back to PNG for WebP sets. These are exactly the non-obvious behaviors an agent needs to know.

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 description is long and dense, but nearly every sentence carries a distinct constraint or caveat: platform layouts, softness reporting, size ranges, availability, and format quirks. The core action is front-loaded, and the extra detail earns its place given the tool's complexity.

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?

With a full input schema, an output schema, and annotations, the description still covers key edge cases: format fallbacks, alpha rejection for JPG, size collision semantics, soft scaling disclosure, and unsupported source types. An agent has enough information to call this tool correctly in complex scenarios without needing to inspect other tools.

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 goes beyond the schema by explaining that iconSize sizes the batch rather than each file, that names carry the size to avoid collisions, and that generation is 'the random segment of its download URL, as list_recent_generations returns it.' This adds real selection guidance beyond the property descriptions.

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 states a specific verb and resource: 'Export an existing image set as icons, free.' It then describes the full output scope (web, iOS, Android, Flutter, viewer, ledger), which clearly distinguishes it from sibling tools like generate_image_set or edit_image_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?

The description gives strong usage constraints: one export per call, one batch per generation, one base size per call, and explicit exclusions ('Not available for illustrations, or for sets generated before editing existed'). It does not name alternative tools explicitly, but the exclusions and references to edit_image_set and list_recent_generations make when-to-use reasonably clear.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation5/5

Each tool has a clearly distinct role: generation is split by output type (single illustration vs. solid-color set vs. transparent set), and the remaining tools handle references, delivery editing, icon export, credit checking, and listing. The three generation tools are heavily cross-referenced with explicit guidance on when to use each, leaving no boundary ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (check_credits, create_reference, edit_image_set, export_icons, generate_illustration, list_recent_generations). The two set-generation variants differ by a descriptive adjective but still follow the same generate_*_set shape, so the naming pattern remains predictable.

Tool Count5/5

Eight tools is well-scoped for an image generation service: three generation variants, one reference-upload helper, one delivery editor, one export tool, one credit checker, and one history/retrieval tool. Each tool serves a distinct workflow step without unnecessary redundancy.

Completeness4/5

The core lifecycle is well covered: generate (all three modes), upload references, edit delivered sets, export icons, check credits, and retrieve past generations. The only notable gap is that illustrations cannot be edited or re-delivered after generation, though the tool descriptions make this an explicit design constraint rather than an oversight.

Resources

Need Help?