Skip to main content
Glama

Server Details

AI-agent image generation: image sets, character sets & illustration sets. Edit, extend, export.

Ownership verified
Status
Healthy
Uptime
99.9% over 68 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.6/5.0

Scored across 16 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: three generation tools are differentiated by output type (isolated subjects, one character, composed scenes), and their extend counterparts mirror them exactly. The reference and credit tools, plus listing versus fetching generations, are explicitly scoped and cross-referenced in descriptions, leaving no realistic ambiguity.

Naming Consistency5/5

All 16 tools follow a consistent snake_case verb_noun pattern (generate_*_set, extend_*_set, list_*, delete_*, check_credits, buy_credits). No mixed conventions or vague verbs are present.

Tool Count4/5

Sixteen tools is slightly above the typical sweet spot but every tool maps to a real operation in the generation lifecycle (credits, references, three generate/extend families, edit, export, fetch, delete). The count is well justified, though a few pairs could theoretically be merged without loss.

Completeness5/5

The surface covers the full lifecycle: credit balance and purchase, reference creation/list/deletion, three generation families with extension, delivery editing, platform export, generation retrieval/listing, and deletion. No obvious CRUD or workflow gaps remain for the stated image-generation domain.

Available Tools

16 tools
buy_creditsAInspect

Buy more credits for your API key. Returns a Stripe Checkout link for 1 to 10 credit packs, already tied to this key's account, so no sign-in is needed. Calling this charges nothing: open the link in a browser if you can, or give it to the user, and the user completes the payment there with a card or Stripe Link. The credits are added to this key within seconds of payment; call check_credits to confirm. The result gives the purchase's credits and price. Costs no credits.

NameRequiredDescriptionDefault
packsNoHow many credit packs to buy, 1 to 10. Defaults to 1.

Output Schema

NameRequiredDescription
packsYesCredit packs in this purchase.
creditsYesCredits added to the API key once paid.
priceUSDYesTotal price in US dollars.
expiresAtYesWhen the checkout link stops working (RFC 3339).
checkoutURLYesStripe Checkout link that completes the purchase.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only give generic hints (readOnlyHint=false, openWorldHint=true); the description adds the critical non-obvious behavior that calling it charges nothing and costs no credits, that the link is pre-tied to the key's account so no sign-in is needed, and that credits land within seconds. These are exactly the facts an agent needs to avoid mis-describing a purchase operation to a user.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action and the returned artifact, then flows through usage, timing, and cost. Slightly redundant at the tail: 'Calling this charges nothing' and 'Costs no credits' convey the same fact twice.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter mutation tool with an output schema present, the description covers everything needed: what it does, what it returns, that it is free, how the payment completes out-of-band, and how to confirm success. No gaps remain for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter has 100% schema description coverage ('How many credit packs to buy, 1 to 10. Defaults to 1'), so the schema already carries the semantics. The description's '1 to 10 credit packs' merely restates that range without adding format or selection guidance, making this baseline-3 territory.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Buy more credits for your API key') and immediately names the artifact produced ('a Stripe Checkout link'). It is clearly distinguishable from every sibling, especially check_credits, which it explicitly routes to for confirmation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains exactly how to use the result ('open the link in a browser if you can, or give it to the user'), what the user must do to complete payment, and names check_credits as the follow-up verification step. Both the usage context and the alternative verification flow are explicit.

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

check_creditsA
Read-onlyIdempotent
Inspect

Check how many image generation credits remain on your account: one balance shared by your MCP calls and the logospell.com generate page. Call it before generating to confirm the balance covers the call (each generation tool states its cost), or afterwards to see what is left. When credits run out, buy_credits returns a checkout link for more. It only reads the balance, changes nothing, and costs no credits.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
remainingYesCredits remaining on the API key.

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, so the safety profile is covered. The description still adds genuine context beyond them: the balance is shared between MCP calls and the logospell.com generate page, and the call itself consumes no credits. It does not discuss rate limits or auth, but those are not evidently relevant here.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, then usage timing, then the fallback to buy_credits. It runs a touch long with three sentences and parenthetical asides, but every sentence carries distinct information rather than restating the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and annotations plus a zero-parameter schema remove any remaining ambiguity. An agent has everything needed to decide when to call this and what to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so per the rubric the baseline is 4. The description correctly implies a no-argument call and adds the semantic that the returned balance is account-wide rather than per-generation-tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('check how many image generation credits remain on your account') and immediately scopes it to a single shared balance. It is clearly distinguishable from siblings like buy_credits and get_generations without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use on both sides: call before generating to confirm the balance covers the call, or afterwards to see what is left. It also names the alternative path (buy_credits) for the exhausted-credits case, leaving nothing to inference.

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

create_referenceAInspect

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 (to grow an existing set, use its extend tool instead: extend_image_set, extend_character_set or extend_illustration_set). 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. To update a reference, upload a new file to the same upload URL: its image is replaced and its ref_ token stays the same. Costs no credits.

NameRequiredDescriptionDefault
sourceImageNoOptional, with sourceGeneration: the delivered image filename to use as the reference, exactly as the generation's result or get_generations (the subjects, variations or scenes in promptJSON) lists it (e.g. "a_lotus_cradling_a_glowing_pearl.png"). An image larger than the reference limits is downscaled to fit automatically.
sourceGenerationNoOptional, 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.

Output Schema

NameRequiredDescription
refYesToken to pass to a tool's reference-image parameter.
expiresAtYesWhen the reference expires if left unused, RFC3339.
uploadURLYesURL to PUT or POST the image file to.

TDQS

A4.8/5.0
Behavior5/5

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

Far beyond the annotations: it discloses the out-of-band curl PUT upload flow, why images cannot be embedded in the call (base64/context-window rationale), accepted formats and hard limits (PNG/JPEG/WebP, 500KB, 64-768px), the 7-day expiry with each use restarting the window, key-scoped privacy, the update-by-re-upload semantics that preserve the ref_ token, and that it costs no credits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action and the returned token, and nearly every sentence carries operational content. The base64/context-window explanation is slightly lecturing for a 2-parameter tool, but it preempts a costly caller mistake, so it largely earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although an output schema exists, the description still names the two returned values, and it covers everything else an agent needs: format/size constraints, the out-of-band transport requirement, the no-upload shortcut, lifecycle and expiry, and the update path. Nothing material is left to inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and the description adds value on top by framing the two optional parameters as a coupled server-side alternative ('skip the upload entirely: pass sourceGeneration and sourceImage') rather than independent options. It does not, however, add anything the schema descriptions don't already cover about filename/id formatting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource ('Create an upload slot for a reference image') and immediately names the artifact it returns (upload URL + ref_ token). It also distinguishes itself from siblings by explicitly naming extend_image_set, extend_character_set and extend_illustration_set as the tools to use for a different job.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states exactly when to use it ('the ONLY way to supply reference images'), when to skip it entirely (own recent Logospell generation via sourceGeneration/sourceImage), and which alternative to reach for when growing an existing set. It even routes the agent to the specific extend tools by name.

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

delete_generationsA
DestructiveIdempotent
Inspect

Permanently delete one or more of your generations before their download window closes: each one's download URL stops working, and its images, its prompt.json and the full-resolution source kept for edit_set and export_set are removed from Logospell's servers. Call it only when the user asks to delete generations: it cannot be undone, the credits they cost are not refunded, and a deleted generation can no longer be edited or exported. Only the API key that made a generation can delete it. A set that grew over several calls has one id per call (list_recent_generations and get_generations show them); pass them all to delete the whole set in one call. Ids that are not found are reported without failing the call, which fails only when nothing was deleted. Up to 50 ids per call. Without this, every generation is removed automatically when its download window closes. Costs no credits.

NameRequiredDescriptionDefault
generationsYesThe ids of the generations to delete: the random segment of each one's download URL, as list_recent_generations returns it. A set that grew over several calls has one id per call; pass them all to delete the whole set.

Output Schema

NameRequiredDescription
deletedYesThe ids that were deleted.
notFoundNoIds that were not found for this API key or whose download window had closed; nothing was deleted for them.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructive/idempotent/not-readOnly, but the description adds substantial context: what is destroyed (download URL, images, prompt.json, full-resolution source for edit_set/export_set), that it cannot be undone, that credits are not refunded, the API-key ownership requirement, the 50-id cap, the not-found-ids-do-not-fail semantics, and that it costs no credits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action and its permanence, then details; every clause carries new information. It is a single dense run-on paragraph, which makes it harder to scan than a segmented form, but there is little wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive one-parameter tool with an output schema already describing returns, the description covers everything an agent needs: irreversible effects, auth scoping, batching limits, partial-failure behavior, and cost.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so the baseline is 3, and the description goes beyond it by defining the id format ('the random segment of each one's download URL'), explaining the multi-call set case, and stating the 50-ids-per-call limit that the schema does not encode.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Permanently delete one or more of your generations') plus the scope constraint (before the download window closes). It is clearly distinguishable from delete_references and from the automatic expiry mentioned later.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to call it ('only when the user asks to delete generations') and supplies the implicit alternative — if you do nothing, generations are removed automatically when the download window closes. It also names list_recent_generations and get_generations as the way to obtain the ids.

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

delete_referencesA
DestructiveIdempotent
Inspect

Permanently delete one or more references you created with create_reference: each one's image is removed from Logospell's servers and its ref_ token stops working in any later call. Call it only when the user asks to delete references: it cannot be undone. Only the API key that created a reference can delete it; list_references shows yours. Tokens that are not found are reported without failing the call, which fails only when nothing was deleted. Up to 50 tokens per call. Without this, a reference expires on its own 7 days after its last use or re-upload. Costs no credits.

NameRequiredDescriptionDefault
refsYesThe ref_ tokens of the references to delete, as create_reference or list_references returned them.

Output Schema

NameRequiredDescription
deletedYesThe ref_ tokens that were deleted.
notFoundNoTokens that were not found for this API key or had already expired; nothing was deleted for them.

TDQS

A4.8/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: images are removed from servers, ref_ tokens stop working, the action cannot be undone, tokens not found are reported without failing, the call fails only when nothing was deleted, 50-token limit, ownership by API key, and zero credit cost. These details are not present in the annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but front-loads the action and key constraints. It could be trimmed slightly (e.g., the credits sentence), but every sentence adds useful operational detail. It is well-structured for an agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description does not need to explain return values. It covers all other necessary aspects: scope, irreversible nature, ownership, token limits, error behavior, and the default expiry fallback. Nothing an agent needs to call this tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter description is already detailed, so the baseline is 3. The tool description adds value by clarifying that ref_ tokens are the identifiers returned by create_reference or list_references, and by specifying the 50-token limit, which is not in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: 'Permanently delete one or more references you created with create_reference'. It clearly distinguishes this tool from siblings such as list_references and create_reference by naming them and describing what deletion entails.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to call: 'Call it only when the user asks to delete references: it cannot be undone.' It also provides an alternative lifecycle path ('Without this, a reference expires on its own 7 days after its last use or re-upload') and names list_references for discovering tokens, leaving no ambiguity.

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

edit_setA
Idempotent
Inspect

Change how an existing image set, character set or illustration 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, a file size limit per image on webp (maxKB), and for a character set or a transparent image set its background (any color, or transparent). 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 get_generations reports the new levers. Free; no credits are spent. What the pictures show (the style or character, the subjects, variations or scenes, and the references) cannot be edited - a different picture is a new set.

On an illustration set, width and height go together and must be one of the batch's own sizes: the size its scenes were drawn at (get_generations' nativeWidth and nativeHeight) or an exact half, quarter and so on of it, down to 256 pixels on the shorter side. Format and quality apply as on the other sets; canvas, margin, sizing, background and maxKB do not. At the native size in the model's own format, the originals themselves are delivered.

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 set delivered transparent composes the images over white unless a background color is in force (given in the same call or kept from an earlier edit); jpg together with background "transparent" is rejected. background applies to character sets and transparent image sets only. Not available for sets generated before editing existed (they have no source).

The user asked for this change to see it: as soon as the call returns, fetch the replaced zip and show them every image exactly as delivered, each as its own file (open the extracted index.html, attach each file as it is, or give the viewer link). Never present a new image made from them.

NameRequiredDescriptionDefault
maxKBNoNew file size limit for each image, in KB, webp only: each image is encoded under it as on the set tools, its quality and the precision of its transparent edges lowered together only where needed, down to quality 70; a set below 70 keeps its quality and lowers only its edges. An image still over the limit is named in the result. 0 removes the limit. Left out, the current limit stays.
resetNotrue 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.
widthNoNew 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. On an illustration set they go together, as one of its own sizes (see the tool description).
canvasNoWith 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.
formatNoNew format: png, webp, or jpg. Left out, the current format stays. jpg has no alpha: on a set delivered transparent it composes the images over white unless a background color is in force (given in the same call or kept from an earlier edit).
heightNoNew delivered height in pixels, or 0 to stop fixing the height. Left out, the current height stays.
sizingNoNew 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.
qualityNoNew quality (1-100) for webp and jpg; ignored for png. Left out, the current quality stays.
backgroundNoCharacter sets and transparent image sets only: a #RRGGBB color composes every image over it and delivers an opaque set; "transparent" delivers the images with their alpha. Left out, the current background stays. Rejected on an image set generated on a color, whose color is in its pixels and cannot change.
generationYesThe 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.
minimumMarginNoNew minimum margin in pixels around each subject, with the set tools' bounds. Left out, the current margin stays.

Output Schema

NameRequiredDescription
widthNo
heightNo
imagesNo
leversNoThe delivery levers now in force: width, height, canvas, minimumMargin, sizing, format, quality, background, and maxKB when a file size limit is set; an illustration set has only width, height, format and quality.
zipURLNoThe set's download, unchanged, now serving the new delivery.
expiresAtNo
generationNo
deliveredAtNo
crispBaseSizeNoThe largest base size, in pixels, at which export_set keeps every density of this batch crisp at these levers (for an illustration set, a quarter of the longest side its scenes were drawn at, the largest it exports at); absent when no base size does.

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), it adds substantial context: free/no credits, in-place replacement of the same download URL, no history retained because identical levers yield identical bytes, that editing never extends the download window, jpg/alpha composition rules, background restrictions, and unavailability for pre-editing sets. This is consistent with — not contradictory to — the idempotent annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the description runs several dense paragraphs with overlapping detail already carried by the schema (e.g. width/height box mechanics, margin bounds) and ends with agent-facing presentation instructions. It is structured but longer than necessary; several sentences restate parameter-level content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter mutation tool with an output schema present, this is thorough: it covers edge cases (jpg transparency, unsupported sets), lever inheritance, reset behavior, and idempotency. Since an output schema exists, it needn't describe return values, and its remaining coverage is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description nonetheless adds cross-parameter semantics the schema does not, notably the illustration-set rule that width and height go together and must be one of the batch's own sizes, and the interaction between reset and other levers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a precise verb ('Change how...is delivered') and resource (image/character/illustration set), and explicitly distinguishes itself from generating: 'without generating again'. It also draws the boundary against siblings by stating what cannot be edited ('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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when this tool applies (adjust delivery levers on an existing set, free, no regeneration) and what to do instead when the picture itself must change. It does not explicitly name the alternative tools (generate_*/extend_*) by name, so routing is implied rather than spelled out.

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

export_setA
Idempotent
Inspect

Export an existing set for the web, iOS, Android and Flutter, free: every image at the base size you name and at every density each platform needs, laid out as each expects (web files with @2x and @3x and an srcset line, an iOS asset catalog with one imageset per image, Android res/ density buckets, Flutter asset folders with the pubspec lines), plus a viewer and a ledger. An image or character set exports as icons; an illustration set exports its scenes whole, for the illustrations in an app or site. One export per call: one batch of a set (a set that grew over several calls is exported batch by batch; the trees merge by folder) at one base size (a second size is a second call; names carry the size, so two sizes never collide). The files come from the set's full-resolution source, so each is the batch as it is currently delivered, scaled: an image or character set's size, canvas, sizing and margin all carry (edit_set changes them), and an illustration set's shape; no pixel comes from a delivered image. How large a batch exports crisp is its crispBaseSize: every generation and edit_set result states it, and list_recent_generations and get_generations report it. An image or character set takes base sizes from 16 to 256 (48 to 128 is the usual range for icons), its crisp size set by how many subjects or variations it holds at generation, and edits to its size, canvas, margin or sizing can move it; files up to 3x the 1x size (4x on Android) are always delivered, and where a density would enlarge a subject past its source pixels the ledger says so per tree ("soft": some blur) and by how much, never withholding a file. An illustration set takes base sizes from 16 up to its crispBaseSize, a quarter of the longest side its scenes were drawn at, so its export is always crisp. Not available for sets generated before editing existed (they have no source).

NameRequiredDescriptionDefault
formatNopng, webp, or jpg. Left out, the set's current format. iOS asset catalogs take no WebP, so a webp export's iOS tree is PNG at the same pixels (the ledger says so). jpg has no alpha: rejected while the set's background is transparent.
qualityNo1 to 100 for webp and jpg; ignored for png. Left out, the set's current quality (90 when it has none).
baseSizeYesThe base size: one even number that each platform reads in its own unit (CSS px on the web, pt on iOS, dp on Android), from 16 to 256 for an image or character set and from 16 to its crispBaseSize for an illustration set. It sizes the batch, not each file: every file is the batch's delivered image scaled so the batch's longest side is this number, so nothing exceeds it, a set delivered on one canvas gives files that all match it, and a set whose images wrap their own subjects gives files that differ the same way. The export holds files up to 3x it (4x on Android).
generationYesThe id of the set to export - the random segment of its download URL, as list_recent_generations returns it. One batch per call.

Output Schema

NameRequiredDescription
formatNo
ledgerNoThe export's account of itself: per tree (web, ios, android, flutter) the densities, format, largest file and fidelity (crisp, or soft, meaning some blur, with the largest enlargement past source pixels), and every file with its tree, image name, density and pixel size. Also inside the zip as ledger.json.
zipURLNoThe export zip; fetch and extract it as your first action after the call, the link expires with the set.
qualityNo
baseSizeNo
expiresAtNo
generationNo

TDQS

A4.3/5.0
Behavior5/5

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

With readOnlyHint=false, destructiveHint=false and idempotentHint=true already declared, the description adds substantial behavior: files derive from the full-resolution source rather than delivered pixels, 3x/4x caps, the "soft" ledger annotation when a density exceeds source pixels, jpg rejection under a transparent background, and iOS WebP being downgraded to PNG. No statement conflicts 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first clause, but the body is a dense, heavily parenthesized wall of text where base-size rules and crispness behavior are repeated across sentences. For a four-parameter export tool this is over-written, and several sentences re-document what the schema already states.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the description thoroughly covers batching, base-size ranges by set type, format/alpha interactions, and platform-specific layout. An agent has everything needed to call it correctly without opening other tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters are already documented in the schema, and much of the description's baseSize/format material restates it. The description's added value (one batch per call, size-collision avoidance, per-platform unit interpretation) is real but marginal against a fully covered schema, warranting the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a precise verb+resource ("Export an existing set") and immediately names the target platforms and the artifacts produced (web files with srcset, iOS asset catalog, Android res/ buckets, Flutter folders). It further distinguishes behavior by set type (image/character = icons, illustration = scenes whole), so it is unmistakable against siblings like edit_set or the generate/extend tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operational context: one export per call, one batch of a set, one base size per call, and a second size being a second call. It also states an exclusion ("Not available for sets generated before editing existed"). It never names a sibling as the alternative for a different task, so it stops short of a full 5.

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

extend_character_setAInspect

Add more variations to a set made with generate_character_set. The new batch is generated exactly as the set was - the same character text and character references, with the background (a color or transparent), size, format, quality, margin, sizing and file size limit of the batch you name - so a set grows past the 16-variation limit of one call without drifting; only the variations are new. A set made with character references is sent them again, and only them; a set made from text alone is sent up to 3 images from its first batch, so the new variations are drawn like the rest of the set. The new batch joins the set: listings show the batches together, and the whole set's download window restarts. Each call costs what a generation of the set costs: 1 credit per call. Run generation calls sequentially, never in parallel - only one generation runs at a time per API key.

Variations that do not describe distinct, drawable variations are refused before anything is generated or charged. To change the character, the size, or anything else, start a new set instead; to change only how an existing set is delivered, use edit_set.

IMPORTANT - variation description rules:

  • Describe each variation by what the character is doing in it: its action and pose, what it is feeling and how strongly, its expression, and anything it holds or wears. Specific feelings at specific intensities give the most expressive sets (a slow-burning silent glare and a mid-leap scream read very differently).

  • Each image is ONE isolated character, not a scene: describe the character and what it directly holds or interacts with, never the surrounding setting, environment, landscape, or sky.

  • Do not use size words (large, tiny, small, etc.) on the character as a whole - all images are produced at the same size. Size words on what it holds or wears are fine (e.g. 'holding a tiny umbrella').

  • Maximum 16 variations per call.

  • If the variation 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.

  • Showing the result: as soon as the call returns, show the user every delivered image before you put them to use, then keep working without waiting for a reply (unless the user asked to review first), so they can ask for a change before anything is built on them. Show each image exactly as delivered, as its own file: the files are the product, and their exact size, margin and background are what the user asked for. Never present a new image made from them, even to check them; it hides all three. Files on disk or a link in your context are not delivery. Where you can open files on the user's machine, open the extracted index.html with the host's file opener; it shows each image at its delivered size with its dimensions. Where you can attach files to your reply, attach each delivered file as it is (attaching is not inspecting). Otherwise give the online viewer link and the zip link. Show every image unless the user asked for only some, and say in one line what you left out; if you can show none, say the set was made but you could not show it, and give the viewer link.

NameRequiredDescriptionDefault
unpackToNoPath 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).
generationYesThe id of any batch in the set to extend: the random segment of its download URL (.../download/<id>/images.zip), also returned by list_recent_generations. The new batch is generated exactly as that set: the same tool, character text and character references, and the named batch's background, size, format, quality, margin, sizing and file size limit.
validationNoHow to handle the automatic variation check before generating. One of: suggest (the default) - if the new variation 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-variation 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.
variationsYesWhat the character is doing in each image, one entry per image: either a list of descriptions or objects with description and filename (e.g. [{"description": "waving hello", "filename": "waving.png"}]). Each entry is one isolated variation of the same character - its pose, action, expression, how strongly it feels it, and anything it holds or wears - not a scene or setting. Entries must be distinct: entries differing only in case, punctuation, or spacing are rejected as the same. Write each variation as plain text, with no list marker such as "1." or "-" in front, no square brackets, and no invisible characters.

Output Schema

NameRequiredDescription
formatNoThe delivered image format.
imagesNoThe generated images: each one's file name inside the zip, its variation, and its pixel width and height.
zipURLNoDownload URL for the zip of generated images. Time-limited; expiresAt states the deadline.
unpackToNoThe caller-supplied local extraction path, echoed back.
characterNo
expiresAtNoWhen the download URL expires.
remainingNoCredits remaining after this call.
backgroundNoThe background color used, or transparent.
manifestURLNo
rejectedCharacterNoPresent only when the request was rejected because the character text does not appear to describe a character: the submitted text. No generation ran and nothing was charged; revise it (or drop it and use characterReferences) and resubmit.
rejectedVariationsNoPresent only when the request was rejected because some variations do not appear to describe distinct, drawable variations: the exact rejected entries. No generation ran and nothing was charged; revise or remove them and resubmit.
suggestedCharacterNoPresent only on a validation suggestion: the cleaned character text, for review. An empty string means the cleanup removed the character text entirely (nothing in it said who or what the character is) - replace it, or use characterReferences. Absent when the character text was not checked (references only, or an extension). No generation ran and nothing was charged.
suggestedVariationsNoPresent only on a validation suggestion: the cleaned variation list, one entry per image. Adopt these, or resubmit your own wording with validation set to skip.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the mutation/open-world profile; the description supplies the costly details an agent actually needs: 1 credit per call, variations rejected before charging, background/size/format/margin inherited from the named batch, character references resent (or up to 3 first-batch images used for text-only sets), the set's download window restarting, and per-API-key serialization. It adds substantial value beyond annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and behavior, then organized under a clear 'IMPORTANT' rules block and a 'Showing the result' block, so it is navigable despite its length. The delivery section is long and partly duplicates the variations schema rules, so not every sentence is strictly load-bearing, but the ordering is sensible and the critical constraints come first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a credit-costing, non-idempotent generation tool with four parameters, the description covers cost, sequencing, rejection semantics, validation modes, set-growth behavior, and how delivered files must be surfaced to the user. With an output schema and full schema coverage present, nothing an agent needs to invoke this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description goes further by explaining how the id is found ('the random segment of its download URL'), how the validation modes interact with a suggested cleanup and resubmission, and the variation rules (action/pose/feeling/expression, no size words on the character, one isolated character not a scene, max 16). Some of this overlaps the schema's own variations text, which keeps it from a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a precise verb+resource ('Add more variations to a set made with generate_character_set') and immediately names the parent tool and the 16-variation limit it exists to bypass. An agent can distinguish this from generate_character_set, extend_image_set and extend_illustration_set by the character-set framing, and the 'only the variations are new' clause pinpoints what the call produces.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use (grow past 16 variations without drifting), when-not to ('to change the character, the size, or anything else, start a new set instead'), and a named alternative for delivery changes ('use edit_set'). It also states sequencing ('run generation calls sequentially, never in parallel') and rate-limit retry behavior, leaving nothing to inference.

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

extend_illustration_setAInspect

Add more scenes to a set made with generate_illustration_set. The new batch is drawn exactly as the set was - the same style text and style references, with the format and quality of the batch you name, and its size unless width and height are given (any size generate_illustration_set lists, so one set can hold a wide hero and tall posters). A set made with style references is sent them again, and only them; a set made from text alone is sent up to 3 images from its first batch, so the new scenes are drawn like the rest of the set. The new batch joins the set: listings show the batches together, and the whole set's download window restarts. Each call costs 1 credit. Run generation calls sequentially, never in parallel - only one generation runs at a time per API key.

Scenes that do not describe distinct illustrations are refused before anything is generated or charged. To change the style, start a new set instead; to change only how a batch is delivered, use edit_set.

  • Maximum 6 scenes per call. Scene max length: 2500 characters each.

  • If a "Rate limit exceeded" error is returned, wait the suggested number of seconds before retrying. Do not retry immediately.

  • Showing the result: as soon as the call returns, show the user every delivered image before you put them to use, then keep working without waiting for a reply (unless the user asked to review first), so they can ask for a change before anything is built on them. Show each image exactly as delivered, as its own file: the files are the product, and their exact size, margin and background are what the user asked for. Never present a new image made from them, even to check them; it hides all three. Files on disk or a link in your context are not delivery. Where you can open files on the user's machine, open the extracted index.html with the host's file opener; it shows each image at its delivered size with its dimensions. Where you can attach files to your reply, attach each delivered file as it is (attaching is not inspecting). Otherwise give the online viewer link and the zip link. Show every image unless the user asked for only some, and say in one line what you left out; if you can show none, say the set was made but you could not show it, and give the viewer link.

NameRequiredDescriptionDefault
widthNoOptional width in pixels, together with height: one of the supported pixel pairs generate_illustration_set lists. Left out, the named batch's current size.
heightNoOptional height in pixels, together with width. Left out, the named batch's current size.
scenesYesWhat each illustration shows, one entry per illustration: either a list of scene descriptions or objects with description and filename (e.g. [{"description": "a harbor market at dawn", "filename": "hero.webp"}]). A scene is prose and may name a setting, a moment, the light and the camera. Entries must describe distinct illustrations; without a filename, the file is named from the start of its scene.
unpackToNoPath 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).
generationYesThe id of any batch in the set to extend: the random segment of its download URL (.../download/<id>/images.zip), also returned by list_recent_generations. The new batch is drawn exactly as that set: the same style text and style references, and the named batch's format and quality.

Output Schema

NameRequiredDescription
styleNo
formatNoThe delivered image format.
imagesNoThe illustrations: each one's file name inside the zip, its scene, and its pixel width and height.
zipURLNoDownload URL for the zip of illustrations. Time-limited; expiresAt states the deadline.
unpackToNoThe caller-supplied local extraction path, echoed back.
expiresAtNoWhen the download URL expires.
remainingNoCredits remaining after this call.
manifestURLNo
rejectedStyleNoPresent 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.
rejectedScenesNoPresent only when the request was rejected because some scenes do not appear to describe distinct illustrations: the exact rejected entries. No generation ran and nothing was charged; revise or remove them and resubmit.

TDQS

A4.5/5.0
Behavior4/5

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

With annotations already covering the safety profile, the description adds substantial context annotations cannot: 1 credit per call, refusal of non-distinct scenes before any charge, that the set's download window restarts, and how style references versus text-only sets are re-sent. It stops short of describing what the returned payload looks like, but an output schema exists so that is less critical.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and constraints are front-loaded, which is good, but roughly half the text is a repetitive 'Showing the result' block restating the same delivery rules three times (show exactly as delivered, never present a new image, show every image unless asked otherwise). Valuable content, but it dilutes the tool-selection signal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given five parameters, an output schema, and full annotation coverage, nothing an agent needs in order to call this correctly is missing — cost, limits, sequencing, retry behavior, alternative tools, and delivery expectations are all present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description earns the extra point by explaining the width/height coupling and its purpose ('any size generate_illustration_set lists, so one set can hold a wide hero and tall posters') and by clarifying that the named batch supplies format and quality rather than just style.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource: 'Add more scenes to a set made with generate_illustration_set.' It names the parent tool that creates the set and, via 'to change the style, start a new set instead', implicitly separates itself from the other extend_* siblings that serve different set types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes to alternatives with conditions: 'To change the style, start a new set instead; to change only how a batch is delivered, use edit_set.' It also states hard operating constraints — max 6 scenes, 2500 chars each, one generation at a time per API key, and the retry rule after a rate-limit error.

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

extend_image_setAInspect

Add more subjects to a set made with generate_image_set. The new batch is generated exactly as the set was - the same style text and style references, with the background (a color or transparent), size, format, quality, margin, sizing and file size limit of the batch you name - so a set grows past the 16-subject limit of one call without drifting; only the subjects are new. A set made with style references is sent them again, and only them; a set made from text alone is sent up to 3 images from its first batch, so the new subjects are drawn like the rest of the set. The new batch joins the set: listings show the batches together, and the whole set's download window restarts. Each call costs what a generation of the set costs: 1 credit per call. Run generation calls sequentially, never in parallel - only one generation runs at a time per API key.

Subjects that do not describe distinct, drawable subjects are refused before anything is generated or charged. To change the style, the size, or anything else, start a new set instead; to change only how an existing set is delivered, use edit_set.

IMPORTANT - subject description rules:

  • Subject 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 composed scenes (a figure set within an environment), use generate_illustration_set 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').

  • 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).

  • Maximum 16 subjects per call.

  • If the subject 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.

  • Showing the result: as soon as the call returns, show the user every delivered image before you put them to use, then keep working without waiting for a reply (unless the user asked to review first), so they can ask for a change before anything is built on them. Show each image exactly as delivered, as its own file: the files are the product, and their exact size, margin and background are what the user asked for. Never present a new image made from them, even to check them; it hides all three. Files on disk or a link in your context are not delivery. Where you can open files on the user's machine, open the extracted index.html with the host's file opener; it shows each image at its delivered size with its dimensions. Where you can attach files to your reply, attach each delivered file as it is (attaching is not inspecting). Otherwise give the online viewer link and the zip link. Show every image unless the user asked for only some, and say in one line what you left out; if you can show none, say the set was made but you could not show it, and give the viewer link.

NameRequiredDescriptionDefault
subjectsYesEither 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. Write each subject as plain text, with no list marker such as "1." or "-" in front, no square brackets, and no invisible characters.
unpackToNoPath 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).
generationYesThe id of any batch in the set to extend: the random segment of its download URL (.../download/<id>/images.zip), also returned by list_recent_generations. The new batch is generated exactly as that set: the same tool, style text and style references, and the named batch's background, size, format, quality, margin, sizing and file size limit.
validationNoHow to handle the automatic subject check before generating. One of: suggest (the default) - if the new subject 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.

Output Schema

NameRequiredDescription
styleNo
formatNoThe delivered image format.
imagesNoThe generated images: each one's file name inside the zip, its subject, and its pixel width and height.
zipURLNoDownload URL for the zip of generated images. Time-limited; expiresAt states the deadline.
unpackToNoThe caller-supplied local extraction path, echoed back.
expiresAtNoWhen the download URL expires.
remainingNoCredits remaining after this call.
backgroundNoThe background color used, or transparent.
manifestURLNo
rejectedStyleNoPresent 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.
suggestedStyleNoPresent 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 when the style was not checked (references only, or an extension). No generation ran and nothing was charged.
rejectedSubjectsNoPresent 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.
suggestedSubjectsNoPresent 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.

TDQS

A4.7/5.0
Behavior5/5

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

Goes far beyond the annotations: discloses cost (1 credit per call), a serialization constraint (never run generation calls in parallel, one generation per API key), rate-limit retry behavior, that subjects are validated and refused before charging, that the whole set's download window restarts, and that the zip URL expires. Annotations only say non-readonly, non-idempotent, open-world.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose and cost, which is good, but the body is very long and the 'Showing the result' block runs several sentences with parenthetical restatements ('attaching is not inspecting', 'files on disk or a link in your context are not delivery') that could be tightened. The subject-rule bullets and delivery instructions together dominate the description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a paid, non-idempotent generation tool with an output schema, the description covers everything an agent needs: inheritance semantics, validation flow, cost, concurrency limits, failure modes, and how to present deliverables. Return format is correctly left to the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description adds real meaning by documenting the three validation modes ('suggest'/'skip'/'auto-apply') and the exact resubmit-after-suggestion workflow, which the schema leaves as an unspecified string. The generation parameter's 'any batch id from the set' semantics are also clarified beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb (add subjects) and resource (an existing set made with generate_image_set), and explicitly scopes what is inherited (style, background, size, format) versus what is new (only the subjects). It is immediately distinguishable from generate_image_set, extend_character_set, extend_illustration_set, and edit_set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing rules are given: to change style or size, 'start a new set instead'; to change delivery only, 'use edit_set'; for composed scenes, 'use generate_illustration_set instead'. The 16-subject overflow rationale explains the primary when-to-use condition.

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

generate_character_setAInspect

Generate a SET of images of ONE character - the same mascot, creature, person, or single product in every image - one isolated variation of it per image, on one SOLID-COLOR background or a TRANSPARENT one (sticker and reaction packs, mascot poses, a product shown many ways; transparent for stickers that drop onto any chat or backdrop). The character parameter describes who or what it is; characterReferences shows it in up to 3 reference images, the most faithful way to keep one specific character; the variations parameter says what it is doing in each image; the background parameter is a color or "transparent". Returns a zip download URL. Cost: 1 credit per call. Run generation calls sequentially, never in parallel - only one generation runs at a time per API key.

For many DIFFERENT subjects sharing one style, use generate_image_set instead.

Output formats: PNG (lossless), JPEG, or WebP; JPEG has no alpha channel, so a set delivered transparent is PNG or WebP.

Size and quality considerations match generate_image_set: leaving width and height unset delivers native resolution (best quality, varies between generations; relative sizing scales nothing but a variation far larger than the rest, fill scales each variation to its frame); fixing them resamples to that box, and fixing one axis lets the other hug each variation.

IMPORTANT - character and variation description rules for best results: The character and its references decide WHO appears in every image; each variation decides only what that one character is doing in its image.

  • Describe each variation by what the character is doing in it: its action and pose, what it is feeling and how strongly, its expression, and anything it holds or wears. Specific feelings at specific intensities give the most expressive sets (a slow-burning silent glare and a mid-leap scream read very differently).

  • Each image is ONE isolated character, not a scene: describe the character and what it directly holds or interacts with, never the surrounding setting, environment, landscape, or sky.

  • Do not use size words (large, tiny, small, etc.) on the character as a whole - all images are produced at the same size. Size words on what it holds or wears are fine (e.g. 'holding a tiny umbrella').

  • Do not put background color or background descriptions in the character or variation text.

  • No captions, labels, or annotations. Text that is part of a depicted object is fine.

  • Do not connect the images to each other; each must be drawable on its own.

  • Maximum 16 images per generation.

  • Character description max length: 500 characters. Variation 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 variation (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 variations in relation to one another, one scale for the whole set; fill scales each variation on its own to fill its frame less the margin, the icon-set convention, giving up relative size and enlarging variations smaller than the frame (the result says by how much). Both can be changed later with edit_set.

  • If the character 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".

  • To add more variations to a set, call extend_character_set with the id of any batch in it, as often as the set needs.

  • If a "Rate limit exceeded" error is returned, wait the suggested number of seconds before retrying. Do not retry immediately.

  • Showing the result: as soon as the call returns, show the user every delivered image before you put them to use, then keep working without waiting for a reply (unless the user asked to review first), so they can ask for a change before anything is built on them. Show each image exactly as delivered, as its own file: the files are the product, and their exact size, margin and background are what the user asked for. Never present a new image made from them, even to check them; it hides all three. Files on disk or a link in your context are not delivery. Where you can open files on the user's machine, open the extracted index.html with the host's file opener; it shows each image at its delivered size with its dimensions. Where you can attach files to your reply, attach each delivered file as it is (attaching is not inspecting). Otherwise give the online viewer link and the zip link. Show every image unless the user asked for only some, and say in one line what you left out; if you can show none, say the set was made but you could not show it, and give the viewer link.

NameRequiredDescriptionDefault
maxKBNoA file size limit for each image, in KB (1 KB = 1024 bytes), 10 to 10240; webp only (rejected with png or jpg). An image that fits keeps the quality set above; one that does not has its quality and the precision of its transparent edges lowered together, 5 quality points at a time down to 70, until it fits (a set below 70 keeps its quality and lowers only its edges), so images in a set can land at different qualities and the faintest edges of a busy transparent image can soften. An image still over the limit at the last step is delivered anyway and named in the result. For platforms that cap each file's size. Omit for no limit.
widthNoDelivered 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 variation at that scale plus the margin (so images in the set differ on it); give neither and images arrive at their native size (relative sizing scales nothing but a variation far larger than the rest, fill scales each variation to its frame) - 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 variation 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.
formatNoOutput format: png, jpg, or webp. Defaults to png. jpg has no alpha channel, so a set delivered transparent is png or webp.
heightNoDelivered height in pixels; see width for how the two combine (both: an exact box; one: the other axis hugs each variation; neither: native size).
sizingNoHow variations 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 variation stays small in its frame. fill scales each variation 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 variation smaller than the frame, which the result reports when it happens.
qualityNoImage quality for jpg/webp (1-100). Defaults to 90.
unpackToNoPath 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).
characterNoThe character every image depicts, in words: who or what it is and how it looks (a mascot, a creature, a person, or a single product or object). Provide this, characterReferences, or both - the references show what it looks like, and this text adds details and, if a reference image shows more than one character, says which of them to draw.
backgroundNoThe background every image sits on: a 6-char hex color #RRGGBB (e.g. #ffffff, #2c3e50), or "transparent" for images with no background that drop onto any backdrop. Default is #ffffff. Do not mention background in the character or variation descriptions.
validationNoHow to handle the automatic character/variation check before generating. One of: suggest (the default) - if the character and variation 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-variation 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.
variationsYesWhat the character is doing in each image, one entry per image: either a list of descriptions or objects with description and filename (e.g. [{"description": "waving hello", "filename": "waving.png"}]). Each entry is one isolated variation of the same character - its pose, action, expression, how strongly it feels it, and anything it holds or wears - not a scene or setting. Entries must be distinct: entries differing only in case, punctuation, or spacing are rejected as the same. Write each variation as plain text, with no list marker such as "1." or "-" in front, no square brackets, and no invisible characters.
minimumMarginNoMinimum margin in pixels around each variation. 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 variation and never falls below this (only the set's largest variation sits exactly on it); with fill sizing every variation touches it on one axis.
characterReferencesNoUp to 3 reference images of the character every image depicts, alone or alongside the character text. 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. The set shows the character alone, not the rest of the reference images. To add more variations to a set later, use extend_character_set. Provide at least one of character and characterReferences.

Output Schema

NameRequiredDescription
formatNoThe delivered image format.
imagesNoThe generated images: each one's file name inside the zip, its variation, and its pixel width and height.
zipURLNoDownload URL for the zip of generated images. Time-limited; expiresAt states the deadline.
unpackToNoThe caller-supplied local extraction path, echoed back.
characterNo
expiresAtNoWhen the download URL expires.
remainingNoCredits remaining after this call.
backgroundNoThe background color used, or transparent.
manifestURLNo
rejectedCharacterNoPresent only when the request was rejected because the character text does not appear to describe a character: the submitted text. No generation ran and nothing was charged; revise it (or drop it and use characterReferences) and resubmit.
rejectedVariationsNoPresent only when the request was rejected because some variations do not appear to describe distinct, drawable variations: the exact rejected entries. No generation ran and nothing was charged; revise or remove them and resubmit.
suggestedCharacterNoPresent only on a validation suggestion: the cleaned character text, for review. An empty string means the cleanup removed the character text entirely (nothing in it said who or what the character is) - replace it, or use characterReferences. Absent when the character text was not checked (references only, or an extension). No generation ran and nothing was charged.
suggestedVariationsNoPresent only on a validation suggestion: the cleaned variation list, one entry per image. Adopt these, or resubmit your own wording with validation set to skip.

TDQS

A4.7/5.0
Behavior5/5

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

The annotations already establish readOnly=false, openWorld=true, idempotent=false, and destructive=false, but the description adds substantial behavioral context: cost of one credit per call, sequential-only execution, rate-limit handling, validation modes, zip URL delivery, and detailed post-generation display requirements. Nothing contradicts 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose and sibling differentiation are front-loaded, which is good, but the description is extremely long and includes many detailed instructions that overlap with the schema and could be moved to separate guidance. It is informative but bloated for a tool definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of the tool, its 13 parameters, annotations, and output schema, the description is complete enough for an agent to invoke it correctly. It covers purpose, alternatives, constraints, validation, delivery expectations, and error handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already carries substantial parameter meaning. The description still adds useful constraints beyond the schema, including maximum 16 images, 500-character character limits, 200-character variation limits, no-background-in-text rules, no-size-word guidance, and the validation resubmission behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it generates a set of images of one character, with one isolated variation per image. It also distinguishes the tool from its sibling generate_image_set by naming the different-subject/shared-style case, so an agent can select it without opening another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to use this tool versus generate_image_set and extend_character_set, including how to add more variations later. It also gives concrete operational guidance such as running generation calls sequentially, handling rate-limit errors, and the validation workflow.

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

generate_illustration_setAInspect

Generate a SET of illustrations in one consistent style - scenes, environments, hero images, banners, posters, portraits - one composed illustration per scene, every illustration in the call at the same size. The style parameter says how they are drawn, styleReferences shows that style in up to 3 reference images, and the scenes parameter says what each illustration shows. Without style references, the first scene is drawn first and the rest are drawn to match it. 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 separate isolated subjects on a plain or transparent background (icons, sprites, asset packs), use generate_image_set instead; for one character in many variations, generate_character_set.

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. To add scenes later, at this size or another from the list, use extend_illustration_set; to deliver a batch again at another of its sizes, format or quality, use edit_set.

2752x1536, 1376x768, 688x384 2048x2048, 1024x1024, 512x512, 256x256 1024x4128, 512x2064, 256x1032 704x5856, 352x2928 3168x1344, 1584x672, 792x336 1696x2528, 848x1264, 424x632 2528x1696, 1264x848, 632x424 1792x2400, 896x1200, 448x600 4128x1024, 2064x512, 1032x256 2400x1792, 1200x896, 600x448 1856x2304, 928x1152, 464x576 2304x1856, 1152x928, 576x464 5856x704, 2928x352 1536x2752, 768x1376, 384x688

IMPORTANT - style and scene rules for best results:

  • The style is how every illustration is drawn (medium, technique, palette, lighting treatment); each scene is what one illustration shows (its subject, setting, moment and composition). Keep the shared look in the style, so the set stays consistent.

  • Scene craft, since each call costs a credit: name the light and the time of day (cold blue twilight, one warm lamp from the left); fix the camera (wide establishing shot, three-quarter portrait, viewed from the doorway); and ask for open space on a named side when text will be laid over the illustration later.

  • Illustrations carry no text unless a scene asks for it: write any words that belong in an illustration, such as the name on a shop sign, into its scene.

  • Scenes must describe distinct illustrations; a scene that describes nothing to draw, or repeats another, is rejected, as is a style that does not describe a visual style.

  • Maximum 6 scenes per call. Style max length: 500 characters. Scene max length: 2500 characters each.

  • Formats: png (default, lossless), jpg, webp. quality (1-100) applies to jpg and webp; default 90.

  • To add more scenes to a set, call extend_illustration_set with the id of any batch in it, as often as the set needs.

  • If a "Rate limit exceeded" error is returned, wait the suggested number of seconds before retrying. Do not retry immediately.

  • Showing the result: as soon as the call returns, show the user every delivered image before you put them to use, then keep working without waiting for a reply (unless the user asked to review first), so they can ask for a change before anything is built on them. Show each image exactly as delivered, as its own file: the files are the product, and their exact size, margin and background are what the user asked for. Never present a new image made from them, even to check them; it hides all three. Files on disk or a link in your context are not delivery. Where you can open files on the user's machine, open the extracted index.html with the host's file opener; it shows each image at its delivered size with its dimensions. Where you can attach files to your reply, attach each delivered file as it is (attaching is not inspecting). Otherwise give the online viewer link and the zip link. Show every image unless the user asked for only some, and say in one line what you left out; if you can show none, say the set was made but you could not show it, and give the viewer link.

NameRequiredDescriptionDefault
styleNoHow every illustration in the set is drawn: medium, technique, palette, and lighting treatment (e.g. painterly storybook watercolor with warm golden light). Text that does not describe a visual style is rejected. Provide this, styleReferences, or both - together they hold a style most tightly.
widthYesWidth in pixels, together with height: one of the supported pixel pairs listed in the tool description. Every scene is delivered at this size.
formatNoOutput format: png, jpg, or webp. Defaults to png.
heightYesHeight in pixels, together with width: one of the supported pixel pairs listed in the tool description.
scenesYesWhat each illustration shows, one entry per illustration: either a list of scene descriptions or objects with description and filename (e.g. [{"description": "a harbor market at dawn", "filename": "hero.webp"}]). A scene is prose and may name a setting, a moment, the light and the camera. Entries must describe distinct illustrations; without a filename, the file is named from the start of its scene.
qualityNoImage quality for jpg/webp (1-100). Defaults to 90.
unpackToNoPath 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).
styleReferencesNoUp to 3 reference images that define the style, alone or alongside the style parameter. 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. Their rendering carries over; their subjects and composition do not. Provide at least one of style and styleReferences.

Output Schema

NameRequiredDescription
styleNo
formatNoThe delivered image format.
imagesNoThe illustrations: each one's file name inside the zip, its scene, and its pixel width and height.
zipURLNoDownload URL for the zip of illustrations. Time-limited; expiresAt states the deadline.
unpackToNoThe caller-supplied local extraction path, echoed back.
expiresAtNoWhen the download URL expires.
remainingNoCredits remaining after this call.
manifestURLNo
rejectedStyleNoPresent 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.
rejectedScenesNoPresent only when the request was rejected because some scenes do not appear to describe distinct illustrations: the exact rejected entries. No generation ran and nothing was charged; revise or remove them and resubmit.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare readOnly=false, openWorld=true, idempotent=false, destructive=false. The description adds cost (1 credit per call), concurrency constraints (one generation at a time per API key), rate-limit retry behavior, input validation rejection rules (scene/style/length limits), and URL expiry on the returned zip — none of which the annotations convey. This is substantial disclosure beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well front-loaded (purpose, alternatives, sizes, craft rules) and the pixel table and bulleted rule blocks are scannable. It is nonetheless very long, and the closing 'Showing the result' block restates the same delivery requirement several ways ('Show each image exactly as delivered,' 'Show every image,' 'attaching is not inspecting'), which costs more words than it needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an 8-parameter generation tool with nested scene objects and an output schema, the description covers everything an agent needs: validation constraints, credit cost, sequential execution, sibling routing, and what to do with the returned zip. No gaps remain for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline would be 3, but the description goes well beyond it: it encodes the full supported pixel-pair matrix (with the note that any other pair is rejected), explains that style vs scenes is 'how' vs 'what', and describes the styleReferences ref_ token upload workflow that the schema only alludes to. This is meaning the agent could not derive from the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+scope: 'Generate a SET of illustrations in one consistent style,' then enumerates the scene types it covers. It explicitly distinguishes itself from generate_image_set (isolated subjects/icons) and generate_character_set (one character, many variations), so an agent can route without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States when to use alternatives by name (generate_image_set for icons/sprites, generate_character_set for character variations), and when to use extend_illustration_set and edit_set afterwards. It also gives operational exclusions ('Run generation calls sequentially, never in parallel'), which is exactly the routing guidance an agent needs.

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

generate_image_setAInspect

Generate a cohesive SET of custom images on one SOLID-COLOR background or a TRANSPARENT one, each one a separate isolated subject sharing one visual style (icons, logos, game assets, UI elements, sprite/asset packs; transparent for images that drop onto any backdrop). The style parameter says how everything is drawn; the subjects parameter says what to draw; the background parameter is a color or "transparent". 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). Returns a zip download URL. Cost: 1 credit per call. When a solid color fits the user's use case, it is the faster choice. Run generation calls sequentially, never in parallel - only one generation runs at a time per API key.

For composed, full-bleed pictures (scenes, hero images, banners, posters, environments), use generate_illustration_set instead.

For several images of ONE character (the same mascot, creature, person, or product in different poses or moods), use generate_character_set instead.

Output formats: PNG (lossless), JPEG, or WebP; JPEG has no alpha channel, so a set delivered transparent is PNG 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, unscaled under relative sizing except that a subject far larger than the rest is shrunk (fill sizing scales each subject to its frame), which produces the highest quality results and is recommended when images will be post-processed, composited, or resized downstream. On a solid background, 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 16; 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).

  • Subject 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 composed scenes (a figure set within an environment), use generate_illustration_set 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 16 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. Subject 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_set.

  • Icons: the subject count sets how large a batch's icons can later be exported with export_set, crisp at every density: about a 136px base size with 13 to 16 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".

  • To add more subjects to a set, call extend_image_set with the id of any batch in it, as often as the set needs.

  • If a "Rate limit exceeded" error is returned, wait the suggested number of seconds before retrying. Do not retry immediately.

  • Showing the result: as soon as the call returns, show the user every delivered image before you put them to use, then keep working without waiting for a reply (unless the user asked to review first), so they can ask for a change before anything is built on them. Show each image exactly as delivered, as its own file: the files are the product, and their exact size, margin and background are what the user asked for. Never present a new image made from them, even to check them; it hides all three. Files on disk or a link in your context are not delivery. Where you can open files on the user's machine, open the extracted index.html with the host's file opener; it shows each image at its delivered size with its dimensions. Where you can attach files to your reply, attach each delivered file as it is (attaching is not inspecting). Otherwise give the online viewer link and the zip link. Show every image unless the user asked for only some, and say in one line what you left out; if you can show none, say the set was made but you could not show it, and give the viewer link.

NameRequiredDescriptionDefault
maxKBNoA file size limit for each image, in KB (1 KB = 1024 bytes), 10 to 10240; webp only (rejected with png or jpg). An image that fits keeps the quality set above; one that does not has its quality and the precision of its transparent edges lowered together, 5 quality points at a time down to 70, until it fits (a set below 70 keeps its quality and lowers only its edges), so images in a set can land at different qualities and the faintest edges of a busy transparent image can soften. An image still over the limit at the last step is delivered anyway and named in the result. For platforms that cap each file's size. Omit for no limit.
styleNoVisual 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).
widthNoDelivered 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 (relative sizing scales nothing but a subject far larger than the rest, fill scales each subject to its frame) - 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.
formatNoOutput format: png, jpg, or webp. Defaults to png. jpg has no alpha channel, so a set delivered transparent is png or webp.
heightNoDelivered height in pixels; see width for how the two combine (both: an exact box; one: the other axis hugs each subject; neither: native size).
sizingNoHow 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.
qualityNoImage quality for jpg/webp (1-100). Defaults to 90.
subjectsYesEither 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. Write each subject as plain text, with no list marker such as "1." or "-" in front, no square brackets, and no invisible characters.
unpackToNoPath 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).
backgroundNoThe background every image sits on: a 6-char hex color #RRGGBB (e.g. #ffffff, #2c3e50), or "transparent" for images with no background that drop onto any backdrop. Default is #ffffff. Do not mention background in the style or subject descriptions.
validationNoHow 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.
minimumMarginNoMinimum 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.
styleReferencesNoUp 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). 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.

Output Schema

NameRequiredDescription
styleNo
formatNoThe delivered image format.
imagesNoThe generated images: each one's file name inside the zip, its subject, and its pixel width and height.
zipURLNoDownload URL for the zip of generated images. Time-limited; expiresAt states the deadline.
unpackToNoThe caller-supplied local extraction path, echoed back.
expiresAtNoWhen the download URL expires.
remainingNoCredits remaining after this call.
backgroundNoThe background color used, or transparent.
manifestURLNo
rejectedStyleNoPresent 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.
suggestedStyleNoPresent 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 when the style was not checked (references only, or an extension). No generation ran and nothing was charged.
rejectedSubjectsNoPresent 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.
suggestedSubjectsNoPresent 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.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare mutating/open-world/non-idempotent/non-destructive; the description goes far beyond by disclosing the 1-credit-per-call cost, the per-API-key serialization of generation calls, rate-limit retry behavior, that the result is an expiring zip URL, and that unpackTo is client-side (the server does not write files). It also discloses that fixed sizes apply Lanczos resampling that may soften detail, a real quality trade-off. Nothing contradicts 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the sibling alternatives are correctly front-loaded in the first three paragraphs, and rules are bulleted, but the body is very large and mixes API contract with long agent workflow instructions (how to display delivered images, attaching vs inspecting, opening index.html). Much of that is valuable guidance but it pushes the definition well past a concise tool contract and buries later parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter, credit-costing generation tool with an output schema, the description covers everything an agent needs to call it correctly: credit cost, sequencing constraints, style/subject content rules, validation modes, sizing behavior, rate-limit handling, and the expiring zip/unpackTo handoff. Return-value detail is largely in the output schema, yet the description still flags URL expiry, which is the operationally critical piece.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning the schema does not: it explains the skip/auto-apply validation workflow and when to resubmit with 'skip', the relative-vs-fill sizing consequences, and the 256-512 per-axis range relationship. It still restates a fair amount that already lives verbatim in the schema descriptions (background default, jpg alpha caveat, subject distinctness), so it is valuable but partly redundant.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb (generate), resource (a set of custom images on a solid or transparent background), and scope (isolated subjects sharing one style, with icon/logo/sprite-pack examples). It explicitly distinguishes itself from two siblings by naming generate_illustration_set for full-bleed scenes and generate_character_set for one character, so an agent can route correctly without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use-this vs when-to-use-alternatives: composed scenes go to generate_illustration_set, one character goes to generate_character_set, adding subjects goes to extend_image_set, and solid color is recommended as the faster choice when it fits. It also states the sequential-execution requirement and the rate-limit retry rule, which are operational 'when' conditions an agent must honor.

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

get_generationsA
Read-onlyIdempotent
Inspect

Get the full record of generations of yours by id: each one's download URL and expiry, promptJSON (the original call, so the generation can be extended or reproduced), its current delivery settings, where its reference images came from, and its parents (the set it extends, or the generations its references were copied from). The ids come from list_recent_generations or from a generation's download URL. Ids that are not found are reported without failing the call, which fails only when none was found. Up to 50 ids per call. Costs no credits.

NameRequiredDescriptionDefault
generationsYesThe ids of the generations to get: the random segment of each one's download URL.

Output Schema

NameRequiredDescription
notFoundNoIds that were not found for this API key or whose download window has closed.
generationsYesThe generations found, in the order asked for, each with its full record.

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations, which only cover read-only/idempotent/non-destructive. The description discloses partial-failure semantics ('Ids that are not found are reported without failing the call, which fails only when none was found'), a hard batch limit of 50 ids, and that the call costs no credits — all behavioral facts an agent cannot infer from the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose, then adds id provenance, failure semantics, limits, and cost in a logical order. It is a dense run-on paragraph with some nesting, but each sentence carries distinct operational information and none is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be re-explained; the description nonetheless frames them. Combined with the documented error semantics, batch cap, and zero-cost note, an agent has everything needed to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema description already states that each id is 'the random segment of each one's download URL'. The description repeats that mapping and adds the 50-id batch bound, but contributes no further per-parameter syntax or format detail, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Get the full record of generations') and enumerates what the record contains: download URL and expiry, promptJSON, delivery settings, reference image provenance, and parents. It also distinguishes itself from the sibling that produces the ids (list_recent_generations), so an agent can tell the two apart without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells the agent where valid ids come from ('list_recent_generations or from a generation's download URL'), which routes it to the correct sibling for discovery. It does not state exclusions or contrast against the other get-style siblings (list_references), but the usage context is clear.

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

list_recent_generationsA
Read-onlyIdempotent
Inspect

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 an index, newest first and a page at a time (limit and offset; total says how many there are): each generation's id, tool, creation and expiry times, zip download URL, its style or character text, its image count, whether it can be edited, and its parents (the set it extends, or the generations its references were copied from). For a generation's full record (the original call as promptJSON, where its reference images came from, and its current delivery settings), for example to extend or reproduce a set, pass its id to get_generations. Costs no credits.

NameRequiredDescriptionDefault
limitNoMaximum number of generations to return (default 5). With offset it pages through your generations, newest first; total in the output says how many there are. To fetch generations whose ids you know, use get_generations.
offsetNoHow many of the newest generations to skip before returning up to limit of them (default 0), for paging: the two oldest of total generations are limit 2 at offset total minus 2.

Output Schema

NameRequiredDescription
totalYesHow many unexpired generations this key has in all. More than offset plus the rows returned means there are more to page through with offset.
generationsYesRecent successful generations, newest first.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds real context beyond them: billing occurs on completion, downloads stay available until original expiry even if the response never arrived, re-listing does not extend expiry, and it costs no credits. These are non-obvious behavioral facts an agent must know before retrying.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and every clause carries information, but it is one very dense paragraph that also enumerates returned fields already covered by the output schema, which is slight duplication. Efficient for its content, just not tightly trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only listing tool with an output schema, the description is more than complete: it covers the recovery use case, expiry/billing semantics, site-origin caveat, paging, and the routing rule to get_generations. No gap an agent would need to fill.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented, including the paging relationship between limit and offset. The description restates the newest-first paging model but adds little syntax or meaning beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List your recent successful generations and return their download URLs') and immediately distinguishes itself from the sibling get_generations by scope (index vs. full record). An agent can tell exactly which tool to pick without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when-to-use scenario (recovering a generation whose result message was lost, e.g. a dropped connection) and names the alternative and its condition: pass an id to get_generations for the full record, or fetch by known ids there instead of paging here. Nothing is left to inference.

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

list_referencesA
Read-onlyIdempotent
Inspect

List your live reference images, most recently used or uploaded first: each one's ref_ token, its upload URL, when it expires, whether its image is in place, and the generation image it was filled from, if any. Use it to recover a token you lost instead of uploading the image again. References are private to your API key, at most 10 are live at once, and each expires 7 days after its last use or re-upload. Costs no credits.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
totalYesHow many references are live on this API key.
referencesYesYour live references, most recently used or uploaded first.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, but the description adds operationally important context: references are private to the API key, at most 10 are live at once, each expires 7 days after last use or re-upload, and the call costs no credits. These constraints are not derivable from the annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads what is listed and its ordering, then the use case, then the operating constraints. Dense but every clause carries new information; no filler or repetition of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless read tool with an output schema, the description covers everything the agent needs: purpose, ordering, per-item contents, the recovery use case, privacy scoping, the 10-item cap, the 7-day expiry rule, and the zero credit cost.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4 per the rubric. The description goes slightly beyond by naming the fields in each returned record (ref_ token, upload URL, expiry, image-in-place flag, source generation image), which helps even though an output schema exists.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (list), resource (live reference images), scope (live, private to API key), and ordering (most recently used or uploaded first), then enumerates the fields returned for each item. The 'recover a token you lost instead of uploading the image again' clause implicitly contrasts it with create_reference, so the agent can distinguish it from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear scenario ('Use it to recover a token you lost') and names the alternative it replaces ('instead of uploading the image again'), which points at create_reference. It does not state any when-not conditions or other valid uses (e.g. auditing expiry), so it falls short of fully explicit routing.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updates
    • Changedextend_character_set1 field changed
      • changedInput schema / properties / variations / description
        Previous value: -"What the character is doing in each image, one entry per image: either a list of descriptions or objects with description and filename (e.g. [{\"description\": \"waving hello\", \"filename\": \"waving.png\"}]). Each entry is one isolated variation of the same character - its pose, action, expression, how strongly it feels it, and anything it holds or wears - not a scene or setting. Entries must be distinct: entries differing only in case, punctuation, or spacing are rejected as the same. Text can use only letters, numbers, dashes, spaces, and apostrophes, and must start and end with a letter or number."New value: +"What the character is doing in each image, one entry per image: either a list of descriptions or objects with description and filename (e.g. [{\"description\": \"waving hello\", \"filename\": \"waving.png\"}]). Each entry is one isolated variation of the same character - its pose, action, expression, how strongly it feels it, and anything it holds or wears - not a scene or setting. Entries must be distinct: entries differing only in case, punctuation, or spacing are rejected as the same. Write each variation as plain text, with no list marker such as \"1.\" or \"-\" in front, no square brackets, and no invisible characters."
    • Changedextend_image_set1 field changed
      • changedInput schema / properties / subjects / description
        Previous 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."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. Write each subject as plain text, with no list marker such as \"1.\" or \"-\" in front, no square brackets, and no invisible characters."
    • Changedgenerate_character_set1 field changed
      • changedInput schema / properties / variations / description
        Previous value: -"What the character is doing in each image, one entry per image: either a list of descriptions or objects with description and filename (e.g. [{\"description\": \"waving hello\", \"filename\": \"waving.png\"}]). Each entry is one isolated variation of the same character - its pose, action, expression, how strongly it feels it, and anything it holds or wears - not a scene or setting. Entries must be distinct: entries differing only in case, punctuation, or spacing are rejected as the same. Text can use only letters, numbers, dashes, spaces, and apostrophes, and must start and end with a letter or number."New value: +"What the character is doing in each image, one entry per image: either a list of descriptions or objects with description and filename (e.g. [{\"description\": \"waving hello\", \"filename\": \"waving.png\"}]). Each entry is one isolated variation of the same character - its pose, action, expression, how strongly it feels it, and anything it holds or wears - not a scene or setting. Entries must be distinct: entries differing only in case, punctuation, or spacing are rejected as the same. Write each variation as plain text, with no list marker such as \"1.\" or \"-\" in front, no square brackets, and no invisible characters."
    • Changedgenerate_image_set1 field changed
      • changedInput schema / properties / subjects / description
        Previous 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."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. Write each subject as plain text, with no list marker such as \"1.\" or \"-\" in front, no square brackets, and no invisible characters."
  2. 2 tool updates
    • Changedextend_illustration_set2 fields changed
      • changedInput schema / properties / scenes / description
        Previous value: -"What each illustration shows, one entry per picture: either a list of scene descriptions or objects with description and filename (e.g. [{\"description\": \"a harbor market at dawn\", \"filename\": \"hero.webp\"}]). A scene is prose and may name a setting, a moment, the light and the camera. Entries must describe distinct pictures; without a filename, the file is named from the start of its scene."New value: +"What each illustration shows, one entry per illustration: either a list of scene descriptions or objects with description and filename (e.g. [{\"description\": \"a harbor market at dawn\", \"filename\": \"hero.webp\"}]). A scene is prose and may name a setting, a moment, the light and the camera. Entries must describe distinct illustrations; without a filename, the file is named from the start of its scene."
      • changedOutput schema / properties / rejectedScenes / description
        Previous value: -"Present only when the request was rejected because some scenes do not appear to describe distinct pictures: the exact rejected entries. No generation ran and nothing was charged; revise or remove them and resubmit."New value: +"Present only when the request was rejected because some scenes do not appear to describe distinct illustrations: the exact rejected entries. No generation ran and nothing was charged; revise or remove them and resubmit."
    • Changedgenerate_illustration_set2 fields changed
      • changedInput schema / properties / scenes / description
        Previous value: -"What each illustration shows, one entry per picture: either a list of scene descriptions or objects with description and filename (e.g. [{\"description\": \"a harbor market at dawn\", \"filename\": \"hero.webp\"}]). A scene is prose and may name a setting, a moment, the light and the camera. Entries must describe distinct pictures; without a filename, the file is named from the start of its scene."New value: +"What each illustration shows, one entry per illustration: either a list of scene descriptions or objects with description and filename (e.g. [{\"description\": \"a harbor market at dawn\", \"filename\": \"hero.webp\"}]). A scene is prose and may name a setting, a moment, the light and the camera. Entries must describe distinct illustrations; without a filename, the file is named from the start of its scene."
      • changedOutput schema / properties / rejectedScenes / description
        Previous value: -"Present only when the request was rejected because some scenes do not appear to describe distinct pictures: the exact rejected entries. No generation ran and nothing was charged; revise or remove them and resubmit."New value: +"Present only when the request was rejected because some scenes do not appear to describe distinct illustrations: the exact rejected entries. No generation ran and nothing was charged; revise or remove them and resubmit."
  3. 8 tool updates
    • Changededit_set7 fields changed
      • addedInput schema / properties / maxKB
        Added value: +{
        +  "description": "New file size limit for each image, in KB, webp only: each image is encoded under it as on the set tools, its quality and the precision of its transparent edges lowered together only where needed, down to quality 70; a set below 70 keeps its quality and lowers only its edges. An image still over the limit is named in the result. 0 removes the limit. Left out, the current limit stays.",
        +  "type": [
        +    "null",
        +    "integer"
        +  ]
        +}
      • addedOutput schema / properties / images / items / properties / bytes
        Added value: +{
        +  "description": "The image file's size in bytes.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / images / items / properties / maskLevels
        Added value: +{
        +  "description": "Under a file size limit (maxKB): how many transparency levels this image kept; 256 is exact.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / images / items / properties / overBudget
        Added value: +{
        +  "description": "Under a file size limit (maxKB): true when this image is still over the limit at the lowest step (quality 70, or the set's own when that is lower).",
        +  "type": "boolean"
        +}
      • addedOutput schema / properties / images / items / properties / quality
        Added value: +{
        +  "description": "Under a file size limit (maxKB): the quality this image was delivered at.",
        +  "type": "integer"
        +}
      • changedOutput schema / properties / levers / description
        Previous value: -"The delivery levers now in force: width, height, canvas, minimumMargin, sizing, format, quality, background; an illustration set has only width, height, format and quality."New value: +"The delivery levers now in force: width, height, canvas, minimumMargin, sizing, format, quality, background, and maxKB when a file size limit is set; an illustration set has only width, height, format and quality."
      • addedOutput schema / properties / levers / properties / maxKB
        Added value: +{
        +  "type": "integer"
        +}
    • Changedextend_character_set5 fields changed
      • changedInput schema / properties / generation / description
        Previous value: -"The id of any batch in the set to extend: the random segment of its download URL (.../download/<id>/images.zip), also returned by list_recent_generations. The new batch is generated exactly as that set: the same tool, character text and character references, and the named batch's background, size, format, quality, margin and sizing."New value: +"The id of any batch in the set to extend: the random segment of its download URL (.../download/<id>/images.zip), also returned by list_recent_generations. The new batch is generated exactly as that set: the same tool, character text and character references, and the named batch's background, size, format, quality, margin, sizing and file size limit."
      • addedOutput schema / properties / images / items / properties / bytes
        Added value: +{
        +  "description": "The image file's size in bytes.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / images / items / properties / maskLevels
        Added value: +{
        +  "description": "Under a file size limit (maxKB): how many transparency levels this image kept; 256 is exact.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / images / items / properties / overBudget
        Added value: +{
        +  "description": "Under a file size limit (maxKB): true when this image is still over the limit at the lowest step (quality 70, or the set's own when that is lower).",
        +  "type": "boolean"
        +}
      • addedOutput schema / properties / images / items / properties / quality
        Added value: +{
        +  "description": "Under a file size limit (maxKB): the quality this image was delivered at.",
        +  "type": "integer"
        +}
    • Changedextend_illustration_set4 fields changed
      • addedOutput schema / properties / images / items / properties / bytes
        Added value: +{
        +  "description": "The image file's size in bytes.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / images / items / properties / maskLevels
        Added value: +{
        +  "description": "Under a file size limit (maxKB): how many transparency levels this image kept; 256 is exact.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / images / items / properties / overBudget
        Added value: +{
        +  "description": "Under a file size limit (maxKB): true when this image is still over the limit at the lowest step (quality 70, or the set's own when that is lower).",
        +  "type": "boolean"
        +}
      • addedOutput schema / properties / images / items / properties / quality
        Added value: +{
        +  "description": "Under a file size limit (maxKB): the quality this image was delivered at.",
        +  "type": "integer"
        +}
    • Changedextend_image_set5 fields changed
      • changedInput schema / properties / generation / description
        Previous value: -"The id of any batch in the set to extend: the random segment of its download URL (.../download/<id>/images.zip), also returned by list_recent_generations. The new batch is generated exactly as that set: the same tool, style text and style references, and the named batch's background, size, format, quality, margin and sizing."New value: +"The id of any batch in the set to extend: the random segment of its download URL (.../download/<id>/images.zip), also returned by list_recent_generations. The new batch is generated exactly as that set: the same tool, style text and style references, and the named batch's background, size, format, quality, margin, sizing and file size limit."
      • addedOutput schema / properties / images / items / properties / bytes
        Added value: +{
        +  "description": "The image file's size in bytes.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / images / items / properties / maskLevels
        Added value: +{
        +  "description": "Under a file size limit (maxKB): how many transparency levels this image kept; 256 is exact.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / images / items / properties / overBudget
        Added value: +{
        +  "description": "Under a file size limit (maxKB): true when this image is still over the limit at the lowest step (quality 70, or the set's own when that is lower).",
        +  "type": "boolean"
        +}
      • addedOutput schema / properties / images / items / properties / quality
        Added value: +{
        +  "description": "Under a file size limit (maxKB): the quality this image was delivered at.",
        +  "type": "integer"
        +}
    • Changedgenerate_character_set5 fields changed
      • addedInput schema / properties / maxKB
        Added value: +{
        +  "description": "A file size limit for each image, in KB (1 KB = 1024 bytes), 10 to 10240; webp only (rejected with png or jpg). An image that fits keeps the quality set above; one that does not has its quality and the precision of its transparent edges lowered together, 5 quality points at a time down to 70, until it fits (a set below 70 keeps its quality and lowers only its edges), so images in a set can land at different qualities and the faintest edges of a busy transparent image can soften. An image still over the limit at the last step is delivered anyway and named in the result. For platforms that cap each file's size. Omit for no limit.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / images / items / properties / bytes
        Added value: +{
        +  "description": "The image file's size in bytes.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / images / items / properties / maskLevels
        Added value: +{
        +  "description": "Under a file size limit (maxKB): how many transparency levels this image kept; 256 is exact.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / images / items / properties / overBudget
        Added value: +{
        +  "description": "Under a file size limit (maxKB): true when this image is still over the limit at the lowest step (quality 70, or the set's own when that is lower).",
        +  "type": "boolean"
        +}
      • addedOutput schema / properties / images / items / properties / quality
        Added value: +{
        +  "description": "Under a file size limit (maxKB): the quality this image was delivered at.",
        +  "type": "integer"
        +}
    • Changedgenerate_illustration_set4 fields changed
      • addedOutput schema / properties / images / items / properties / bytes
        Added value: +{
        +  "description": "The image file's size in bytes.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / images / items / properties / maskLevels
        Added value: +{
        +  "description": "Under a file size limit (maxKB): how many transparency levels this image kept; 256 is exact.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / images / items / properties / overBudget
        Added value: +{
        +  "description": "Under a file size limit (maxKB): true when this image is still over the limit at the lowest step (quality 70, or the set's own when that is lower).",
        +  "type": "boolean"
        +}
      • addedOutput schema / properties / images / items / properties / quality
        Added value: +{
        +  "description": "Under a file size limit (maxKB): the quality this image was delivered at.",
        +  "type": "integer"
        +}
    • Changedgenerate_image_set5 fields changed
      • addedInput schema / properties / maxKB
        Added value: +{
        +  "description": "A file size limit for each image, in KB (1 KB = 1024 bytes), 10 to 10240; webp only (rejected with png or jpg). An image that fits keeps the quality set above; one that does not has its quality and the precision of its transparent edges lowered together, 5 quality points at a time down to 70, until it fits (a set below 70 keeps its quality and lowers only its edges), so images in a set can land at different qualities and the faintest edges of a busy transparent image can soften. An image still over the limit at the last step is delivered anyway and named in the result. For platforms that cap each file's size. Omit for no limit.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / images / items / properties / bytes
        Added value: +{
        +  "description": "The image file's size in bytes.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / images / items / properties / maskLevels
        Added value: +{
        +  "description": "Under a file size limit (maxKB): how many transparency levels this image kept; 256 is exact.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / images / items / properties / overBudget
        Added value: +{
        +  "description": "Under a file size limit (maxKB): true when this image is still over the limit at the lowest step (quality 70, or the set's own when that is lower).",
        +  "type": "boolean"
        +}
      • addedOutput schema / properties / images / items / properties / quality
        Added value: +{
        +  "description": "Under a file size limit (maxKB): the quality this image was delivered at.",
        +  "type": "integer"
        +}
    • Changedget_generations3 fields changed
      • changedOutput schema / properties / generations / items / properties / levers / description
        Previous value: -"The delivery levers now in force (width, height, canvas, minimumMargin, sizing, format, quality, background; an illustration set has width, height, format and quality): the first delivery's until edit_set changes them. Absent on sets from before editing existed."New value: +"The delivery levers now in force (width, height, canvas, minimumMargin, sizing, format, quality, background, and maxKB when a file size limit is set; an illustration set has width, height, format and quality): the first delivery's until edit_set changes them. Absent on sets from before editing existed."
      • addedOutput schema / properties / generations / items / properties / levers / properties / maxKB
        Added value: +{
        +  "type": "integer"
        +}
      • changedOutput schema / properties / generations / items / properties / promptJSON / description
        Previous value: -"The batch's own prompt.json, verbatim - the same bytes that ship inside the zip. What it asked for (the style or character, the list and the references) is the original call, and no edit can change it; its delivery settings (width, height, canvas, minimumMargin, sizing, format, quality) are the current delivery, which edit_set rewrites, so reusing this reproduces the generation as it stands now rather than as first delivered. The edited flag says whether that has happened. Its background is the color the set was generated on, or transparent (a set generated transparent stays transparent here after an edit changes its background to a color; levers holds the color). Its shape follows the tool named in its own tool field. Image sets carry style, subjects as {description, filename} pairs, format, quality, minimumMargin, validation, width and height when an axis was fixed, background (a color, or transparent), and styleReferences as zip-relative paths when the call used them; character sets carry character, variations and characterReferences in those places; illustration sets carry style, styleReferences, scenes, width, height, format and quality. Read each entry's description (subjects[], variations[] or scenes[]) to reproduce a set: an entry 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. What it asked for (the style or character, the list and the references) is the original call, and no edit can change it; its delivery settings (width, height, canvas, minimumMargin, sizing, format, quality, maxKB) are the current delivery, which edit_set rewrites, so reusing this reproduces the generation as it stands now rather than as first delivered. The edited flag says whether that has happened. Its background is the color the set was generated on, or transparent (a set generated transparent stays transparent here after an edit changes its background to a color; levers holds the color). Its shape follows the tool named in its own tool field. Image sets carry style, subjects as {description, filename} pairs, format, quality, minimumMargin, validation, width and height when an axis was fixed, background (a color, or transparent), and styleReferences as zip-relative paths when the call used them; character sets carry character, variations and characterReferences in those places; illustration sets carry style, styleReferences, scenes, width, height, format and quality. Read each entry's description (subjects[], variations[] or scenes[]) to reproduce a set: an entry given in object form has a description that differs from its filename, so search.webp may have been asked for as a magnifying glass."
  4. 4 tool updates
    • Changedexport_set1 field changed
      • changedInput schema / properties / format / description
        Previous value: -"png, webp, or jpg. Left out, the set's current format. iOS asset catalogs take no WebP, so a webp export's iOS tree is PNG at the same pixels (the ledger says so). jpg has no alpha: rejected for a transparent set unless the set is currently composed over a color."New value: +"png, webp, or jpg. Left out, the set's current format. iOS asset catalogs take no WebP, so a webp export's iOS tree is PNG at the same pixels (the ledger says so). jpg has no alpha: rejected while the set's background is transparent."
    • Changedgenerate_character_set1 field changed
      • changedInput schema / properties / format / description
        Previous value: -"Output format: png, jpg, or webp. Defaults to png. jpg has no alpha channel, so a transparent set is png or webp."New value: +"Output format: png, jpg, or webp. Defaults to png. jpg has no alpha channel, so a set delivered transparent is png or webp."
    • Changedgenerate_image_set1 field changed
      • changedInput schema / properties / format / description
        Previous value: -"Output format: png, jpg, or webp. Defaults to png. jpg has no alpha channel, so a transparent set is png or webp."New value: +"Output format: png, jpg, or webp. Defaults to png. jpg has no alpha channel, so a set delivered transparent is png or webp."
    • Changedget_generations1 field changed
      • changedOutput schema / properties / generations / items / properties / promptJSON / description
        Previous value: -"The batch's own prompt.json, verbatim - the same bytes that ship inside the zip. What it asked for (the style or character, the list and the references) is the original call, and no edit can change it; its delivery settings (width, height, canvas, minimumMargin, sizing, format, quality) are the current delivery, which edit_set rewrites, so reusing this reproduces the generation as it stands now rather than as first delivered. The edited flag says whether that has happened. Its background is the color the set was generated on, or transparent (an edit that composes a transparent set over a color leaves it transparent here; levers holds the color). Its shape follows the tool named in its own tool field. Image sets carry style, subjects as {description, filename} pairs, format, quality, minimumMargin, validation, width and height when an axis was fixed, background (a color, or transparent), and styleReferences as zip-relative paths when the call used them; character sets carry character, variations and characterReferences in those places; illustration sets carry style, styleReferences, scenes, width, height, format and quality. Read each entry's description (subjects[], variations[] or scenes[]) to reproduce a set: an entry 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. What it asked for (the style or character, the list and the references) is the original call, and no edit can change it; its delivery settings (width, height, canvas, minimumMargin, sizing, format, quality) are the current delivery, which edit_set rewrites, so reusing this reproduces the generation as it stands now rather than as first delivered. The edited flag says whether that has happened. Its background is the color the set was generated on, or transparent (a set generated transparent stays transparent here after an edit changes its background to a color; levers holds the color). Its shape follows the tool named in its own tool field. Image sets carry style, subjects as {description, filename} pairs, format, quality, minimumMargin, validation, width and height when an axis was fixed, background (a color, or transparent), and styleReferences as zip-relative paths when the call used them; character sets carry character, variations and characterReferences in those places; illustration sets carry style, styleReferences, scenes, width, height, format and quality. Read each entry's description (subjects[], variations[] or scenes[]) to reproduce a set: an entry given in object form has a description that differs from its filename, so search.webp may have been asked for as a magnifying glass."
  5. 1 tool update
    • Changededit_set2 fields changed
      • changedInput schema / properties / background / description
        Previous value: -"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."New value: +"Character sets and transparent image sets only: a #RRGGBB color composes every image over it and delivers an opaque set; \"transparent\" delivers the images with their alpha. Left out, the current background stays. Rejected on an image set generated on a color, whose color is in its pixels and cannot change."
      • changedInput schema / properties / format / description
        Previous value: -"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 in force (given in the same call or kept from an earlier edit)."New value: +"New format: png, webp, or jpg. Left out, the current format stays. jpg has no alpha: on a set delivered transparent it composes the images over white unless a background color is in force (given in the same call or kept from an earlier edit)."
  6. 2 tool updates
    • Changedget_generations1 field changed
      • changedOutput schema / properties / generations / items / properties / parents / description
        Previous value: -"Ids of the generations whose delivered images seeded this one's references - the set lineage. Absent when this generation extended nothing."New value: +"Ids of the generations this one came from: for a batch made with an extend tool, its set's first batch; otherwise the generations its sourced references were copied from (create_reference's sourceGeneration). Only a parent made by the same tool on the same kind of background, a color or transparent, is in this one's set; any other only supplied reference images. Absent when neither applies."
    • Changedlist_recent_generations1 field changed
      • changedOutput schema / properties / generations / items / properties / parents / description
        Previous value: -"Ids of the generations whose delivered images seeded this one's references: the set lineage, for gathering a whole set's ids."New value: +"Ids of the generations this one came from: for a batch made with an extend tool, its set's first batch; otherwise the generations its sourced references were copied from (create_reference's sourceGeneration). Only a parent made by the same tool on the same kind of background, a color or transparent, is in this one's set; any other only supplied reference images. To gather a whole set's ids, follow only those (get_generations' promptJSON shows each one's tool and background)."
  7. 17 tool updates
    • Changedcreate_reference1 field changed
      • changedInput schema / properties / sourceImage / description
        Previous value: -"Optional, with sourceGeneration: the delivered image filename to use as the reference, exactly as the generation's result, its manifest, or get_generations (the subjects in promptJSON) lists it (e.g. \"a_lotus_cradling_a_glowing_pearl.png\"). An image larger than the reference limits is downscaled to fit automatically."New value: +"Optional, with sourceGeneration: the delivered image filename to use as the reference, exactly as the generation's result or get_generations (the subjects, variations or scenes in promptJSON) lists it (e.g. \"a_lotus_cradling_a_glowing_pearl.png\"). An image larger than the reference limits is downscaled to fit automatically."
    • Removededit_illustration
    • Removededit_image_set
    • Addededit_set
    • Removedexport_icons
    • Addedexport_set
    • Changedextend_character_set6 fields changed
      • changedOutput schema / properties / background / description
        Previous value: -"The background color used; absent for transparent sets."New value: +"The background color used, or transparent."
      • changedOutput schema / properties / images / description
        Previous value: -"The generated images: variation description, filename inside the zip, and pixel width and height."New value: +"The generated images: each one's file name inside the zip, its variation, and its pixel width and height."
      • addedOutput schema / properties / images / items / properties / description
        Added value: +{
        +  "description": "The subject, variation or scene this image was made from, as the call gave it.",
        +  "type": "string"
        +}
      • addedOutput schema / properties / images / items / properties / filename / description
        Added value: +"The image's file name inside the zip."
      • removedOutput schema / properties / images / items / properties / name
        Removed value: -{
        -  "type": "string"
        -}
      • changedOutput schema / properties / images / items / required
        Previous value: -[
        -  "name",
        -  "filename"
        -]New value: +[
        +  "filename",
        +  "description"
        +]
    • Addedextend_illustration_set
    • Changedextend_image_set7 fields changed
      • changedOutput schema / properties / background / description
        Previous value: -"The background color used; absent for transparent sets."New value: +"The background color used, or transparent."
      • changedOutput schema / properties / images / description
        Previous value: -"The generated images: subject name, filename inside the zip, and pixel width and height."New value: +"The generated images: each one's file name inside the zip, its subject, and its pixel width and height."
      • addedOutput schema / properties / images / items / properties / description
        Added value: +{
        +  "description": "The subject, variation or scene this image was made from, as the call gave it.",
        +  "type": "string"
        +}
      • addedOutput schema / properties / images / items / properties / filename / description
        Added value: +"The image's file name inside the zip."
      • removedOutput schema / properties / images / items / properties / name
        Removed value: -{
        -  "type": "string"
        -}
      • changedOutput schema / properties / images / items / required
        Previous value: -[
        -  "name",
        -  "filename"
        -]New value: +[
        +  "filename",
        +  "description"
        +]
      • changedOutput schema / properties / suggestedStyle / description
        Previous value: -"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."New value: +"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 when the style was not checked (references only, or an extension). No generation ran and nothing was charged."
    • Changedgenerate_character_set8 fields changed
      • changedInput schema / properties / background / description
        Previous value: -"Background as a 6-char hex color #RRGGBB (e.g. #ffffff, #2c3e50). Default is #ffffff. For transparent output, call the generate_transparent_character_set tool instead - this tool only produces solid-color backgrounds. Do not mention background in the character or variation descriptions."New value: +"The background every image sits on: a 6-char hex color #RRGGBB (e.g. #ffffff, #2c3e50), or \"transparent\" for images with no background that drop onto any backdrop. Default is #ffffff. Do not mention background in the character or variation descriptions."
      • changedInput schema / properties / format / description
        Previous value: -"Output format: png, jpg, or webp. Defaults to png."New value: +"Output format: png, jpg, or webp. Defaults to png. jpg has no alpha channel, so a transparent set is png or webp."
      • changedOutput schema / properties / background / description
        Previous value: -"The background color used; absent for transparent sets."New value: +"The background color used, or transparent."
      • changedOutput schema / properties / images / description
        Previous value: -"The generated images: variation description, filename inside the zip, and pixel width and height."New value: +"The generated images: each one's file name inside the zip, its variation, and its pixel width and height."
      • addedOutput schema / properties / images / items / properties / description
        Added value: +{
        +  "description": "The subject, variation or scene this image was made from, as the call gave it.",
        +  "type": "string"
        +}
      • addedOutput schema / properties / images / items / properties / filename / description
        Added value: +"The image's file name inside the zip."
      • removedOutput schema / properties / images / items / properties / name
        Removed value: -{
        -  "type": "string"
        -}
      • changedOutput schema / properties / images / items / required
        Previous value: -[
        -  "name",
        -  "filename"
        -]New value: +[
        +  "filename",
        +  "description"
        +]
    • Removedgenerate_illustration
    • Addedgenerate_illustration_set
    • Changedgenerate_image_set9 fields changed
      • changedInput schema / properties / background / description
        Previous 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."New value: +"The background every image sits on: a 6-char hex color #RRGGBB (e.g. #ffffff, #2c3e50), or \"transparent\" for images with no background that drop onto any backdrop. Default is #ffffff. Do not mention background in the style or subject descriptions."
      • changedInput schema / properties / format / description
        Previous value: -"Output format: png, jpg, or webp. Defaults to png."New value: +"Output format: png, jpg, or webp. Defaults to png. jpg has no alpha channel, so a transparent set is png or webp."
      • changedOutput schema / properties / background / description
        Previous value: -"The background color used; absent for transparent sets."New value: +"The background color used, or transparent."
      • changedOutput schema / properties / images / description
        Previous value: -"The generated images: subject name, filename inside the zip, and pixel width and height."New value: +"The generated images: each one's file name inside the zip, its subject, and its pixel width and height."
      • addedOutput schema / properties / images / items / properties / description
        Added value: +{
        +  "description": "The subject, variation or scene this image was made from, as the call gave it.",
        +  "type": "string"
        +}
      • addedOutput schema / properties / images / items / properties / filename / description
        Added value: +"The image's file name inside the zip."
      • removedOutput schema / properties / images / items / properties / name
        Removed value: -{
        -  "type": "string"
        -}
      • changedOutput schema / properties / images / items / required
        Previous value: -[
        -  "name",
        -  "filename"
        -]New value: +[
        +  "filename",
        +  "description"
        +]
      • changedOutput schema / properties / suggestedStyle / description
        Previous value: -"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."New value: +"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 when the style was not checked (references only, or an extension). No generation ran and nothing was charged."
    • Removedgenerate_transparent_character_set
    • Removedgenerate_transparent_image_set
    • Changedget_generations12 fields changed
      • addedOutput schema / properties / generations / items / properties / crispBaseSize
        Added value: +{
        +  "description": "The largest base size, in pixels, at which export_set keeps every density of this batch crisp (no image enlarged past its source pixels) at its current levers; absent when no base size does. An image or character set's is set by its subject or variation count at generation, and edits to size, canvas, margin or sizing can move it; an illustration set's is a quarter of the longest side its scenes were drawn at, the largest it exports at.",
        +  "type": "integer"
        +}
      • changedOutput schema / properties / generations / items / properties / editable / description
        Previous value: -"True when it can be re-delivered: a set with edit_image_set, an illustration with edit_illustration (each has a source to cut from)."New value: +"True when edit_set can re-deliver it (it has a source to cut from)."
      • changedOutput schema / properties / generations / items / properties / edited / description
        Previous value: -"True when an edit (edit_image_set for a set, edit_illustration for an illustration) has changed its delivery from what was generated; a reset makes it false again."New value: +"True when edit_set has changed its delivery from what was generated; a reset makes it false again."
      • removedOutput schema / properties / generations / items / properties / iconCeiling
        Removed 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. Set by the subject count at generation; edits to size, canvas, margin or sizing can move it.",
        -  "type": "integer"
        -}
      • changedOutput schema / properties / generations / items / properties / id / description
        Previous value: -"The generation's id: the random segment of its download URLs, accepted by get_generations, delete_generations, edit_image_set, edit_illustration, export_icons and create_reference's sourceGeneration."New value: +"The generation's id: the random segment of its download URLs, accepted by get_generations, delete_generations, edit_set, export_set, extend_image_set, extend_character_set, extend_illustration_set and create_reference's sourceGeneration."
      • removedOutput schema / properties / generations / items / properties / illustrationLevers
        Removed value: -{
        -  "additionalProperties": false,
        -  "description": "The delivery settings now in force for an illustration (width, height, format, quality): the first delivery's until edit_illustration changes them.",
        -  "properties": {
        -    "format": {
        -      "type": "string"
        -    },
        -    "height": {
        -      "type": "integer"
        -    },
        -    "quality": {
        -      "type": "integer"
        -    },
        -    "width": {
        -      "type": "integer"
        -    }
        -  },
        -  "required": [
        -    "width",
        -    "height",
        -    "format"
        -  ],
        -  "type": [
        -    "null",
        -    "object"
        -  ]
        -}
      • changedOutput schema / properties / generations / items / properties / levers / description
        Previous value: -"The delivery levers now in force for a set (width, height, canvas, minimumMargin, sizing, format, quality, background): the first delivery's until edit_image_set changes them. Absent on illustrations and on sets from before editing existed."New value: +"The delivery levers now in force (width, height, canvas, minimumMargin, sizing, format, quality, background; an illustration set has width, height, format and quality): the first delivery's until edit_set changes them. Absent on sets from before editing existed."
      • changedOutput schema / properties / generations / items / properties / levers / properties / minimumMargin / type
        Previous value: -"integer"New value: +[
        +  "null",
        +  "integer"
        +]
      • changedOutput schema / properties / generations / items / properties / levers / required
        Previous value: -[
        -  "minimumMargin",
        -  "format"
        -]New value: +[
        +  "format"
        +]
      • changedOutput schema / properties / generations / items / properties / nativeWidth / description
        Previous value: -"The canvas this set would be delivered on at native size (its trimmed frame plus margin): the size any re-delivery compares against. For an illustration, the size the model made it at, the largest it can be delivered at."New value: +"The canvas this set would be delivered on at native size, with no width or height fixed: the size any re-delivery compares against. For an illustration set, the size the model draws its scenes at, the largest they can be delivered at."
      • changedOutput schema / properties / generations / items / properties / promptJSON / description
        Previous value: -"The batch's own prompt.json, verbatim - the same bytes that ship inside the zip. What it asked for (a set's style, subjects and references; an illustration's prompt and references) is the original call, and no edit can change it; its delivery settings (width, height, canvas, minimumMargin, format, quality, background) are the current delivery, which an edit rewrites (edit_image_set for a set, edit_illustration for an illustration's width, height, format and quality), so reusing this reproduces the generation 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; character sets carry character, variations and characterReferences in those places. Illustrations carry prompt, references as zip-relative paths when the call used them, 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. What it asked for (the style or character, the list and the references) is the original call, and no edit can change it; its delivery settings (width, height, canvas, minimumMargin, sizing, format, quality) are the current delivery, which edit_set rewrites, so reusing this reproduces the generation as it stands now rather than as first delivered. The edited flag says whether that has happened. Its background is the color the set was generated on, or transparent (an edit that composes a transparent set over a color leaves it transparent here; levers holds the color). Its shape follows the tool named in its own tool field. Image sets carry style, subjects as {description, filename} pairs, format, quality, minimumMargin, validation, width and height when an axis was fixed, background (a color, or transparent), and styleReferences as zip-relative paths when the call used them; character sets carry character, variations and characterReferences in those places; illustration sets carry style, styleReferences, scenes, width, height, format and quality. Read each entry's description (subjects[], variations[] or scenes[]) to reproduce a set: an entry given in object form has a description that differs from its filename, so search.webp may have been asked for as a magnifying glass."
      • changedOutput schema / properties / generations / items / properties / references / description
        Previous value: -"Where each reference image this generation was made with came from, in call order: the generation and delivered image it was copied from (what create_reference takes as sourceGeneration and sourceImage), or uploaded for a hand-uploaded file. The same images are inside promptJSON as zip-relative paths, under styleReferences, characterReferences or references, by tool. Absent when none were used."New value: +"Where each reference image this generation was made with came from, in call order: the generation and delivered image it was copied from (what create_reference takes as sourceGeneration and sourceImage), or uploaded for a hand-uploaded file. The same images are inside promptJSON as zip-relative paths, under styleReferences or characterReferences, by tool. Absent when none were used."
    • Changedlist_recent_generations7 fields changed
      • addedOutput schema / properties / generations / items / properties / crispBaseSize
        Added value: +{
        +  "description": "The largest base size, in pixels, at which export_set keeps every density of this batch crisp; absent when no base size does.",
        +  "type": "integer"
        +}
      • changedOutput schema / properties / generations / items / properties / editable / description
        Previous value: -"True when it can be re-delivered: a set with edit_image_set, an illustration with edit_illustration (each has a source to cut from)."New value: +"True when edit_set can re-deliver it (it has a source to cut from)."
      • changedOutput schema / properties / generations / items / properties / edited / description
        Previous value: -"True when an edit (edit_image_set for a set, edit_illustration for an illustration) has changed its delivery from what was generated."New value: +"True when edit_set has changed its delivery from what was generated."
      • removedOutput schema / properties / generations / items / properties / iconCeiling
        Removed value: -{
        -  "description": "The largest base size, in pixels, at which export_icons keeps every density of this set crisp; absent when no base size does.",
        -  "type": "integer"
        -}
      • changedOutput schema / properties / generations / items / properties / id / description
        Previous value: -"The generation's id: the random segment of its download URLs, accepted by get_generations, delete_generations, edit_image_set, edit_illustration, export_icons and create_reference's sourceGeneration."New value: +"The generation's id: the random segment of its download URLs, accepted by get_generations, delete_generations, edit_set, export_set, extend_image_set, extend_character_set, extend_illustration_set and create_reference's sourceGeneration."
      • removedOutput schema / properties / generations / items / properties / prompt
        Removed value: -{
        -  "description": "An illustration's prompt, as written; absent for sets.",
        -  "type": "string"
        -}
      • changedOutput schema / properties / generations / items / properties / style / description
        Previous value: -"The style a set was generated with, as written; absent for illustrations and for sets styled by reference images alone."New value: +"The style a set was generated with, as written; absent for character sets and for sets styled by reference images alone."
  8. 3 tool updates
    • Changedextend_character_set1 field changed
      • changedInput schema / properties / variations / description
        Previous value: -"What the character is doing in each image, one entry per image: either a list of descriptions or objects with description and filename (e.g. [{\"description\": \"the fox waving hello\", \"filename\": \"waving.png\"}]). Each entry is one isolated variation of the same character - its pose, action, expression, how strongly it feels it, and anything it holds or wears - not a scene or setting. Entries must be distinct: entries differing only in case, punctuation, or spacing are rejected as the same. Text can use only letters, numbers, dashes, spaces, and apostrophes, and must start and end with a letter or number."New value: +"What the character is doing in each image, one entry per image: either a list of descriptions or objects with description and filename (e.g. [{\"description\": \"waving hello\", \"filename\": \"waving.png\"}]). Each entry is one isolated variation of the same character - its pose, action, expression, how strongly it feels it, and anything it holds or wears - not a scene or setting. Entries must be distinct: entries differing only in case, punctuation, or spacing are rejected as the same. Text can use only letters, numbers, dashes, spaces, and apostrophes, and must start and end with a letter or number."
    • Changedgenerate_character_set1 field changed
      • changedInput schema / properties / variations / description
        Previous value: -"What the character is doing in each image, one entry per image: either a list of descriptions or objects with description and filename (e.g. [{\"description\": \"the fox waving hello\", \"filename\": \"waving.png\"}]). Each entry is one isolated variation of the same character - its pose, action, expression, how strongly it feels it, and anything it holds or wears - not a scene or setting. Entries must be distinct: entries differing only in case, punctuation, or spacing are rejected as the same. Text can use only letters, numbers, dashes, spaces, and apostrophes, and must start and end with a letter or number."New value: +"What the character is doing in each image, one entry per image: either a list of descriptions or objects with description and filename (e.g. [{\"description\": \"waving hello\", \"filename\": \"waving.png\"}]). Each entry is one isolated variation of the same character - its pose, action, expression, how strongly it feels it, and anything it holds or wears - not a scene or setting. Entries must be distinct: entries differing only in case, punctuation, or spacing are rejected as the same. Text can use only letters, numbers, dashes, spaces, and apostrophes, and must start and end with a letter or number."
    • Changedgenerate_transparent_character_set1 field changed
      • changedInput schema / properties / variations / description
        Previous value: -"What the character is doing in each image, one entry per image: either a list of descriptions or objects with description and filename (e.g. [{\"description\": \"the fox waving hello\", \"filename\": \"waving.png\"}]). Each entry is one isolated variation of the same character - its pose, action, expression, how strongly it feels it, and anything it holds or wears - not a scene or setting. Entries must be distinct: entries differing only in case, punctuation, or spacing are rejected as the same. Text can use only letters, numbers, dashes, spaces, and apostrophes, and must start and end with a letter or number."New value: +"What the character is doing in each image, one entry per image: either a list of descriptions or objects with description and filename (e.g. [{\"description\": \"waving hello\", \"filename\": \"waving.png\"}]). Each entry is one isolated variation of the same character - its pose, action, expression, how strongly it feels it, and anything it holds or wears - not a scene or setting. Entries must be distinct: entries differing only in case, punctuation, or spacing are rejected as the same. Text can use only letters, numbers, dashes, spaces, and apostrophes, and must start and end with a letter or number."
  9. 2 tool updates
    • Changedget_generations3 fields changed
      • changedOutput schema / properties / generations / items / properties / parents / description
        Previous value: -"Ids of the generations whose delivered images seeded this one's style references - the set lineage. Absent when this generation extended nothing."New value: +"Ids of the generations whose delivered images seeded this one's references - the set lineage. Absent when this generation extended nothing."
      • addedOutput schema / properties / generations / items / properties / references
        Added value: +{
        +  "description": "Where each reference image this generation was made with came from, in call order: the generation and delivered image it was copied from (what create_reference takes as sourceGeneration and sourceImage), or uploaded for a hand-uploaded file. The same images are inside promptJSON as zip-relative paths, under styleReferences, characterReferences or references, by tool. Absent when none 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"
        +  ]
        +}
      • removedOutput schema / properties / generations / items / properties / styleReferences
        Removed value: -{
        -  "description": "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.",
        -  "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"
        -  ]
        -}
    • Changedlist_recent_generations1 field changed
      • changedOutput schema / properties / generations / items / properties / parents / description
        Previous value: -"Ids of the generations whose delivered images seeded this one's style references: the set lineage, for gathering a whole set's ids."New value: +"Ids of the generations whose delivered images seeded this one's references: the set lineage, for gathering a whole set's ids."
  10. 4 tool updates
    • Addededit_illustration
    • Changedgenerate_illustration1 field changed
      • addedInput schema / properties / references
        Added value: +{
        +  "description": "Up to 3 reference images for the illustration: a style to match, or a character, product or place to include. 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. The prompt is used as written, so say in it what each image is for, in the order given (e.g. 'in the style of the first image, the dog from the second image asleep on a sofa'). How closely the result follows a reference is up to the model.",
        +  "items": {
        +    "type": "string"
        +  },
        +  "type": [
        +    "null",
        +    "array"
        +  ]
        +}
    • Changedget_generations7 fields changed
      • changedOutput schema / properties / generations / items / properties / deliveredAt / description
        Previous value: -"When the current delivery was cut: the generation time, or the time of the last edit_image_set."New value: +"When the current delivery was cut: the generation time, or the time of the last edit."
      • changedOutput schema / properties / generations / items / properties / editable / description
        Previous value: -"True when this set can be re-delivered with edit_image_set (it has a source to cut from)."New value: +"True when it can be re-delivered: a set with edit_image_set, an illustration with edit_illustration (each has a source to cut from)."
      • changedOutput schema / properties / generations / items / properties / edited / description
        Previous value: -"True when edit_image_set has changed this set's delivery from what was generated; a reset makes it false again."New value: +"True when an edit (edit_image_set for a set, edit_illustration for an illustration) has changed its delivery from what was generated; a reset makes it false again."
      • changedOutput schema / properties / generations / items / properties / id / description
        Previous value: -"The generation's id: the random segment of its download URLs, accepted by get_generations, delete_generations, edit_image_set, export_icons and create_reference's sourceGeneration."New value: +"The generation's id: the random segment of its download URLs, accepted by get_generations, delete_generations, edit_image_set, edit_illustration, export_icons and create_reference's sourceGeneration."
      • addedOutput schema / properties / generations / items / properties / illustrationLevers
        Added value: +{
        +  "additionalProperties": false,
        +  "description": "The delivery settings now in force for an illustration (width, height, format, quality): the first delivery's until edit_illustration changes them.",
        +  "properties": {
        +    "format": {
        +      "type": "string"
        +    },
        +    "height": {
        +      "type": "integer"
        +    },
        +    "quality": {
        +      "type": "integer"
        +    },
        +    "width": {
        +      "type": "integer"
        +    }
        +  },
        +  "required": [
        +    "width",
        +    "height",
        +    "format"
        +  ],
        +  "type": [
        +    "null",
        +    "object"
        +  ]
        +}
      • changedOutput schema / properties / generations / items / properties / nativeWidth / description
        Previous value: -"The canvas this set would be delivered on at native size (its trimmed frame plus margin): the size any re-delivery compares against."New value: +"The canvas this set would be delivered on at native size (its trimmed frame plus margin): the size any re-delivery compares against. For an illustration, the size the model made it at, the largest it can be delivered at."
      • changedOutput schema / properties / generations / items / properties / promptJSON / description
        Previous 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."New value: +"The batch's own prompt.json, verbatim - the same bytes that ship inside the zip. What it asked for (a set's style, subjects and references; an illustration's prompt and references) is the original call, and no edit can change it; its delivery settings (width, height, canvas, minimumMargin, format, quality, background) are the current delivery, which an edit rewrites (edit_image_set for a set, edit_illustration for an illustration's width, height, format and quality), so reusing this reproduces the generation 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; character sets carry character, variations and characterReferences in those places. Illustrations carry prompt, references as zip-relative paths when the call used them, 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."
    • Changedlist_recent_generations4 fields changed
      • changedOutput schema / properties / generations / items / properties / deliveredAt / description
        Previous value: -"When the current delivery was cut: the generation time, or the time of the last edit_image_set."New value: +"When the current delivery was cut: the generation time, or the time of the last edit."
      • changedOutput schema / properties / generations / items / properties / editable / description
        Previous value: -"True when this set can be re-delivered with edit_image_set (it has a source to cut from)."New value: +"True when it can be re-delivered: a set with edit_image_set, an illustration with edit_illustration (each has a source to cut from)."
      • changedOutput schema / properties / generations / items / properties / edited / description
        Previous value: -"True when edit_image_set has changed this set's delivery from what was generated."New value: +"True when an edit (edit_image_set for a set, edit_illustration for an illustration) has changed its delivery from what was generated."
      • changedOutput schema / properties / generations / items / properties / id / description
        Previous value: -"The generation's id: the random segment of its download URLs, accepted by get_generations, delete_generations, edit_image_set, export_icons and create_reference's sourceGeneration."New value: +"The generation's id: the random segment of its download URLs, accepted by get_generations, delete_generations, edit_image_set, edit_illustration, export_icons and create_reference's sourceGeneration."
  11. 7 tool updates
    • Addedextend_character_set
    • Addedextend_image_set
    • Addedgenerate_character_set
    • Changedgenerate_image_set3 fields changed
      • changedInput schema / properties / style / description
        Previous 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."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)."
      • changedInput schema / properties / styleReferences / description
        Previous value: -"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."New value: +"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). 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."
      • removedOutput schema / properties / style / description
        Removed value: -"The style the set was generated with."
    • Addedgenerate_transparent_character_set
    • Changedgenerate_transparent_image_set4 fields changed
      • changedInput schema / properties / style / description
        Previous 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."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)."
      • changedInput schema / properties / styleReferences / description
        Previous value: -"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."New value: +"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). 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."
      • changedInput schema / properties / width / description
        Previous value: -"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 (relative sizing scales nothing but a subject far larger than the rest, fill scales each subject to its frame). 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."New value: +"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 (relative sizing scales nothing but a subject far larger than the rest, fill scales each subject to its frame) - 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."
      • removedOutput schema / properties / style / description
        Removed value: -"The style the set was generated with."
    • Changedlist_recent_generations1 field changed
      • addedOutput schema / properties / generations / items / properties / character
        Added value: +{
        +  "description": "The character text a character set was generated with, as written; absent for other tools and for character sets made from references alone.",
        +  "type": "string"
        +}
  12. 4 tool updates
    • Changededit_image_set1 field changed
      • changedInput schema / properties / format / description
        Previous value: -"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."New value: +"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 in force (given in the same call or kept from an earlier edit)."
    • Changedgenerate_image_set1 field changed
      • changedInput schema / properties / width / description
        Previous value: -"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."New value: +"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 (relative sizing scales nothing but a subject far larger than the rest, fill scales each subject to its frame) - 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."
    • Changedgenerate_transparent_image_set1 field changed
      • changedInput schema / properties / width / description
        Previous value: -"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."New value: +"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 (relative sizing scales nothing but a subject far larger than the rest, fill scales each subject to its frame). 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."
    • Changedget_generations1 field changed
      • changedOutput schema / properties / generations / items / properties / iconCeiling / description
        Previous value: -"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."New value: +"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. Set by the subject count at generation; edits to size, canvas, margin or sizing can move it."
  13. 3 tool updates
    • Changededit_image_set2 fields changed
      • addedOutput schema / properties / images / items / properties / height
        Added value: +{
        +  "description": "The image's height in pixels.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / images / items / properties / width
        Added value: +{
        +  "description": "The image's width in pixels.",
        +  "type": "integer"
        +}
    • Changedgenerate_image_set3 fields changed
      • changedOutput schema / properties / images / description
        Previous value: -"The generated images: subject name and filename inside the zip."New value: +"The generated images: subject name, filename inside the zip, and pixel width and height."
      • addedOutput schema / properties / images / items / properties / height
        Added value: +{
        +  "description": "The image's height in pixels.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / images / items / properties / width
        Added value: +{
        +  "description": "The image's width in pixels.",
        +  "type": "integer"
        +}
    • Changedgenerate_transparent_image_set3 fields changed
      • changedOutput schema / properties / images / description
        Previous value: -"The generated images: subject name and filename inside the zip."New value: +"The generated images: subject name, filename inside the zip, and pixel width and height."
      • addedOutput schema / properties / images / items / properties / height
        Added value: +{
        +  "description": "The image's height in pixels.",
        +  "type": "integer"
        +}
      • addedOutput schema / properties / images / items / properties / width
        Added value: +{
        +  "description": "The image's width in pixels.",
        +  "type": "integer"
        +}
  14. 1 tool update
    • Addedbuy_credits
  15. 2 tool updates
    • Changedgenerate_image_set1 field changed
      • changedInput schema / properties / subjects / items
        Previous value: -trueNew value: +{
        +  "anyOf": [
        +    {
        +      "title": "Subject name",
        +      "type": "string"
        +    },
        +    {
        +      "properties": {
        +        "description": {
        +          "description": "The subject to draw.",
        +          "type": "string"
        +        },
        +        "filename": {
        +          "description": "Optional name for the delivered file (e.g. overview.webp); without it the name comes from the description.",
        +          "type": "string"
        +        }
        +      },
        +      "title": "Subject with filename",
        +      "type": "object"
        +    }
        +  ]
        +}
    • Changedgenerate_transparent_image_set1 field changed
      • changedInput schema / properties / subjects / items
        Previous value: -trueNew value: +{
        +  "anyOf": [
        +    {
        +      "title": "Subject name",
        +      "type": "string"
        +    },
        +    {
        +      "properties": {
        +        "description": {
        +          "description": "The subject to draw.",
        +          "type": "string"
        +        },
        +        "filename": {
        +          "description": "Optional name for the delivered file (e.g. overview.webp); without it the name comes from the description.",
        +          "type": "string"
        +        }
        +      },
        +      "title": "Subject with filename",
        +      "type": "object"
        +    }
        +  ]
        +}

Publisher details

Operator
Logospell
Operator website
https://logospell.com
Vendor relationship
First-party
Trust center
Not available
Restrictions
Requires an API key from a free Logospell account; generations beyond the free credits need a paid credit pack.

Related MCP Connectors

Related MCP Servers

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources