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 is short-lived (it expires with the set).
`quality`	No
`iconSize`	No
`expiresAt`	No
`generation`	No

TDQS

A4.5/5.0

Behavior5/5

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

Annotations carry only idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds substantial behavior beyond that: idempotent merge semantics (trees merge by folder, two sizes never collide), the 'soft' blur ledger warnings, cost implications of large base sizes ('cost real megabytes'), the never-withhold-files policy, and the crisp-base-size ceiling fixed at generation — genuinely useful operational disclosure not present in any structured field.

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 content is dense and every clause carries information, so it earns its place, but it is delivered as a single unbroken wall of semicolon-heavy prose that is hard to scan. The core purpose is front-loaded, but the lack of any structural segmentation hurts quick comprehension despite the high information density.

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 complex export tool with four parameters, platform-specific output, and an output schema present, the description is remarkably complete: it covers output layout per platform, the scaling rules, the ledger and 'soft' marking, size limits, cost warnings, and exclusions. Nothing an agent needs to call it correctly or interpret its output is missing.

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 real meaning beyond the schema: the webp→iOS PNG fallback caveat, jpg alpha rejection unless composed over a color, the even-number 16-256 constraint, and that iconSize sizes the batch's longest side rather than each file. These cross-parameter behaviors materially help an agent invoke parameters correctly.

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 ('Export'), a precise resource ('an existing image set'), and a concrete outcome (icons at every density for web, iOS, Android, Flutter, laid out as each platform expects). It details the deliverable (file naming, asset catalogs, density buckets, srcset lines, viewer, ledger) and clearly distinguishes itself from generation/editing siblings by emphasizing it operates on an existing set's full-resolution source.

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 context: one batch per call, one base size per call, and the 48-128 typical range. It states exclusions explicitly — 'Not available for illustrations, or for sets generated before editing existed' — with the reason ('they have no source'). It stops short of naming alternative sibling tools by name, but the conditions for using this tool versus others are 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 targets a clearly distinct operation: three generation tools are explicitly differentiated by output type (single illustration vs. solid-color set vs. transparent set), while reference upload, editing, export, credit checking, and listing are all unambiguous. Cross-references between tools further eliminate any boundary confusion.

Naming Consistency5/5

All eight tools follow the same snake_case verb_noun pattern: check_, create_, edit_, export_, generate_, list_. The three generate_* tools share a common prefix with distinct objects, making the naming predictable and scannable.

Tool Count5/5

Eight tools is well-scoped for a logo/icon generation service: three generation variants, one editing tool, one export tool, one reference upload mechanism, plus account and history utilities. Each tool earns its place without redundancy or bloat.

Completeness5/5

The tool surface covers the full creative lifecycle: reference preparation (create_reference), generation (three variants), post-processing (edit_image_set), delivery conversion (export_icons), and session management (list_recent_generations, check_credits). Deletion is unnecessary because references and downloads expire naturally, so there are no dead ends.

Resources

Need Help?