AI-agent image generation: cohesive sets & illustrations. Resize a set or export icons, free.
Check how many image generation credits remain on your account: one balance shared by your MCP calls and the logospell.com generate page.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| remaining | Yes | Credits remaining on the API key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds useful context about the shared account balance, enhancing understanding without contradicting structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the exact purpose with no wasted words. The description is both concise and structurally effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with comprehensive annotations and an output schema, the description is fully sufficient. It adds the key nuance of a shared balance, covering all contextual needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is no parameter description needed beyond the schema, which correctly shows an empty object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks remaining image generation credits, with specific verb 'Check' and resource 'credits'. The added detail about shared balance between MCP calls and the generate page distinguishes it from sibling generation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context makes it obvious this is for verifying available credits before generation, but no explicit when-to-use or alternative comparisons are given. Since no sibling performs the same function, this is not a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an upload slot for a reference image. Returns an upload URL and a ref_ token: upload the image file with one shell command (curl -T ''), then pass the ref_ token to the reference-image parameter you are filling - every parameter that takes reference images names this tool in its description. This is the ONLY way to supply reference images, and those parameters accept ref_ tokens and nothing else. Image data never goes inside a tool call: a call is JSON, so an embedded image would have to be base64 text that you, the caller, must emit character by character - slow, error-prone, and enough to exhaust your context window. The upload moves the bytes out-of-band instead: a plain HTTP PUT of the raw file, so any HTTP client works; if your environment has no way to send one, install curl. And when the image you want is from one of your OWN recent Logospell generations, skip the upload entirely: pass sourceGeneration and sourceImage and the server copies it directly - the shortcut for extending an existing set in its own style. Accepts PNG, JPEG, or WebP, each at most 500KB, each side between 64px and 768px - resize before uploading if needed; larger reference images do not improve results. A reference is private to your API key and can be used in any number of later calls; it expires 7 days after its last use or re-upload (each use restarts the window), so uploading a few references once can serve a whole session of work. Costs no credits.
| Name | Required | Description | Default |
|---|---|---|---|
| sourceImage | No | Optional, with sourceGeneration: the delivered image filename to use as the reference, exactly as listed by list_recent_generations or the generation's manifest (e.g. "a_lotus_cradling_a_glowing_pearl.png"). An image larger than the reference limits is downscaled to fit automatically. | |
| sourceGeneration | No | Optional, with sourceImage: fill this reference from one of your own recent generations instead of uploading a file. Pass the generation id - the random segment of its download URL (.../download/<id>/images.zip), also returned by list_recent_generations. The image is copied server-side; nothing is uploaded. |
| Name | Required | Description |
|---|---|---|
| ref | Yes | |
| expiresAt | Yes | |
| uploadURL | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the sparse annotations by disclosing significant behavioral traits: image data never goes inside a tool call, uploads happen out-of-band via HTTP PUT, references are private to the API key, expire 7 days after last use, restart their expiry window on each use, and cost no credits. It also details format and size constraints. There is no contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place by preventing a specific failure mode: embedded base64, skipped upload steps, wrong file formats, oversized images, missing curl, expiry surprises, or unnecessary credit use. It is front-loaded with the core purpose and the single most important constraint, then builds out details in a logical order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the full workflow: creating the slot, uploading with curl, passing the token, using the sourceGeneration shortcut, file constraints, privacy, expiry, and cost. Since it also names the output (upload URL and ref_ token) and the output schema is present, nothing an agent needs to invoke or complete the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already thoroughly documents sourceImage and sourceGeneration. The description adds value by connecting these parameters to the upload workflow, explaining the decision rule for using them ('skip the upload entirely') and clarifying that the server copies the image directly. This is meaningful but not essential ontop of the already-rich schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create an upload slot for a reference image,' and it explicitly states what the tool returns: an upload URL and a ref_ token. It further distinguishes itself from any alternative path by declaring, 'This is the ONLY way to supply reference images.' This makes the tool's role unambiguous and clearly separates it from the generation-oriented sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit instructions on when to use the tool, how to complete the upload, and when to bypass the upload entirely: 'when the image you want is from one of your OWN recent Logospell generations, skip the upload entirely: pass sourceGeneration and sourceImage.' It also states that every parameter accepting reference images names this tool, leaving no doubt about when the tool is applicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change how an existing image set is delivered, without generating again: its width and height (both, one, or neither, exactly as on the set tools), its canvas when no size is fixed (one canvas for the whole set, or each image wrapped around its own subject), its minimum margin, its sizing (relative or fill), its format and quality, and for a transparent set the background color it is composed over. The set is delivered again from its full-resolution source and its download is replaced in place: the same download URL now serves the new delivery, and list_recent_generations reports the new levers. Free; no credits are spent. Style, subjects and references are generation and cannot be edited - a different picture is a new set.
A lever left out keeps its current value, so one call can change one thing. Any earlier state, the original delivery included, is one edit away: nothing is kept as history because the same levers always produce the same bytes. Editing never extends a set's download window.
jpg has no alpha: asking for jpg on a transparent set composes the images over white unless the same call gives a background color; jpg together with background "transparent" is rejected. background applies to transparent sets only. Not available for illustrations, or for sets generated before this tool existed (they have no source).
| Name | Required | Description | Default |
|---|---|---|---|
| reset | No | true restores every lever to the first delivery's (the set as it was generated), read from the set's own record; any other lever given in the same call is applied on top of that. | |
| width | No | New delivered width in pixels, or 0 to stop fixing the width. Left out, the current width stays. Width and height combine exactly as on the set tools: both fixed is an exact box, one fixed lets the other hug each subject, neither is native size. | |
| canvas | No | With NEITHER width nor height fixed, what the images land on: uniform (the default) puts the whole set on one canvas, the size it was generated at, every image alike; subject wraps each image around its own subject, so the images differ in size the way the subjects do. Says nothing when a size is fixed. Left out, the current value stays. | |
| format | No | New format: png, webp, or jpg. Left out, the current format stays. jpg has no alpha: on a transparent set it composes the images over white unless a background color is given in the same call. | |
| height | No | New delivered height in pixels, or 0 to stop fixing the height. Left out, the current height stays. | |
| sizing | No | New sizing: relative keeps the sizes the model gave the subjects in relation to one another (one scale for the set); fill scales each subject on its own to fill the frame less the margin, so every image reads at the same visual weight, at the cost of relative size and of enlarging subjects smaller than the frame (the result reports by how much). Left out, the current sizing stays. | |
| quality | No | New quality (1-100) for webp and jpg; ignored for png. Left out, the current quality stays. | |
| background | No | Transparent sets only: a #RRGGBB color composes every image over it and delivers an opaque set; "transparent" restores the alpha. Left out, the current background stays. Rejected on a solid-background set, whose color is in its pixels and cannot change. | |
| generation | Yes | The id of the set to edit - the random segment of its download URL, as list_recent_generations returns it. One batch of a set per call; a set that grew over several calls is edited batch by batch. | |
| minimumMargin | No | New minimum margin in pixels around each subject, with the set tools' bounds. Left out, the current margin stays. |
| Name | Required | Description |
|---|---|---|
| width | No | |
| height | No | |
| images | No | |
| levers | No | |
| zipURL | No | |
| expiresAt | No | |
| generation | No | |
| deliveredAt | No | |
| iconCeiling | No | The largest base size, in pixels, at which export_icons keeps every density of this set crisp at these levers; absent when no base size does. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, it discloses that the download URL is replaced in place, list_recent_generations reflects new levers, no credits are spent, no history is kept, deterministic bytes result from identical levers, and the download window is never extended. It also explains jpg alpha limitations and background constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized and front-loaded with the core purpose, but it repeats some details that already appear in the parameter schema, such as jpg alpha behavior and width/height combination rules. Still, every major behavioral constraint earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 10-parameter tool, the description is remarkably complete: it covers eligibility, cost, idempotency, history behavior, download lifecycle, format edge cases, and restrictions. Combined with the detailed schema and output schema, an agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with detailed descriptions, so the baseline is 3. The main description adds cross-cutting semantics such as omitted levers keeping current values, reset restoring the first delivery, and identical levers producing identical bytes, which goes beyond the individual parameter entries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Change how an existing image set is delivered, without generating again.' It clearly distinguishes itself from generation tools by stating style, subjects, and references cannot be edited, and that a different picture is a new set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear when-to-use context: edit delivery of an existing set without regenerating. It also gives explicit when-not-to-use boundaries: not for illustrations, not for sets without a source, and not for changing generative content. This effectively routes the agent toward generation tools for new pictures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| 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 |
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.
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.
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.
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.
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.
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.
Generate a single composed illustration from a prompt - a scene, environment, hero image, banner, character portrait, or any standalone picture. (For a SET of separate isolated subjects sharing one style - icons, sprites, asset packs - use generate_image_set for solid-color backgrounds, or generate_transparent_image_set for transparent backgrounds, instead.) Returns a zip download URL: the image plus a prompt.json recording what you asked for, plus an index.html viewer. Each call costs 1 credit. Run generation calls sequentially, never in parallel - only one generation runs at a time per API key.
The prompt describes the picture and is used as written (no template, no appended instructions); do not put the pixel size in it - put the size in the width and height arguments. width and height must be one of the supported pixel pairs below; any other pair is rejected. These are the maximums offered - nothing larger is available. Each line is one shape: the first pair is that shape's largest size, the rest are exact proportional downscales of it.
Prompt craft, since each call costs a credit: name the light and the time of day (cold blue twilight, one warm lamp from the left), because lighting carries the mood of a single picture; fix the camera (wide establishing shot, three-quarter portrait, viewed from the doorway) so the composition commits to one vantage point; ask for open space on a named side when text will be laid over the picture later; and say no text or lettering unless a word on a sign is the point, since lettering inside a picture is unreliable and titles are better added afterwards.
2816x1584, 1408x792, 704x396 2048x2048, 1024x1024, 512x512, 256x256 1456x2912, 728x1456, 364x728 3200x1440, 1600x720, 800x360 2912x1456, 1456x728, 728x364 1664x2496, 832x1248, 416x624 2496x1664, 1248x832, 624x416 1776x2368, 888x1184, 444x592 2368x1776, 1184x888, 592x444 1584x2816, 792x1408, 396x704 1440x3200, 720x1600, 360x800
Formats: png (default, lossless), jpg, webp. quality (1-100) applies to jpg and webp; default 90. Prompt max length: 2500 characters. A prompt that does not describe a picture is rejected. unpackTo: a directory on your local filesystem to extract the downloaded zip into. filename: name for the image file inside the zip (default illustration.).
If a "Rate limit exceeded" error is returned, wait the suggested number of seconds before retrying. Do not retry immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | Output width in pixels. Must form one of the supported (width, height) pairs listed in the tool description. | |
| format | No | Output format: png (default, lossless), jpg, or webp. | |
| height | Yes | Output height in pixels, paired with width per the supported list in the tool description. | |
| prompt | Yes | What the illustration should depict - a scene, environment, hero image, banner, character, or any single composed picture. Used as written; a prompt that does not describe a picture is rejected. Do not put the pixel size here; use width and height. | |
| quality | No | Image quality for jpg/webp (1-100). Defaults to 90. | |
| filename | No | Name for the image file inside the zip. Defaults to illustration.<ext>. | |
| unpackTo | No | Path on the caller's local filesystem where the generated illustration should be saved. The server does NOT write here. After this call returns, you (the calling client) must download illustration.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL expires (the result states when). |
| Name | Required | Description |
|---|---|---|
| width | No | |
| format | No | |
| height | No | |
| zipURL | No | |
| unpackTo | No | |
| expiresAt | No | |
| remaining | No | |
| manifestURL | No | |
| imageFilename | No | |
| rejectedPrompt | No | Present only when the request was rejected because the prompt does not appear to describe a picture: the submitted prompt. No generation ran and nothing was charged; revise the prompt and resubmit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses many behavioral details beyond annotations: the return payload is a zip download URL containing image, prompt.json, and index.html; each call costs 1 credit; only one generation runs at a time per API key; unsupported pixel pairs are rejected; rate-limit errors require waiting the suggested time; and the unpackTo parameter requires the client to download and extract locally. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured and front-loaded with the core purpose and sibling differentiation. Each section—alternatives, return format, cost/concurrency, parameter constraints, prompt craft, pixel pairs, formats, and error handling—earns its place given the tool's complexity. It could be tightened slightly, but the length is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return value (zip URL contents), cost, concurrency rules, parameter constraints, error handling, and the local file-saving protocol. Combined with the rich input schema and output schema, an agent has everything needed to invoke this tool correctly and to react to the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema covers 100% of parameters, the description adds substantial meaning beyond the schema: it lists the exact supported (width, height) pairs and their downscale relationships, specifies prompt max length and rejection criteria, explains format defaults and quality behavior, and clarifies that unpackTo does NOT make the server write locally but instead directs the client to download and extract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Generate a single composed illustration from a prompt' with concrete examples (scene, environment, hero image, banner, character portrait), clearly identifying it as a single-picture tool. It also distinguishes itself from siblings by explicitly pointing to generate_image_set and generate_transparent_image_set for sets of separate subjects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use alternatives: 'For a SET of separate isolated subjects... use generate_image_set... or generate_transparent_image_set... instead.' It also provides prompt-craft guidance, cost warnings, and the critical constraint that generation calls must run sequentially, never in parallel.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a cohesive SET of custom images on a SOLID-COLOR background, each one a separate isolated subject sharing one background and one visual style (icons, logos, game assets, UI elements, sprite/asset packs). The style parameter says how everything is drawn; the subjects parameter says what to draw. The style can also come from reference images via the styleReferences parameter - alone, or best combined with the style text (text plus references holds a style tightest), so an existing set can be extended in its original style across many calls. Returns a zip download URL. Each call costs 1 credit. Run generation calls sequentially, never in parallel - only one generation runs at a time per API key.
For TRANSPARENT-background output, use generate_transparent_image_set instead (1 credit per call).
For a SINGLE composed picture or a full-bleed scene (hero image, banner, character portrait, environment), use generate_illustration instead.
Output formats: PNG (lossless), JPEG, or WebP. Images can be delivered at a fixed width and height, at one fixed axis with the other hugging each subject, or at their native resolution.
Size and quality considerations: Leaving width and height unset delivers images at their native resolution with zero scaling, which produces the highest quality results and is recommended when images will be post-processed, composited, or resized downstream. Native output dimensions vary between generations and track the subject count - roughly 650-950px per side for small sets, down to roughly 400-650 at the full 18; fewer subjects means larger native images. Fixing width and height (e.g. 512 and 512) guarantees consistent dimensions across all images and generations but applies resampling which may soften fine details; fixing one axis lets each image keep its subject's own proportion on the other.
IMPORTANT - style and subject description rules for best results: The style applies to every image in the set, so it is what keeps them visually consistent. Put HOW the images are drawn (technique, palette, surface treatment) in the style, and make each subject description only about WHAT that one subject is, not how it looks. A quick test for any phrase: is it WHAT the subject is, or HOW it is drawn? HOW belongs in the style, shared across the set.
Get the style and the subject descriptions right with the user before you call. When their request puts how an image is drawn, a background, or a scene into a subject description (or names the subjects to draw in the style rather than as separate entries in the subjects list), fix it as you compose the call: routine moves of shared technique into the style you can just make, but when a change drops or alters something they explicitly asked for, tell them what you are adjusting and why first. Each call costs a credit, so it is worth getting this right up front rather than spending one on a framed or scene-filled result.
The style describes the visual treatment of the images (e.g. 'watercolor', 'pixel art', 'stained glass'). It must NOT mention background color, image count, layout, or sizing.
Do not list the subjects to draw in the style (e.g. 'illustrations of a fox, an owl, and a deer'); the style is only the shared visual treatment, and the subjects belong in the subjects list, one per entry. A category or theme word is fine (e.g. 'insect illustration').
Do not put background color or background descriptions in the style or subject descriptions.
Avoid framing the style as a type of painted canvas ('oil painting', 'acrylic painting', 'gouache painting', 'pastel painting'). These tend to produce each image as a rectangular framed canvas with its own colored background, rather than an isolated subject. Prefer 'illustration' or a specific technique: 'watercolor illustration', 'pen-and-ink sketch', 'ink wash', 'relief-etching', 'pastel drawing', 'woodblock print'.
Avoid color-field or atmospheric phrasings in the style ('luminous backgrounds of violet, rose, and gold', 'set against jewel-tone fields', 'dreamlike rainbow atmosphere'). These instruct the image model to fill each image with colored atmosphere, producing framed compositions rather than isolated subjects. Describe only the linework, palette, and technique of the subjects themselves.
Do not describe an aged, weathered, cracked, or textured surface, ground, wall, panel, or paper that the whole artwork sits on ('on aged wood', 'cracked fresco wall', 'aged parchment surface'); name the art tradition(s) or style(s) instead ('fresco-style illustration'). Texture that belongs to a subject's own material is fine ('a weathered bronze shield', 'a cracked ceramic vase').
No captions, labels, or annotations. Text that is part of the depicted object is fine (e.g. 'STOP' on a stop sign, 'EXIT' on an exit sign).
No grid lines, borders, frames, or separators.
No overlapping or collage-style arrangements.
Do not connect the subjects to each other or give them shared physical elements: no wires, cords, chains, ropes, ribbons, vines, or threads running between subjects, no frame or banner they share, no phrasing like 'connected by' or 'strung together', and no single continuous line or tube forming multiple subjects. Each subject must be drawable in complete isolation; connections inside one subject (a chain on an amulet, laces on a boot) are fine.
No dramatic/long drop shadows (subtle shadows are fine).
Image descriptions should describe WHAT to depict, not where to position it.
Each image is ONE isolated subject, not a scene. Describe the subject with its pose or action and anything it directly holds, rides, or interacts with, but not the surrounding setting, environment, landscape, or sky. For a single composed scene (a figure set within an environment), use generate_illustration instead.
Do not use size words (large, tiny, small, etc.) on the overall image subject (e.g. 'a large elephant', 'a tiny mouse') - all images are produced at the same size. Size words on details within the image are fine (e.g. 'a plate with a small insignia').
Maximum 18 images per generation. Do not put the image count in the style.
Subjects must be distinct: entries that differ only in case, punctuation, or spacing count as the same subject and the call is rejected. Explicit filenames must be distinct too (a different extension alone is not distinct).
The style must actually describe a visual style, and each subject must name a drawable subject; text that does not is rejected.
Style description max length: 500 characters. Image description max length: 200 characters each.
Size: width and height are separate parameters, each 256 to 512 pixels when given. Both given is an exact box; one given fixes that axis and the other hugs each subject (so images in the set differ on it, and it may fall below 256); neither given delivers native resolution, which is also the path to larger images.
Sizing: relative (the default) keeps the sizes the model gave the subjects in relation to one another, one scale for the whole set; fill scales each subject on its own to fill its frame less the margin, the icon-set convention, giving up relative size and enlarging subjects smaller than the frame (the result says by how much). Both can be changed later with edit_image_set.
Icons: the subject count sets how large a batch's icons can later be exported with export_icons, crisp at every density: about a 136px base size with 13 to 18 subjects, 160 with 10 to 12, 180 with 7 to 9, 192 with 5 or 6, 256 with 4 or fewer. Every generation result states its batch's own crisp base size.
If the style check returns a suggested cleanup, show the user the specific changes and get their confirmation, then resubmit the approved prompt with validation set to "skip" so it generates exactly as approved (resubmitting without "skip" re-runs the check and may return further suggestions). See the validation parameter for when to use "skip" and "auto-apply".
If a "Rate limit exceeded" error is returned, wait the suggested number of seconds before retrying. Do not retry immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | Visual style for all images, e.g. flat minimalist, hand-drawn sketch, 3D glossy, pixel art. Text that does not describe a visual style is rejected. Provide this, styleReferences, or both - together they hold a style most tightly (the text pins the style, the references show it applied), which is the recommended way to extend an existing set across multiple calls. | |
| width | No | Delivered width in pixels. Give both width and height for an exact box (every image lands on it, one uniform scale, the shorter axis padded); give only one and the other axis hugs each subject at that scale plus the margin (so images in the set differ on it); give neither and images arrive at their native size with no scaling or distortion - the highest detail, though dimensions then vary between generations. The per-axis range is given in the tool description; a given axis outside it is rejected, and the hugging axis is whatever each subject needs. A fixed size guarantees consistent dimensions across images and generations but applies Lanczos resampling which may soften fine detail; if the user will post-process the images, recommend leaving both unset. | |
| format | No | Output format: png, jpg, or webp. Defaults to png. | |
| height | No | Delivered height in pixels; see width for how the two combine (both: an exact box; one: the other axis hugs each subject; neither: native size). | |
| sizing | No | How subjects are scaled. relative (the default) keeps the sizes the model gave them in relation to one another: one scale for the whole set, so a small subject stays small in its frame. fill scales each subject on its own to fill the frame less the margin, touching it on one axis, so every image reads at the same visual weight (icon-set convention); that gives up relative size and enlarges any subject smaller than the frame, which the result reports when it happens. | |
| quality | No | Image quality for jpg/webp (1-100). Defaults to 90. | |
| subjects | Yes | Either a list of subject names (e.g. ["home", "search"]) or objects with description and filename (e.g. [{"description": "compass rose", "filename": "overview.webp"}]). Each subject must name a drawable subject and be distinct: entries differing only in case, punctuation, or spacing are rejected as the same subject. A subject with no Latin letters or numbers (a name written entirely in another script) needs the object form with a filename, since delivered files are named in ASCII. Subject text can use only letters, numbers, dashes, spaces, and apostrophes, and must start and end with a letter or number. | |
| unpackTo | No | Path on the caller's local filesystem where the generated files should be saved. The server does NOT write here. After this call returns, you (the calling client) must download images.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL expires (the result states when). | |
| background | No | Background as a 6-char hex color #RRGGBB (e.g. #ffffff, #2c3e50). Default is #ffffff. For transparent output, call the generate_transparent_image_set tool instead - this tool only produces solid-color backgrounds. Do not mention background in the style or subject descriptions. | |
| validation | No | How to handle the automatic style/subject check before generating. One of: suggest (the default) - if the style and descriptions need cleanup for a consistent set, the cleaned version is returned as a suggestion for you to review before any image is generated; skip - skip the cleanup suggestions and generate exactly as given (the non-drawable-content and repeated-subject rejection rules above still apply; no mode skips them), set this when resubmitting a prompt you already revised from a previous suggestion (so your approved wording is used as-is and not re-checked, which avoids further suggestions) or when you are confident the prompt is already clean; auto-apply - if cleanup is needed, apply it and generate in one step without returning a suggestion. Omit for the default. | |
| minimumMargin | No | Minimum margin in pixels around each subject. Defaults to 20. At most 15% of the smallest given axis when width or height is given, at most 80 when neither is; negative values are rejected. With relative sizing the actual margin varies by subject and never falls below this (only the set's largest subject sits exactly on it); with fill sizing every subject touches it on one axis. | |
| styleReferences | No | Up to 3 reference images that define the style, alone or alongside the style parameter (with both, the text pins the style and the references show it applied - the tightest hold, recommended when extending an existing set). Each entry is a ref_ token from the create_reference tool: create an upload slot, send the image file with the curl command it returns, then pass the token here. Image data itself never goes in a tool call; ref_ tokens are the only accepted form. Uploads take PNG, JPEG, or WebP; size and dimension limits are given in the create_reference tool's description, and oversized images are rejected with a clear message - larger reference images do not improve results. The images are used as style guides only: their rendering technique carries over, their subjects do not appear in the output. Provide at least one of style and styleReferences. |
| Name | Required | Description |
|---|---|---|
| style | No | |
| format | No | |
| images | No | |
| zipURL | No | |
| unpackTo | No | |
| expiresAt | No | |
| remaining | No | |
| background | No | |
| manifestURL | No | |
| rejectedStyle | No | Present only when the request was rejected because the style does not appear to describe a visual style: the submitted style text. No generation ran and nothing was charged; revise the style (or drop it and use styleReferences) and resubmit. |
| suggestedStyle | No | Present only on a validation suggestion: the cleaned style text, for review. An empty string means the cleanup removed the style entirely (nothing in it was usable as a style) - replace it, or use styleReferences. Absent on refs-only requests. No generation ran and nothing was charged. |
| rejectedSubjects | No | Present only when the request was rejected because some subjects do not appear to name distinct, drawable subjects: the exact rejected entries. No generation ran and nothing was charged; revise or remove these subjects and resubmit. |
| suggestedSubjects | No | Present only on a validation suggestion: the cleaned subject list, one entry per image. Adopt these, or resubmit your own wording with validation set to skip. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond annotations: cost per call, sequential-only execution, zip download URL, download URL expiration, validation flow, rejection rules, and rate-limit retry behavior. None of this contradicts the annotations, and it gives an agent critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is front-loaded and sectioned, but the description is very long and repeats guidance multiple times, such as background prohibitions, the generate_illustration alternative, and credit cost. While nearly all content is relevant, the redundancy prevents it from being a concise definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter generation tool with output schema and annotations, the description is complete: it covers output format, alternatives, sizing behavior, validation, failure modes, and operational constraints. There is no material gap for an agent trying to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description meaningfully expands parameter semantics: width/height combinations, sizing modes, the styleReferences ref_ token flow, validation modes, subject distinctness rules, and background constraints. This goes well beyond the schema's baseline descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: generating a cohesive set of custom images on a solid-color background, each an isolated subject sharing one background and visual style. It explicitly differentiates itself from generate_transparent_image_set and generate_illustration, making its scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use versus when-not-to-use guidance, naming generate_transparent_image_set for transparent backgrounds and generate_illustration for single composed scenes. It also provides usage direction for extending existing sets with styleReferences and for running calls sequentially rather than in parallel.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a cohesive SET of custom images with TRANSPARENT backgrounds, each one a separate isolated subject sharing one visual style (icons, logos, sprites, UI assets that need to drop onto any backdrop). The style parameter says how everything is drawn; the subjects parameter says what to draw. The style can also come from reference images via the styleReferences parameter - alone, or best combined with the style text (text plus references holds a style tightest), so an existing set can be extended in its original style across many calls. Returns a zip download URL. Each call costs 1 credit. When a solid colored background fits the user's use case, generate_image_set (1 credit per call) is the faster choice. Run generation calls sequentially, never in parallel - only one generation runs at a time per API key.
Output formats: PNG (lossless) or WebP. JPG is not supported because it has no alpha channel.
Size and quality considerations match generate_image_set: leaving width and height unset delivers native resolution (best quality, varies between generations); fixing them resamples to that box, and fixing one axis lets the other hug each subject.
IMPORTANT - style and subject description rules for best results: The style applies to every image in the set, so it is what keeps them visually consistent. Put HOW the images are drawn (technique, palette, surface treatment) in the style, and make each subject description only about WHAT that one subject is, not how it looks. A quick test for any phrase: is it WHAT the subject is, or HOW it is drawn? HOW belongs in the style, shared across the set.
Get the style and the subject descriptions right with the user before you call. When their request puts how an image is drawn, a background, or a scene into a subject description (or names the subjects to draw in the style rather than as separate entries in the subjects list), fix it as you compose the call: routine moves of shared technique into the style you can just make, but when a change drops or alters something they explicitly asked for, tell them what you are adjusting and why first. Each call costs a credit, so it is worth getting this right up front rather than spending one on a framed or scene-filled result.
The style describes the visual treatment of the images (e.g. 'watercolor', 'pixel art', 'stained glass'). It must NOT mention background color, image count, layout, or sizing.
Do not list the subjects to draw in the style (e.g. 'illustrations of a fox, an owl, and a deer'); the style is only the shared visual treatment, and the subjects belong in the subjects list, one per entry. A category or theme word is fine (e.g. 'insect illustration').
Do not put background color or background descriptions in the style or subject descriptions.
Avoid framing the style as a type of painted canvas ('oil painting', 'acrylic painting', 'gouache painting', 'pastel painting'). These tend to produce each image as a rectangular framed canvas with its own colored background, rather than an isolated subject. Prefer 'illustration' or a specific technique: 'watercolor illustration', 'pen-and-ink sketch', 'ink wash', 'relief-etching', 'pastel drawing', 'woodblock print'.
Avoid color-field or atmospheric phrasings in the style ('luminous backgrounds of violet, rose, and gold', 'set against jewel-tone fields', 'dreamlike rainbow atmosphere'). These instruct the image model to fill each image with colored atmosphere, producing framed compositions rather than isolated subjects. Describe only the linework, palette, and technique of the subjects themselves.
Do not describe an aged, weathered, cracked, or textured surface, ground, wall, panel, or paper that the whole artwork sits on ('on aged wood', 'cracked fresco wall', 'aged parchment surface'); name the art tradition(s) or style(s) instead ('fresco-style illustration'). Texture that belongs to a subject's own material is fine ('a weathered bronze shield', 'a cracked ceramic vase').
No captions, labels, or annotations. Text that is part of the depicted object is fine (e.g. 'STOP' on a stop sign, 'EXIT' on an exit sign).
No grid lines, borders, frames, or separators.
No overlapping or collage-style arrangements.
Do not connect the subjects to each other or give them shared physical elements: no wires, cords, chains, ropes, ribbons, vines, or threads running between subjects, no frame or banner they share, no phrasing like 'connected by' or 'strung together', and no single continuous line or tube forming multiple subjects. Each subject must be drawable in complete isolation; connections inside one subject (a chain on an amulet, laces on a boot) are fine.
No dramatic/long drop shadows (subtle shadows are fine).
Image descriptions should describe WHAT to depict, not where to position it.
Each image is ONE isolated subject, not a scene. Describe the subject with its pose or action and anything it directly holds, rides, or interacts with, but not the surrounding setting, environment, landscape, or sky. For a single composed scene (a figure set within an environment), use generate_illustration instead.
Do not use size words (large, tiny, small, etc.) on the overall image subject (e.g. 'a large elephant', 'a tiny mouse') - all images are produced at the same size. Size words on details within the image are fine (e.g. 'a plate with a small insignia').
Maximum 18 images per generation. Do not put the image count in the style.
Subjects must be distinct: entries that differ only in case, punctuation, or spacing count as the same subject and the call is rejected. Explicit filenames must be distinct too (a different extension alone is not distinct).
The style must actually describe a visual style, and each subject must name a drawable subject; text that does not is rejected.
Style description max length: 500 characters. Image description max length: 200 characters each.
Size: width and height are separate parameters, each 256 to 512 pixels when given. Both given is an exact box; one given fixes that axis and the other hugs each subject (so images in the set differ on it, and it may fall below 256); neither given delivers native resolution, which is also the path to larger images.
Sizing: relative (the default) keeps the sizes the model gave the subjects in relation to one another, one scale for the whole set; fill scales each subject on its own to fill its frame less the margin, the icon-set convention, giving up relative size and enlarging subjects smaller than the frame (the result says by how much). Both can be changed later with edit_image_set.
Icons: the subject count sets how large a batch's icons can later be exported with export_icons, crisp at every density: about a 136px base size with 13 to 18 subjects, 160 with 10 to 12, 180 with 7 to 9, 192 with 5 or 6, 256 with 4 or fewer. Every generation result states its batch's own crisp base size.
If the style check returns a suggested cleanup, show the user the specific changes and get their confirmation, then resubmit the approved prompt with validation set to "skip" so it generates exactly as approved (resubmitting without "skip" re-runs the check and may return further suggestions). See the validation parameter for when to use "skip" and "auto-apply".
If a "Rate limit exceeded" error is returned, wait the suggested number of seconds before retrying. Do not retry immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | Visual style for all images, e.g. flat minimalist, hand-drawn sketch, 3D glossy, pixel art. Text that does not describe a visual style is rejected. Provide this, styleReferences, or both - together they hold a style most tightly (the text pins the style, the references show it applied), which is the recommended way to extend an existing set across multiple calls. | |
| width | No | Delivered width in pixels. Give both width and height for an exact box (every image lands on it, one uniform scale, the shorter axis padded); give only one and the other axis hugs each subject at that scale plus the margin (so images in the set differ on it); give neither and images arrive at their native size with no scaling or distortion. The per-axis range is given in the tool description; a given axis outside it is rejected, and the hugging axis is whatever each subject needs. | |
| format | No | Output format: png or webp (jpg has no alpha channel and is rejected). Defaults to png. | |
| height | No | Delivered height in pixels; see width for how the two combine (both: an exact box; one: the other axis hugs each subject; neither: native size). | |
| sizing | No | How subjects are scaled. relative (the default) keeps the sizes the model gave them in relation to one another: one scale for the whole set, so a small subject stays small in its frame. fill scales each subject on its own to fill the frame less the margin, touching it on one axis, so every image reads at the same visual weight (icon-set convention); that gives up relative size and enlarges any subject smaller than the frame, which the result reports when it happens. | |
| quality | No | Image quality for webp (1-100). Defaults to 90. | |
| subjects | Yes | Either a list of subject names (e.g. ["home", "search"]) or objects with description and filename (e.g. [{"description": "compass rose", "filename": "overview.webp"}]). Each subject must name a drawable subject and be distinct: entries differing only in case, punctuation, or spacing are rejected as the same subject. A subject with no Latin letters or numbers (a name written entirely in another script) needs the object form with a filename, since delivered files are named in ASCII. Subject text can use only letters, numbers, dashes, spaces, and apostrophes, and must start and end with a letter or number. | |
| unpackTo | No | Path on the caller's local filesystem where the generated files should be saved. The server does NOT write here. After this call returns, you (the calling client) must download images.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL expires (the result states when). | |
| validation | No | How to handle the automatic style/subject check before generating. One of: suggest (the default) - if the style and descriptions need cleanup for a consistent set, the cleaned version is returned as a suggestion for you to review before any image is generated; skip - skip the cleanup suggestions and generate exactly as given (the non-drawable-content and repeated-subject rejection rules above still apply; no mode skips them), set this when resubmitting a prompt you already revised from a previous suggestion (so your approved wording is used as-is and not re-checked, which avoids further suggestions) or when you are confident the prompt is already clean; auto-apply - if cleanup is needed, apply it and generate in one step without returning a suggestion. Omit for the default. | |
| minimumMargin | No | Minimum margin in pixels around each subject. Defaults to 20. At most 15% of the smallest given axis when width or height is given, at most 80 when neither is; negative values are rejected. With relative sizing the actual margin varies by subject and never falls below this (only the set's largest subject sits exactly on it); with fill sizing every subject touches it on one axis. | |
| styleReferences | No | Up to 3 reference images that define the style, alone or alongside the style parameter (with both, the text pins the style and the references show it applied - the tightest hold, recommended when extending an existing set). Each entry is a ref_ token from the create_reference tool: create an upload slot, send the image file with the curl command it returns, then pass the token here. Image data itself never goes in a tool call; ref_ tokens are the only accepted form. Uploads take PNG, JPEG, or WebP; size and dimension limits are given in the create_reference tool's description, and oversized images are rejected with a clear message - larger reference images do not improve results. The images are used as style guides only: their rendering technique carries over, their subjects do not appear in the output. Provide at least one of style and styleReferences. |
| Name | Required | Description |
|---|---|---|
| style | No | |
| format | No | |
| images | No | |
| zipURL | No | |
| unpackTo | No | |
| expiresAt | No | |
| remaining | No | |
| background | No | |
| manifestURL | No | |
| rejectedStyle | No | Present only when the request was rejected because the style does not appear to describe a visual style: the submitted style text. No generation ran and nothing was charged; revise the style (or drop it and use styleReferences) and resubmit. |
| suggestedStyle | No | Present only on a validation suggestion: the cleaned style text, for review. An empty string means the cleanup removed the style entirely (nothing in it was usable as a style) - replace it, or use styleReferences. Absent on refs-only requests. No generation ran and nothing was charged. |
| rejectedSubjects | No | Present only when the request was rejected because some subjects do not appear to name distinct, drawable subjects: the exact rejected entries. No generation ran and nothing was charged; revise or remove these subjects and resubmit. |
| suggestedSubjects | No | Present only on a validation suggestion: the cleaned subject list, one entry per image. Adopt these, or resubmit your own wording with validation set to skip. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations, disclosing the 1-credit cost per call, rate-limit retry behavior, sequential execution constraint, unsupported JPG format due to no alpha channel, download URL expiry, and the fact that unpackTo is not written by the server. It also exposes common failure modes like framed-canvas results and repeated-subject rejections, which the structured annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but the length is justified by the tool's complexity and high failure risk. It is well-structured with clear sections, and the core purpose and primary alternative are front-loaded in the first paragraph. A slightly tighter organization could reduce redundancy, but every major section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, rich annotations, an output schema, and seven sibling tools, the description covers everything an agent needs: cost, rate limits, validation flow, style/subject separation rules, output formats, sizing behavior, reference-image handling, and client-side download responsibility. No critical operational gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description substantially enriches parameter meaning: it explains how width and height combine (exact box, hugging axis, or native size), what relative vs fill sizing does, what styleReferences tokens require, how validation modes behave, and the precise rules for subjects and style content. This is far more than the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: generate a cohesive set of custom images with transparent backgrounds, each an isolated subject sharing one visual style. It explicitly distinguishes itself from siblings—generate_image_set for solid-colored backgrounds and generate_illustration for composed scenes—so an agent can select the right tool without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit and thorough: it names when to prefer generate_image_set, when to use generate_illustration instead, how to extend existing sets via styleReferences, and the requirement to run generation calls sequentially. It also explains the validation flow including when to use 'skip' and 'auto-apply', leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your recent successful generations and return their download URLs again. Use this to recover a generation whose result message was lost (for example a dropped connection mid-call): generations are billed when they complete, and their downloads stay available until their original expiry even if the response never arrived - re-listing does not extend the expiry. Generations made on the logospell.com generate page appear here too. Returns, newest first: each generation's id, creation and expiry times, zip download URL, its set lineage (parent generation ids plus the style-reference sources it was made with, ready to reuse via create_reference), and promptJSON - the batch's own prompt.json, whose style and subject descriptions are the original call, so a past generation can be reproduced rather than only identified, and whose delivery levers follow the set's current delivery once it has been edited. Costs no credits.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of recent generations to return (default 5). There is no ceiling: pass a large number to list everything, and read total in the output to know whether anything was left out. |
| Name | Required | Description |
|---|---|---|
| total | Yes | How many unexpired generations this key has in all. Greater than the number of rows returned means the listing was cut short by limit; ask again with a larger limit. |
| generations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds significant behavioral nuance: re-listing does not extend expiry, generations are billed when they complete, and downloads remain available even if the response never arrived. This goes well beyond the structured hint data and is consistent with it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place: purpose, recovery scenario, billing/expiry caveat, source scope, full return payload breakdown, and cost note. It is front-loaded with the primary action and structured logically from simplest use case to detailed output semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that lists recent generations, the description is remarkably complete. It covers cost, ordering (newest first), what fields are returned, how lineage can be reused via create_reference, and the fact that the promptJSON enables reproduction. The presence of an output schema further reduces the burden, but this description would be nearly sufficient even without it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'limit' is fully described in the input schema (default 5, no ceiling, read total to detect truncation). Since schema coverage is 100%, the description does not need to add parameter detail, and it correctly focuses on output rather than repeating the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'List your recent successful generations and return their download URLs again.' It immediately distinguishes itself from siblings like generate_image_set by focusing on retrieval/recovery rather than creation, and even names the recovery use case explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states exactly when to use this tool: 'Use this to recover a generation whose result message was lost (for example a dropped connection mid-call).' It also gives important context about billing and expiry, and mentions that generations from the logospell.com page appear here too, helping an agent decide when this is the right call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
export_icons1 field changedOutput schema / properties / zipURL / descriptionPrevious 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."generate_illustration1 field changedInput schema / properties / unpackTo / descriptionPrevious value: -"Path on the caller's local filesystem where the generated illustration should be saved. The server does NOT write here. After this call returns, you (the calling client) must download illustration.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL is short-lived."New value: +"Path on the caller's local filesystem where the generated illustration should be saved. The server does NOT write here. After this call returns, you (the calling client) must download illustration.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL expires (the result states when)."generate_image_set1 field changedInput schema / properties / unpackTo / descriptionPrevious value: -"Path on the caller's local filesystem where the generated files should be saved. The server does NOT write here. After this call returns, you (the calling client) must download images.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL is short-lived."New value: +"Path on the caller's local filesystem where the generated files should be saved. The server does NOT write here. After this call returns, you (the calling client) must download images.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL expires (the result states when)."generate_transparent_image_set1 field changedInput schema / properties / unpackTo / descriptionPrevious value: -"Path on the caller's local filesystem where the generated files should be saved. The server does NOT write here. After this call returns, you (the calling client) must download images.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL is short-lived."New value: +"Path on the caller's local filesystem where the generated files should be saved. The server does NOT write here. After this call returns, you (the calling client) must download images.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL expires (the result states when)."list_recent_generations1 field changedOutput schema / properties / generations / items / properties / promptJSON / descriptionPrevious value: -"The original call, verbatim, exactly as the batch's own prompt.json records it - the same bytes that ship inside the zip. Its shape follows the tool named in its own tool field. Sets carry style, subjects as {description, filename} pairs, format, quality, minimumMargin, validation, width and height when an axis was fixed, background for solid-background sets, and styleReferences as zip-relative paths when the call used them. Illustrations carry prompt, width, height, format, quality and filename. Read subjects[].description to reproduce a set: a subject given in object form has a description that differs from its filename, so search.webp may have been asked for as a magnifying glass."New value: +"The batch's own prompt.json, verbatim - the same bytes that ship inside the zip. Its style, subjects and styleReferences are the original call and no edit can change them; its delivery levers (width, height, canvas, minimumMargin, format, quality, background) are the batch's current delivery, which edit_image_set rewrites, so reusing this reproduces the set as it stands now rather than as first delivered. The edited flag says whether that has happened. Its shape follows the tool named in its own tool field. Sets carry style, subjects as {description, filename} pairs, format, quality, minimumMargin, validation, width and height when an axis was fixed, background for solid-background sets, and styleReferences as zip-relative paths when the call used them. Illustrations carry prompt, width, height, format, quality and filename. Read subjects[].description to reproduce a set: a subject given in object form has a description that differs from its filename, so search.webp may have been asked for as a magnifying glass."edit_image_setexport_iconsgenerate_image_set5 fields changedInput schema / properties / heightAdded value: +{
+ "description": "Delivered height in pixels; see width for how the two combine (both: an exact box; one: the other axis hugs each subject; neither: native size).",
+ "type": "integer"
+}Input schema / properties / minimumMargin / descriptionPrevious value: -"Minimum margin in pixels around each subject. Defaults to 20. At most 15% of the smallest requested dimension when a size is given, at most 80 without one; negative values are rejected. All images in a set share one set of dimensions; the actual margin varies by subject and never falls below this."New value: +"Minimum margin in pixels around each subject. Defaults to 20. At most 15% of the smallest given axis when width or height is given, at most 80 when neither is; negative values are rejected. With relative sizing the actual margin varies by subject and never falls below this (only the set's largest subject sits exactly on it); with fill sizing every subject touches it on one axis."Input schema / properties / sizeRemoved value: -{
- "description": "Image dimensions (e.g. 512 for square, 256x512 for non-square). Per-axis minimum and maximum are given in the tool description; values outside the range are rejected. If omitted, images are delivered at their native size with no scaling or distortion - this preserves maximum detail but output dimensions vary between generations. Specifying a size guarantees consistent dimensions across all images and generations but applies Lanczos resampling which may soften fine details. If the user plans to post-process the images, recommend omitting size to get the highest quality results.",
- "type": "string"
-}Input schema / properties / sizingAdded value: +{
+ "description": "How subjects are scaled. relative (the default) keeps the sizes the model gave them in relation to one another: one scale for the whole set, so a small subject stays small in its frame. fill scales each subject on its own to fill the frame less the margin, touching it on one axis, so every image reads at the same visual weight (icon-set convention); that gives up relative size and enlarges any subject smaller than the frame, which the result reports when it happens.",
+ "type": "string"
+}Input schema / properties / widthAdded value: +{
+ "description": "Delivered width in pixels. Give both width and height for an exact box (every image lands on it, one uniform scale, the shorter axis padded); give only one and the other axis hugs each subject at that scale plus the margin (so images in the set differ on it); give neither and images arrive at their native size with no scaling or distortion - the highest detail, though dimensions then vary between generations. The per-axis range is given in the tool description; a given axis outside it is rejected, and the hugging axis is whatever each subject needs. A fixed size guarantees consistent dimensions across images and generations but applies Lanczos resampling which may soften fine detail; if the user will post-process the images, recommend leaving both unset.",
+ "type": "integer"
+}generate_transparent_image_set5 fields changedInput schema / properties / heightAdded value: +{
+ "description": "Delivered height in pixels; see width for how the two combine (both: an exact box; one: the other axis hugs each subject; neither: native size).",
+ "type": "integer"
+}Input schema / properties / minimumMargin / descriptionPrevious value: -"Minimum margin in pixels around each subject. Defaults to 20. At most 15% of the smallest requested dimension when a size is given, at most 80 without one; negative values are rejected. All images in a set share one set of dimensions; the actual margin varies by subject and never falls below this."New value: +"Minimum margin in pixels around each subject. Defaults to 20. At most 15% of the smallest given axis when width or height is given, at most 80 when neither is; negative values are rejected. With relative sizing the actual margin varies by subject and never falls below this (only the set's largest subject sits exactly on it); with fill sizing every subject touches it on one axis."Input schema / properties / sizeRemoved value: -{
- "description": "Image dimensions (e.g. 512 for square, 256x512 for non-square). Per-axis minimum and maximum are given in the tool description; values outside the range are rejected. If omitted, images are delivered at their native size with no scaling or distortion.",
- "type": "string"
-}Input schema / properties / sizingAdded value: +{
+ "description": "How subjects are scaled. relative (the default) keeps the sizes the model gave them in relation to one another: one scale for the whole set, so a small subject stays small in its frame. fill scales each subject on its own to fill the frame less the margin, touching it on one axis, so every image reads at the same visual weight (icon-set convention); that gives up relative size and enlarges any subject smaller than the frame, which the result reports when it happens.",
+ "type": "string"
+}Input schema / properties / widthAdded value: +{
+ "description": "Delivered width in pixels. Give both width and height for an exact box (every image lands on it, one uniform scale, the shorter axis padded); give only one and the other axis hugs each subject at that scale plus the margin (so images in the set differ on it); give neither and images arrive at their native size with no scaling or distortion. The per-axis range is given in the tool description; a given axis outside it is rejected, and the hugging axis is whatever each subject needs.",
+ "type": "integer"
+}list_recent_generations8 fields changedOutput schema / properties / generations / items / properties / deliveredAtAdded value: +{
+ "description": "When the current delivery was cut: the generation time, or the time of the last edit_image_set.",
+ "type": "string"
+}Output schema / properties / generations / items / properties / editableAdded value: +{
+ "description": "True when this set can be re-delivered with edit_image_set (it has a source to cut from).",
+ "type": "boolean"
+}Output schema / properties / generations / items / properties / editedAdded value: +{
+ "description": "True when edit_image_set has changed this set's delivery from what was generated; a reset makes it false again.",
+ "type": "boolean"
+}Output schema / properties / generations / items / properties / iconCeilingAdded value: +{
+ "description": "The largest base size, in pixels, at which export_icons keeps every density of this set crisp (no subject enlarged past its source pixels) at its current levers; absent when no base size does. Fixed by the subject count at generation; edits to margin or sizing move it.",
+ "type": "integer"
+}Output schema / properties / generations / items / properties / leversAdded value: +{
+ "additionalProperties": false,
+ "description": "The delivery levers now in force for a set (width, height, minimumMargin, format, quality, background): the first delivery's until edit_image_set changes them. Absent on illustrations and on sets from before editing existed.",
+ "properties": {
+ "background": {
+ "type": "string"
+ },
+ "canvas": {
+ "type": "string"
+ },
+ "format": {
+ "type": "string"
+ },
+ "height": {
+ "type": "integer"
+ },
+ "minimumMargin": {
+ "type": "integer"
+ },
+ "quality": {
+ "type": "integer"
+ },
+ "sizing": {
+ "type": "string"
+ },
+ "width": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "minimumMargin",
+ "format"
+ ],
+ "type": [
+ "null",
+ "object"
+ ]
+}Output schema / properties / generations / items / properties / nativeHeightAdded value: +{
+ "type": "integer"
+}Output schema / properties / generations / items / properties / nativeWidthAdded value: +{
+ "description": "The canvas this set would be delivered on at native size (its trimmed frame plus margin): the size any re-delivery compares against.",
+ "type": "integer"
+}Output schema / properties / generations / items / properties / promptJSON / descriptionPrevious value: -"The original call, verbatim, exactly as the batch's own prompt.json records it - the same bytes that ship inside the zip. Its shape follows the tool named in its own tool field. Sets carry style, subjects as {description, filename} pairs, format, quality, minimumMargin, validation, size when one was requested, background for solid-background sets, and styleReferences as zip-relative paths when the call used them. Illustrations carry prompt, width, height, format, quality and filename. Read subjects[].description to reproduce a set: a subject given in object form has a description that differs from its filename, so search.webp may have been asked for as a magnifying glass."New value: +"The original call, verbatim, exactly as the batch's own prompt.json records it - the same bytes that ship inside the zip. Its shape follows the tool named in its own tool field. Sets carry style, subjects as {description, filename} pairs, format, quality, minimumMargin, validation, width and height when an axis was fixed, background for solid-background sets, and styleReferences as zip-relative paths when the call used them. Illustrations carry prompt, width, height, format, quality and filename. Read subjects[].description to reproduce a set: a subject given in object form has a description that differs from its filename, so search.webp may have been asked for as a magnifying glass."list_recent_generations7 fields changedOutput schema / properties / generations / items / properties / imagesRemoved value: -{
- "type": "integer"
-}Output schema / properties / generations / items / properties / namesRemoved value: -{
- "items": {
- "type": "string"
- },
- "type": [
- "null",
- "array"
- ]
-}Output schema / properties / generations / items / properties / promptJSONAdded value: +{
+ "description": "The original call, verbatim, exactly as the batch's own prompt.json records it - the same bytes that ship inside the zip. Its shape follows the tool named in its own tool field. Sets carry style, subjects as {description, filename} pairs, format, quality, minimumMargin, validation, size when one was requested, background for solid-background sets, and styleReferences as zip-relative paths when the call used them. Illustrations carry prompt, width, height, format, quality and filename. Read subjects[].description to reproduce a set: a subject given in object form has a description that differs from its filename, so search.webp may have been asked for as a magnifying glass."
+}Output schema / properties / generations / items / properties / styleRemoved value: -{
- "type": "string"
-}Output schema / properties / generations / items / properties / styleReferences / descriptionPrevious value: -"The style references this generation was made with, in call order, each identified by the delivered image it came from when known. Absent when no references were used."New value: +"The style references this generation was made with, in call order, each identified by the delivered image it came from when known, and reusable via create_reference. Distinct from promptJSON.styleReferences, which records the same references as zip-relative paths inside the original call. Absent when no references were used."Output schema / properties / generations / items / properties / toolRemoved value: -{
- "type": "string"
-}Output schema / properties / generations / items / requiredPrevious value: -[
- "id",
- "tool",
- "created",
- "expiresAt",
- "images",
- "zipURL"
-]New value: +[
+ "id",
+ "created",
+ "expiresAt",
+ "zipURL",
+ "promptJSON"
+]list_recent_generations3 fields changedInput schema / properties / limit / descriptionPrevious value: -"Maximum number of recent generations to return (default 5, max 20)."New value: +"Maximum number of recent generations to return (default 5). There is no ceiling: pass a large number to list everything, and read total in the output to know whether anything was left out."Output schema / properties / totalAdded value: +{
+ "description": "How many unexpired generations this key has in all. Greater than the number of rows returned means the listing was cut short by limit; ask again with a larger limit.",
+ "type": "integer"
+}Output schema / requiredPrevious value: -[
- "generations"
-]New value: +[
+ "generations",
+ "total"
+]list_recent_generations4 fields changedOutput schema / properties / generations / items / properties / idAdded value: +{
+ "description": "The generation's id - the random segment of its download URLs, accepted by create_reference's sourceGeneration.",
+ "type": "string"
+}Output schema / properties / generations / items / properties / parentsAdded value: +{
+ "description": "Ids of the generations whose delivered images seeded this one's style references - the set lineage. Absent when this generation extended nothing.",
+ "items": {
+ "type": "string"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}Output schema / properties / generations / items / properties / styleReferencesAdded value: +{
+ "description": "The style references this generation was made with, in call order, each identified by the delivered image it came from when known. Absent when no references were used.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "from": {
+ "description": "The generation id this reference image came from; accepted by create_reference's sourceGeneration.",
+ "type": "string"
+ },
+ "image": {
+ "description": "The delivered image filename inside that generation; accepted by create_reference's sourceImage.",
+ "type": "string"
+ },
+ "uploaded": {
+ "description": "True for a hand-uploaded reference that came from no generation.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}Output schema / properties / generations / items / requiredPrevious value: -[
- "tool",
- "created",
- "expiresAt",
- "images",
- "zipURL"
-]New value: +[
+ "id",
+ "tool",
+ "created",
+ "expiresAt",
+ "images",
+ "zipURL"
+]generate_image_set1 field changedInput schema / properties / subjects / descriptionPrevious value: -"Either a list of subject names (e.g. [\"home\", \"search\"]) or objects with description and filename (e.g. [{\"description\": \"compass rose\", \"filename\": \"overview.webp\"}]). Each subject must name a drawable subject and be distinct: entries differing only in case, punctuation, or spacing are rejected as the same subject. A subject with no Latin letters or numbers (a name written entirely in another script) needs the object form with a filename, since delivered files are named in ASCII."New value: +"Either a list of subject names (e.g. [\"home\", \"search\"]) or objects with description and filename (e.g. [{\"description\": \"compass rose\", \"filename\": \"overview.webp\"}]). Each subject must name a drawable subject and be distinct: entries differing only in case, punctuation, or spacing are rejected as the same subject. A subject with no Latin letters or numbers (a name written entirely in another script) needs the object form with a filename, since delivered files are named in ASCII. Subject text can use only letters, numbers, dashes, spaces, and apostrophes, and must start and end with a letter or number."generate_transparent_image_set1 field changedInput schema / properties / subjects / descriptionPrevious value: -"Either a list of subject names (e.g. [\"home\", \"search\"]) or objects with description and filename (e.g. [{\"description\": \"compass rose\", \"filename\": \"overview.webp\"}]). Each subject must name a drawable subject and be distinct: entries differing only in case, punctuation, or spacing are rejected as the same subject. A subject with no Latin letters or numbers (a name written entirely in another script) needs the object form with a filename, since delivered files are named in ASCII."New value: +"Either a list of subject names (e.g. [\"home\", \"search\"]) or objects with description and filename (e.g. [{\"description\": \"compass rose\", \"filename\": \"overview.webp\"}]). Each subject must name a drawable subject and be distinct: entries differing only in case, punctuation, or spacing are rejected as the same subject. A subject with no Latin letters or numbers (a name written entirely in another script) needs the object form with a filename, since delivered files are named in ASCII. Subject text can use only letters, numbers, dashes, spaces, and apostrophes, and must start and end with a letter or number."create_referencegenerate_illustration2 fields changedInput schema / properties / prompt / descriptionPrevious value: -"What the illustration should depict - a scene, environment, hero image, banner, character, or any single composed picture. Used as written. Do not put the pixel size here; use width and height."New value: +"What the illustration should depict - a scene, environment, hero image, banner, character, or any single composed picture. Used as written; a prompt that does not describe a picture is rejected. Do not put the pixel size here; use width and height."Output schema / properties / rejectedPromptAdded value: +{
+ "description": "Present only when the request was rejected because the prompt does not appear to describe a picture: the submitted prompt. No generation ran and nothing was charged; revise the prompt and resubmit.",
+ "type": "string"
+}generate_image_set11 fields changedInput schema / properties / minimumMargin / descriptionPrevious value: -"Minimum padding in pixels around each subject. Defaults to 20. Subjects in a cohesive set share one output frame so relative scales stay consistent across the set, so any subject smaller than the largest in the set will have additional padding beyond this minimum."New value: +"Minimum margin in pixels around each subject. Defaults to 20. At most 15% of the smallest requested dimension when a size is given, at most 80 without one; negative values are rejected. All images in a set share one set of dimensions; the actual margin varies by subject and never falls below this."Input schema / properties / size / descriptionPrevious value: -"Image dimensions (e.g. 512 for square, 256x512 for non-square). Per-axis minimum is given in the tool description; smaller values are rejected. If omitted, images are delivered at their native size with no scaling or distortion - this preserves maximum detail but output dimensions vary between generations. Specifying a size guarantees consistent dimensions across all images and generations but applies Lanczos resampling which may soften fine details. If the user plans to post-process the images, recommend omitting size to get the highest quality results."New value: +"Image dimensions (e.g. 512 for square, 256x512 for non-square). Per-axis minimum and maximum are given in the tool description; values outside the range are rejected. If omitted, images are delivered at their native size with no scaling or distortion - this preserves maximum detail but output dimensions vary between generations. Specifying a size guarantees consistent dimensions across all images and generations but applies Lanczos resampling which may soften fine details. If the user plans to post-process the images, recommend omitting size to get the highest quality results."Input schema / properties / style / descriptionPrevious value: -"Visual style for all images, e.g. flat minimalist, hand-drawn sketch, 3D glossy, pixel art"New value: +"Visual style for all images, e.g. flat minimalist, hand-drawn sketch, 3D glossy, pixel art. Text that does not describe a visual style is rejected. Provide this, styleReferences, or both - together they hold a style most tightly (the text pins the style, the references show it applied), which is the recommended way to extend an existing set across multiple calls."Input schema / properties / styleReferencesAdded value: +{
+ "description": "Up to 3 reference images that define the style, alone or alongside the style parameter (with both, the text pins the style and the references show it applied - the tightest hold, recommended when extending an existing set). Each entry is a ref_ token from the create_reference tool: create an upload slot, send the image file with the curl command it returns, then pass the token here. Image data itself never goes in a tool call; ref_ tokens are the only accepted form. Uploads take PNG, JPEG, or WebP; size and dimension limits are given in the create_reference tool's description, and oversized images are rejected with a clear message - larger reference images do not improve results. The images are used as style guides only: their rendering technique carries over, their subjects do not appear in the output. Provide at least one of style and styleReferences.",
+ "items": {
+ "type": "string"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}Input schema / properties / subjects / descriptionPrevious value: -"Either a list of subject names (e.g. [\"home\", \"search\"]) or objects with description and filename (e.g. [{\"description\": \"compass rose\", \"filename\": \"overview.webp\"}])"New value: +"Either a list of subject names (e.g. [\"home\", \"search\"]) or objects with description and filename (e.g. [{\"description\": \"compass rose\", \"filename\": \"overview.webp\"}]). Each subject must name a drawable subject and be distinct: entries differing only in case, punctuation, or spacing are rejected as the same subject. A subject with no Latin letters or numbers (a name written entirely in another script) needs the object form with a filename, since delivered files are named in ASCII."Input schema / properties / validation / descriptionPrevious value: -"How to handle the automatic style/subject check before generating. One of: suggest (the default) - if the style and descriptions need cleanup for a consistent set, the cleaned version is returned as a suggestion for you to review before any image is generated; skip - skip the check and generate exactly as given, set this when resubmitting a prompt you already revised from a previous suggestion (so your approved wording is used as-is and not re-checked, which avoids further suggestions) or when you are confident the prompt is already clean; auto-apply - if cleanup is needed, apply it and generate in one step without returning a suggestion. Omit for the default."New value: +"How to handle the automatic style/subject check before generating. One of: suggest (the default) - if the style and descriptions need cleanup for a consistent set, the cleaned version is returned as a suggestion for you to review before any image is generated; skip - skip the cleanup suggestions and generate exactly as given (the non-drawable-content and repeated-subject rejection rules above still apply; no mode skips them), set this when resubmitting a prompt you already revised from a previous suggestion (so your approved wording is used as-is and not re-checked, which avoids further suggestions) or when you are confident the prompt is already clean; auto-apply - if cleanup is needed, apply it and generate in one step without returning a suggestion. Omit for the default."Input schema / requiredPrevious value: -[
- "style",
- "subjects"
-]New value: +[
+ "subjects"
+]Output schema / properties / rejectedStyleAdded value: +{
+ "description": "Present only when the request was rejected because the style does not appear to describe a visual style: the submitted style text. No generation ran and nothing was charged; revise the style (or drop it and use styleReferences) and resubmit.",
+ "type": "string"
+}Output schema / properties / rejectedSubjectsAdded value: +{
+ "description": "Present only when the request was rejected because some subjects do not appear to name distinct, drawable subjects: the exact rejected entries. No generation ran and nothing was charged; revise or remove these subjects and resubmit.",
+ "items": {
+ "type": "string"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}Output schema / properties / suggestedStyleAdded value: +{
+ "description": "Present only on a validation suggestion: the cleaned style text, for review. An empty string means the cleanup removed the style entirely (nothing in it was usable as a style) - replace it, or use styleReferences. Absent on refs-only requests. No generation ran and nothing was charged.",
+ "type": [
+ "null",
+ "string"
+ ]
+}Output schema / properties / suggestedSubjectsAdded value: +{
+ "description": "Present only on a validation suggestion: the cleaned subject list, one entry per image. Adopt these, or resubmit your own wording with validation set to skip.",
+ "items": {
+ "type": "string"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}generate_transparent_image_set11 fields changedInput schema / properties / minimumMargin / descriptionPrevious value: -"Minimum padding in pixels around each subject. Defaults to 20. Subjects in a cohesive set share one output frame so relative scales stay consistent across the set, so any subject smaller than the largest in the set will have additional padding beyond this minimum."New value: +"Minimum margin in pixels around each subject. Defaults to 20. At most 15% of the smallest requested dimension when a size is given, at most 80 without one; negative values are rejected. All images in a set share one set of dimensions; the actual margin varies by subject and never falls below this."Input schema / properties / size / descriptionPrevious value: -"Image dimensions (e.g. 512 for square, 256x512 for non-square). Per-axis minimum is given in the tool description; smaller values are rejected. If omitted, images are delivered at their native size with no scaling or distortion."New value: +"Image dimensions (e.g. 512 for square, 256x512 for non-square). Per-axis minimum and maximum are given in the tool description; values outside the range are rejected. If omitted, images are delivered at their native size with no scaling or distortion."Input schema / properties / style / descriptionPrevious value: -"Visual style for all images, e.g. flat minimalist, hand-drawn sketch, 3D glossy, pixel art"New value: +"Visual style for all images, e.g. flat minimalist, hand-drawn sketch, 3D glossy, pixel art. Text that does not describe a visual style is rejected. Provide this, styleReferences, or both - together they hold a style most tightly (the text pins the style, the references show it applied), which is the recommended way to extend an existing set across multiple calls."Input schema / properties / styleReferencesAdded value: +{
+ "description": "Up to 3 reference images that define the style, alone or alongside the style parameter (with both, the text pins the style and the references show it applied - the tightest hold, recommended when extending an existing set). Each entry is a ref_ token from the create_reference tool: create an upload slot, send the image file with the curl command it returns, then pass the token here. Image data itself never goes in a tool call; ref_ tokens are the only accepted form. Uploads take PNG, JPEG, or WebP; size and dimension limits are given in the create_reference tool's description, and oversized images are rejected with a clear message - larger reference images do not improve results. The images are used as style guides only: their rendering technique carries over, their subjects do not appear in the output. Provide at least one of style and styleReferences.",
+ "items": {
+ "type": "string"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}Input schema / properties / subjects / descriptionPrevious value: -"Either a list of subject names (e.g. [\"home\", \"search\"]) or objects with description and filename (e.g. [{\"description\": \"compass rose\", \"filename\": \"overview.webp\"}])"New value: +"Either a list of subject names (e.g. [\"home\", \"search\"]) or objects with description and filename (e.g. [{\"description\": \"compass rose\", \"filename\": \"overview.webp\"}]). Each subject must name a drawable subject and be distinct: entries differing only in case, punctuation, or spacing are rejected as the same subject. A subject with no Latin letters or numbers (a name written entirely in another script) needs the object form with a filename, since delivered files are named in ASCII."Input schema / properties / validation / descriptionPrevious value: -"How to handle the automatic style/subject check before generating. One of: suggest (the default) - if the style and descriptions need cleanup for a consistent set, the cleaned version is returned as a suggestion for you to review before any image is generated; skip - skip the check and generate exactly as given, set this when resubmitting a prompt you already revised from a previous suggestion (so your approved wording is used as-is and not re-checked, which avoids further suggestions) or when you are confident the prompt is already clean; auto-apply - if cleanup is needed, apply it and generate in one step without returning a suggestion. Omit for the default."New value: +"How to handle the automatic style/subject check before generating. One of: suggest (the default) - if the style and descriptions need cleanup for a consistent set, the cleaned version is returned as a suggestion for you to review before any image is generated; skip - skip the cleanup suggestions and generate exactly as given (the non-drawable-content and repeated-subject rejection rules above still apply; no mode skips them), set this when resubmitting a prompt you already revised from a previous suggestion (so your approved wording is used as-is and not re-checked, which avoids further suggestions) or when you are confident the prompt is already clean; auto-apply - if cleanup is needed, apply it and generate in one step without returning a suggestion. Omit for the default."Input schema / requiredPrevious value: -[
- "style",
- "subjects"
-]New value: +[
+ "subjects"
+]Output schema / properties / rejectedStyleAdded value: +{
+ "description": "Present only when the request was rejected because the style does not appear to describe a visual style: the submitted style text. No generation ran and nothing was charged; revise the style (or drop it and use styleReferences) and resubmit.",
+ "type": "string"
+}Output schema / properties / rejectedSubjectsAdded value: +{
+ "description": "Present only when the request was rejected because some subjects do not appear to name distinct, drawable subjects: the exact rejected entries. No generation ran and nothing was charged; revise or remove these subjects and resubmit.",
+ "items": {
+ "type": "string"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}Output schema / properties / suggestedStyleAdded value: +{
+ "description": "Present only on a validation suggestion: the cleaned style text, for review. An empty string means the cleanup removed the style entirely (nothing in it was usable as a style) - replace it, or use styleReferences. Absent on refs-only requests. No generation ran and nothing was charged.",
+ "type": [
+ "null",
+ "string"
+ ]
+}Output schema / properties / suggestedSubjectsAdded value: +{
+ "description": "Present only on a validation suggestion: the cleaned subject list, one entry per image. Adopt these, or resubmit your own wording with validation set to skip.",
+ "items": {
+ "type": "string"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}generate_image_set4 fields changedInput schema / properties / background / descriptionPrevious value: -"Background as a 6-char hex color #RRGGBB (e.g. #ffffff, #2c3e50). Default is #ffffff. For transparent output, call the generate_transparent_image_set tool instead - this tool only produces solid-color backgrounds. Do not mention background in the style or image descriptions."New value: +"Background as a 6-char hex color #RRGGBB (e.g. #ffffff, #2c3e50). Default is #ffffff. For transparent output, call the generate_transparent_image_set tool instead - this tool only produces solid-color backgrounds. Do not mention background in the style or subject descriptions."Input schema / properties / imagesRemoved value: -{
- "description": "Either a list of image names (e.g. [\"home\", \"search\"]) or objects with description and filename (e.g. [{\"description\": \"compass rose\", \"filename\": \"overview.webp\"}])",
- "items": true,
- "type": [
- "null",
- "array"
- ]
-}Input schema / properties / subjectsAdded value: +{
+ "description": "Either a list of subject names (e.g. [\"home\", \"search\"]) or objects with description and filename (e.g. [{\"description\": \"compass rose\", \"filename\": \"overview.webp\"}])",
+ "items": true,
+ "type": [
+ "null",
+ "array"
+ ]
+}Input schema / requiredPrevious value: -[
- "style",
- "images"
-]New value: +[
+ "style",
+ "subjects"
+]generate_transparent_image_set3 fields changedInput schema / properties / imagesRemoved value: -{
- "description": "Either a list of image names (e.g. [\"home\", \"search\"]) or objects with description and filename (e.g. [{\"description\": \"compass rose\", \"filename\": \"overview.webp\"}])",
- "items": true,
- "type": [
- "null",
- "array"
- ]
-}Input schema / properties / subjectsAdded value: +{
+ "description": "Either a list of subject names (e.g. [\"home\", \"search\"]) or objects with description and filename (e.g. [{\"description\": \"compass rose\", \"filename\": \"overview.webp\"}])",
+ "items": true,
+ "type": [
+ "null",
+ "array"
+ ]
+}Input schema / requiredPrevious value: -[
- "style",
- "images"
-]New value: +[
+ "style",
+ "subjects"
+]generate_illustration1 field changedInput schema / properties / unpackTo / descriptionPrevious value: -"Path on the caller's local filesystem where the generated illustration should be saved. The server does NOT write here. After this call returns, you (the calling client) must download illustration.zip from the returned zip URL, extract it to this path yourself, then report the path to the user."New value: +"Path on the caller's local filesystem where the generated illustration should be saved. The server does NOT write here. After this call returns, you (the calling client) must download illustration.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL is short-lived."generate_image_set1 field changedInput schema / properties / unpackTo / descriptionPrevious value: -"Path on the caller's local filesystem where the generated files should be saved. The server does NOT write here. After this call returns, you (the calling client) must download images.zip from the returned zip URL, extract it to this path yourself, then report the path to the user."New value: +"Path on the caller's local filesystem where the generated files should be saved. The server does NOT write here. After this call returns, you (the calling client) must download images.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL is short-lived."generate_transparent_image_set1 field changedInput schema / properties / unpackTo / descriptionPrevious value: -"Path on the caller's local filesystem where the generated files should be saved. The server does NOT write here. After this call returns, you (the calling client) must download images.zip from the returned zip URL, extract it to this path yourself, then report the path to the user."New value: +"Path on the caller's local filesystem where the generated files should be saved. The server does NOT write here. After this call returns, you (the calling client) must download images.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL is short-lived."check_credits1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "remaining": {
+ "description": "Credits remaining on the API key.",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "remaining"
+ ],
+ "type": "object"
+}check_creditsgenerate_illustrationgenerate_image_setgenerate_transparent_image_setlist_recent_generationsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Icons for agentic development: search & fetch 366,000+ open-source icons as SVG/PNG. No API key.
Multilingual semantic SVG icon search with previews for AI coding agents. 20,000+ icons.
Image processing for AI agents: resize, convert, compress, crop, and web-ready AI-generated images.
AI image, video and audio generation for agents: banners, reveal videos, avatars, voice cloning.
Add one secure layer between your agents and this server.
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.
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.
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.
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.
