AI-agent image generation: cohesive sets & illustrations. Resize a set or export it as icons.
Scored across 13 tools
Each tool targets a distinct resource+action, and the three generation tools (illustration, image_set, transparent_image_set) are explicitly cross-referenced in descriptions to steer selection. List vs get tools for generations (list_recent_generations/get_generations) and the generation vs reference delete tools are clearly separated by target.
All 13 tools follow a consistent snake_case verb_noun pattern (buy_credits, create_reference, generate_image_set, delete_generations, list_references, etc.). The convention is uniform throughout with no mixing of styles.
13 tools is well within the ideal 3-15 range and each earns its place: credits management, reference lifecycle, three generation modes, editing, icon export, and listing/getting records. No redundant or filler tools.
Covers the full lifecycle: generate (3 modes), list/get/delete generations, edit delivery, export icons, and reference create/list/delete plus credit purchase/check. Minor gaps only—no single-reference get and no in-place reference update beyond re-uploading to the same URL.
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 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.
| Name | Required | Description | Default |
|---|---|---|---|
| packs | No | How many credit packs to buy, 1 to 10. Defaults to 1. |
| Name | Required | Description |
|---|---|---|
| packs | Yes | Credit packs in this purchase. |
| credits | Yes | Credits added to the API key once paid. |
| priceUSD | Yes | Total price in US dollars. |
| expiresAt | Yes | When the checkout link stops working (RFC 3339). |
| checkoutURL | Yes | Stripe Checkout link that completes the purchase. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, openWorldHint=true, non-idempotent, non-destructive), and the description adds substantial context beyond them: invoking it charges nothing, the link is pre-tied to the key's account so no sign-in is needed, payment completes in the browser, and credits land within seconds. This is exactly the extra context annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and the key reassurance ('Calling this charges nothing') before the operational steps. Slightly redundant at the tail, where 'Costs no credits' repeats the earlier 'charges nothing' statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return details needn't be explained, yet the description still notes the result carries credits and price. For a one-parameter, non-destructive action tool, nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'packs' parameter is fully documented in the schema, including the 1–10 range and default. The description restates the 1-to-10 packs constraint without adding format or behavioral detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Buy more credits for your API key') and immediately clarifies the artifact produced (a Stripe Checkout link). It is readily distinguishable from the sibling check_credits, which only inspects balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context: call this when more credits are needed, then 'call check_credits to confirm' after payment. It lacks explicit when-not-to-use guidance or a direct alternative, but the post-purchase confirmation step is spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| remaining | Yes | Credits remaining on the API key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/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.
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.
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.
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.
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.
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 an upload slot for a reference image. Returns an upload URL and a ref_ token: upload the image file with one shell command (curl -T ''), then pass the ref_ token to the reference-image parameter you are filling - every parameter that takes reference images names this tool in its description. This is the ONLY way to supply reference images, and those parameters accept ref_ tokens and nothing else. Image data never goes inside a tool call: a call is JSON, so an embedded image would have to be base64 text that you, the caller, must emit character by character - slow, error-prone, and enough to exhaust your context window. The upload moves the bytes out-of-band instead: a plain HTTP PUT of the raw file, so any HTTP client works; if your environment has no way to send one, install curl. And when the image you want is from one of your OWN recent Logospell generations, skip the upload entirely: pass sourceGeneration and sourceImage and the server copies it directly - the shortcut for extending an existing set in its own style. Accepts PNG, JPEG, or WebP, each at most 500KB, each side between 64px and 768px - resize before uploading if needed; larger reference images do not improve results. A reference is private to your API key and can be used in any number of later calls; it expires 7 days after its last use or re-upload (each use restarts the window), so uploading a few references once can serve a whole session of work. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| sourceImage | No | 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. | |
| sourceGeneration | No | Optional, with sourceImage: fill this reference from one of your own recent generations instead of uploading a file. Pass the generation id - the random segment of its download URL (.../download/<id>/images.zip), also returned by list_recent_generations. The image is copied server-side; nothing is uploaded. |
| Name | Required | Description |
|---|---|---|
| ref | Yes | Token to pass to a tool's reference-image parameter. |
| expiresAt | Yes | When the reference expires if left unused, RFC3339. |
| uploadURL | Yes | URL to PUT or POST the image file to. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the safety profile (not read-only, not idempotent, not destructive, closed-world), and the description adds far more: out-of-band upload mechanics, accepted formats (PNG/JPEG/WebP), size/dimension limits (500KB, 64-768px), API-key privacy, the 7-day sliding expiry, the same-URL replacement behavior, and zero credit cost. This is unusually rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core contract (create slot, upload, pass token) is front-loaded, and sentences are information-dense. It is somewhat verbose, with persuasive asides about curl and context-window exhaustion that justify rather than instruct, slightly diluting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a separate output schema, the description still explains the meaningful return (upload URL and ref_ token) and covers limits, expiry, privacy, update semantics, and cost. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both sourceImage and sourceGeneration are already fully documented in the schema, and the description adds little beyond echoing that they enable a server-side copy. Baseline 3 is appropriate when the schema carries the parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a precise verb and resource ("Create an upload slot for a reference image") and immediately names the artifacts returned (upload URL and ref_ token). It is unmistakably distinct from siblings like delete_references, list_references, and the generation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states this is the ONLY way to supply reference images, describes the two-step workflow (upload then pass ref_ token), and names the alternative path (sourceGeneration/sourceImage to skip the upload). When-to-use, when-not, and the alternative are all covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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_image_set and export_icons 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 as icons. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| generations | Yes | The 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. |
| Name | Required | Description |
|---|---|---|
| deleted | Yes | The ids that were deleted. |
| notFound | No | Ids that were not found for this API key or whose download window had closed; nothing was deleted for them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint and idempotentHint, yet the description adds substantial context beyond them: exactly what is destroyed (download URL, images, prompt.json, source kept for edit_image_set/export_icons), no credit refund, no undo, the API-key ownership constraint, partial-failure semantics, and zero cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense and front-loaded with the destructive consequences, and every sentence carries distinct information. It runs long as a single block of clauses, which slightly hurts scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers destruction scope, irreversibility, auth requirement, batch limits, partial-failure behavior, and cost. With an output schema present, return-value detail is unnecessary, so nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the baseline is 3, but the description adds real meaning: the batch limit ('Up to 50 ids per call'), the many-ids-per-set pattern, and the fact that not-found ids are reported without failing the call. The id-format explanation largely duplicates the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Starts with a specific verb+resource+permanence qualifier ('Permanently delete one or more of your generations') and immediately scopes the timing ('before their download window closes'). Clearly distinguishable from delete_references and the generate_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the trigger condition ('Call it only when the user asks to delete generations'), names the automatic-deletion alternative that happens without it, and points to list_recent_generations and get_generations for obtaining ids.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| refs | Yes | The ref_ tokens of the references to delete, as create_reference or list_references returned them. |
| Name | Required | Description |
|---|---|---|
| deleted | Yes | The ref_ tokens that were deleted. |
| notFound | No | Tokens that were not found for this API key or had already expired; nothing was deleted for them. |
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.
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.
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.
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.
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.
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.
Change how an existing image set is delivered, without generating again: its width and height (both, one, or neither, exactly as on the set tools), its canvas when no size is fixed (one canvas for the whole set, or each image wrapped around its own subject), its minimum margin, its sizing (relative or fill), its format and quality, and for a transparent set the background color it is composed over. The set is delivered again from its full-resolution source and its download is replaced in place: the same download URL now serves the new delivery, and get_generations reports the new levers. Free; no credits are spent. Style, subjects and references are generation and cannot be edited - a different picture is a new set.
A lever left out keeps its current value, so one call can change one thing. Any earlier state, the original delivery included, is one edit away: nothing is kept as history because the same levers always produce the same bytes. Editing never extends a set's download window.
jpg has no alpha: asking for jpg on a transparent set composes the images over white unless the same call gives a background color; jpg together with background "transparent" is rejected. background applies to transparent sets only. Not available for illustrations, or for sets generated before this tool existed (they have no source).
| Name | Required | Description | Default |
|---|---|---|---|
| reset | No | true restores every lever to the first delivery's (the set as it was generated), read from the set's own record; any other lever given in the same call is applied on top of that. | |
| width | No | New delivered width in pixels, or 0 to stop fixing the width. Left out, the current width stays. Width and height combine exactly as on the set tools: both fixed is an exact box, one fixed lets the other hug each subject, neither is native size. | |
| canvas | No | With NEITHER width nor height fixed, what the images land on: uniform (the default) puts the whole set on one canvas, the size it was generated at, every image alike; subject wraps each image around its own subject, so the images differ in size the way the subjects do. Says nothing when a size is fixed. Left out, the current value stays. | |
| format | No | New format: png, webp, or jpg. Left out, the current format stays. jpg has no alpha: on a transparent set it composes the images over white unless a background color is given in the same call. | |
| height | No | New delivered height in pixels, or 0 to stop fixing the height. Left out, the current height stays. | |
| sizing | No | New sizing: relative keeps the sizes the model gave the subjects in relation to one another (one scale for the set); fill scales each subject on its own to fill the frame less the margin, so every image reads at the same visual weight, at the cost of relative size and of enlarging subjects smaller than the frame (the result reports by how much). Left out, the current sizing stays. | |
| quality | No | New quality (1-100) for webp and jpg; ignored for png. Left out, the current quality stays. | |
| background | No | Transparent sets only: a #RRGGBB color composes every image over it and delivers an opaque set; "transparent" restores the alpha. Left out, the current background stays. Rejected on a solid-background set, whose color is in its pixels and cannot change. | |
| generation | Yes | The id of the set to edit - the random segment of its download URL, as list_recent_generations returns it. One batch of a set per call; a set that grew over several calls is edited batch by batch. | |
| minimumMargin | No | New minimum margin in pixels around each subject, with the set tools' bounds. Left out, the current margin stays. |
| Name | Required | Description |
|---|---|---|
| width | No | |
| height | No | |
| images | No | |
| levers | No | The delivery levers now in force: width, height, canvas, minimumMargin, sizing, format, quality, background. |
| zipURL | No | The set's download, unchanged, now serving the new delivery. |
| expiresAt | No | |
| generation | No | |
| deliveredAt | No | |
| iconCeiling | No | The largest base size, in pixels, at which export_icons keeps every density of this set crisp at these levers; absent when no base size does. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly/destructive/idempotent hints; the description adds substantially more: free (no credits), the download is replaced in place at the same URL, no history is retained, the download window is not extended, and specific error cases (jpg on a transparent set, jpg with 'transparent' rejected). This is consistent with the annotations and far exceeds what they convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the core 'levers, not regeneration' framing are front-loaded, and each paragraph carries distinct information (mechanics, economics, format constraints). It is dense but largely non-redundant, with only minor repetition of the jpg-alpha rule between the body and the format parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter mutation with an output schema present, the description covers everything an agent needs: what can and cannot be edited, the cost model, default/omission behavior, in-place replacement, and availability limits. Return-value explanation is correctly delegated to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the per-parameter descriptions are already exhaustive, so the baseline is 3. The description still adds value by grouping the levers semantically, stating the 'left out keeps current value' and reset-on-top rules, cross-referencing the set tools for size semantics, and giving the jpg+background rejection rule that the schema does not state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific verb and resource (change how an existing image set is delivered) and immediately scopes it against regenerating ('without generating again'), which cleanly separates it from generate_image_set and generate_transparent_image_set. The full list of editable levers makes the operation concrete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for use ('one call can change one thing', 'a different picture is a new set') and explicit when-not conditions (not for illustrations, not for sets predating the tool). It never names a sibling tool directly, so the routing to generate_image_set is implied rather than stated, keeping it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export an existing image set as icons, free: every subject at the base size you name and at every density the web, iOS, Android and Flutter need, laid out as each expects (web files with @2x and @3x and an srcset line, an iOS asset catalog with one imageset per icon, Android res/ density buckets, Flutter asset folders with the pubspec lines), plus a viewer and a ledger. One export per call: one batch of a set (a set that grew over several calls is exported batch by batch; the trees merge by folder) at one base size (a second size is a second call; names carry the size, so two sizes never collide). The icons come from the set's full-resolution source, so an icon is the set as it is currently delivered, scaled: its size, canvas, sizing and margin all carry (edit_image_set changes them), while no pixel comes from a delivered image. Files up to 3x the 1x size (4x on Android) are always delivered; where a density would enlarge a subject past its source pixels the ledger says so per tree ("soft": some blur) and by how much, never withholding a file. Large base sizes cost real megabytes for files the ledger will mark soft; 48 to 128 is the usual range. How large a set's icons can be was fixed when it was generated, by its subject count: every generation result and list_recent_generations state the batch's crisp base size, and the ledger says where a larger size went past the source. Not available for illustrations, or for sets generated before editing existed (they have no source).
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | png, webp, or jpg. Left out, the set's current format. iOS asset catalogs take no WebP, so a webp export's iOS tree is PNG at the same pixels (the ledger says so). jpg has no alpha: rejected for a transparent set unless the set is currently composed over a color. | |
| quality | No | 1 to 100 for webp and jpg; ignored for png. Left out, the set's current quality (90 when it has none). | |
| iconSize | Yes | The base size: one even number from 16 to 256 that each platform reads in its own unit (CSS px on the web, pt on iOS, dp on Android). It sizes the batch, not each file: every icon is the set's delivered image scaled so the batch's longest side is this number, so nothing exceeds it, a set delivered on one canvas gives icons that all match it, and a set whose images wrap their own subjects gives icons that differ the same way. The export holds files up to 3x it (4x on Android). | |
| generation | Yes | The id of the set to export - the random segment of its download URL, as list_recent_generations returns it. One batch per call. |
| Name | Required | Description |
|---|---|---|
| format | No | |
| ledger | No | The export's account of itself: per tree (web, ios, android, flutter) the densities, format, largest file and fidelity (crisp, or soft, meaning some blur, with the largest enlargement past source pixels), and every file with its tree, subject, density and pixel size. Also inside the zip as ledger.json. |
| zipURL | No | The export zip; fetch and extract it as your first action after the call, the link expires with the set. |
| quality | No | |
| iconSize | No | |
| expiresAt | No | |
| generation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-destructive, idempotent, closed-world behavior, but the description adds substantial operational detail: free, batch-per-call, source-based scaling, no delivered pixels, guaranteed density files, ledger softness, and cost implications. It discloses what is written and when output may be soft, going well beyond annotation hints without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first sentence, and most clauses convey unique constraints about platform outputs and export behavior. However, it is a single dense paragraph with some redundancy, so it is not maximally tight for a 4-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description need not explain return values. It covers the key usage and behavioral context: source basis, limitations, cost, softness, and platform deliverables. The definition is complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds practical parameter guidance not in the schema, such as the usual 48–128 base-size range, one-batch/one-size-per-call constraints, and how names carry size to avoid collisions; it adds little for format or quality beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: export an existing image set as icons, with clear platform scope (web, iOS, Android, Flutter). It also distinguishes itself from mutation siblings like edit_image_set by focusing on exporting from existing source rather than creating or modifying a set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: one export per call, one batch and one base size per call, and explicit exclusions for illustrations and pre-editing sets. It names list_recent_generations and edit_image_set for supporting tasks, but does not name a sibling alternative to use instead for the export operation itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a single composed illustration from a prompt - a scene, environment, hero image, banner, character portrait, or any standalone picture. (For a SET of separate isolated subjects sharing one style - icons, sprites, asset packs - use generate_image_set for solid-color backgrounds, or generate_transparent_image_set for transparent backgrounds, instead.) Returns a zip download URL: the image plus a prompt.json recording what you asked for, plus an index.html viewer. Each call costs 1 credit. Run generation calls sequentially, never in parallel - only one generation runs at a time per API key.
The prompt describes the picture and is used as written (no template, no appended instructions); do not put the pixel size in it - put the size in the width and height arguments. width and height must be one of the supported pixel pairs below; any other pair is rejected. These are the maximums offered - nothing larger is available. Each line is one shape: the first pair is that shape's largest size, the rest are exact proportional downscales of it.
Prompt craft, since each call costs a credit: name the light and the time of day (cold blue twilight, one warm lamp from the left), because lighting carries the mood of a single picture; fix the camera (wide establishing shot, three-quarter portrait, viewed from the doorway) so the composition commits to one vantage point; ask for open space on a named side when text will be laid over the picture later; and say no text or lettering unless a word on a sign is the point, since lettering inside a picture is unreliable and titles are better added afterwards.
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
Formats: png (default, lossless), jpg, webp. quality (1-100) applies to jpg and webp; default 90. Prompt max length: 2500 characters. A prompt that does not describe a picture is rejected. unpackTo: a directory on your local filesystem to extract the downloaded zip into. filename: name for the image file inside the zip (default illustration.).
If a "Rate limit exceeded" error is returned, wait the suggested number of seconds before retrying. Do not retry immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | Output width in pixels. Must form one of the supported (width, height) pairs listed in the tool description. | |
| format | No | Output format: png (default, lossless), jpg, or webp. | |
| height | Yes | Output height in pixels, paired with width per the supported list in the tool description. | |
| prompt | Yes | What the illustration should depict - a scene, environment, hero image, banner, character, or any single composed picture. Used as written; a prompt that does not describe a picture is rejected. Do not put the pixel size here; use width and height. | |
| quality | No | Image quality for jpg/webp (1-100). Defaults to 90. | |
| filename | No | Name for the image file inside the zip. Defaults to illustration.<ext>. | |
| unpackTo | No | Path on the caller's local filesystem where the generated illustration should be saved. The server does NOT write here. After this call returns, you (the calling client) must download illustration.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL expires (the result states when). |
| Name | Required | Description |
|---|---|---|
| width | No | Delivered width in pixels. |
| format | No | The delivered image format. |
| height | No | Delivered height in pixels. |
| zipURL | No | Download URL for the zip containing the illustration. Time-limited; expiresAt states the deadline. |
| unpackTo | No | The caller-supplied local extraction path, echoed back. |
| expiresAt | No | When the download URL expires. |
| remaining | No | Credits remaining after this call. |
| manifestURL | No | |
| imageFilename | No | The illustration's filename inside the zip. |
| rejectedPrompt | No | Present only when the request was rejected because the prompt does not appear to describe a picture: the submitted prompt. No generation ran and nothing was charged; revise the prompt and resubmit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations (readOnly=false, destructive=false, openWorld=true, idempotent=false) covering the safety profile, the description adds rich behavioral context: each call costs 1 credit, generation runs sequentially and never in parallel, the return is a zip containing image + prompt.json + index.html, supported dimension pairs are max sizes with exact downscales, prompt length limit, rejection of non-picture prompts, quality defaults, prompt used as written with no template, and rate-limit handling with an explicit do-not-retry-immediately warning. This goes far beyond what the annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is front-loaded with the core purpose and sibling routing, then behavior, then the dimension table, then prompt craft and format details. It is somewhat long and could be slightly tighter, but every section serves a purpose for a generation tool with multiple supported formats and a large dimension matrix. The instruction to run sequentially is well placed near the top. Uses a short second sentence to explain the set-based alternative's reason. Structure is logical and scannable, though the inline dimension list is verbose and could be formatted as a table.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, multiple output formats, dimension constraints, credit cost, download workflow), the description is complete: it covers prompt usage, dimension constraints, formats, quality defaults, filename, the client-side download responsibility, rate limits, and output contents. Nothing essential for correct invocation is missing. The output schema exists; the description supplements rather than duplicates it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well documented, but the description adds value beyond the schema: it explains width/height must be one of the supported pixel pairs (with the full pair list inline), provides prompt-craft guidance absent from the schema, clarifies filename default and unpackTo download responsibility, and notes prompt max length. These additions meaningfully compensate for any ambiguity in the schema's reference to 'the supported list in the tool description'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states a specific verb (generate) and resource (single composed illustration), distinguishing it from generate_image_set and generate_transparent_image_set by naming the when-to-use condition (set of separate isolated subjects). An agent can choose this tool versus its siblings 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.
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 alternatives, naming two sibling tools and the exact condition that selects them (solid-color backgrounds vs transparent backgrounds). It also provides sequential-execution and rate-limit retry guidance, covering both correct and incorrect usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a cohesive SET of custom images on a SOLID-COLOR background, each one a separate isolated subject sharing one background and one visual style (icons, logos, game assets, UI elements, sprite/asset packs). The style parameter says how everything is drawn; the subjects parameter says what to draw. The style can also come from reference images via the styleReferences parameter - alone, or best combined with the style text (text plus references holds a style tightest), so an existing set can be extended in its original style across many calls. Returns a zip download URL. Each call costs 1 credit. Run generation calls sequentially, never in parallel - only one generation runs at a time per API key.
For TRANSPARENT-background output, use generate_transparent_image_set instead (1 credit per call).
For a SINGLE composed picture or a full-bleed scene (hero image, banner, character portrait, environment), use generate_illustration instead.
Output formats: PNG (lossless), JPEG, or WebP. Images can be delivered at a fixed width and height, at one fixed axis with the other hugging each subject, or at their native resolution.
Size and quality considerations: Leaving width and height unset delivers images at their native resolution with zero scaling, which produces the highest quality results and is recommended when images will be post-processed, composited, or resized downstream. Native output dimensions vary between generations and track the subject count - roughly 650-950px per side for small sets, down to roughly 400-650 at the full 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).
Image descriptions should describe WHAT to depict, not where to position it.
Each image is ONE isolated subject, not a scene. Describe the subject with its pose or action and anything it directly holds, rides, or interacts with, but not the surrounding setting, environment, landscape, or sky. For a single composed scene (a figure set within an environment), use generate_illustration instead.
Do not use size words (large, tiny, small, etc.) on the overall image subject (e.g. 'a large elephant', 'a tiny mouse') - all images are produced at the same size. Size words on details within the image are fine (e.g. 'a plate with a small insignia').
Maximum 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. Image description max length: 200 characters each.
Size: width and height are separate parameters, each 256 to 512 pixels when given. Both given is an exact box; one given fixes that axis and the other hugs each subject (so images in the set differ on it, and it may fall below 256); neither given delivers native resolution, which is also the path to larger images.
Sizing: relative (the default) keeps the sizes the model gave the subjects in relation to one another, one scale for the whole set; fill scales each subject on its own to fill its frame less the margin, the icon-set convention, giving up relative size and enlarging subjects smaller than the frame (the result says by how much). Both can be changed later with edit_image_set.
Icons: the subject count sets how large a batch's icons can later be exported with export_icons, crisp at every density: about a 136px base size with 13 to 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".
If a "Rate limit exceeded" error is returned, wait the suggested number of seconds before retrying. Do not retry immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | Visual style for all images, e.g. flat minimalist, hand-drawn sketch, 3D glossy, pixel art. Text that does not describe a visual style is rejected. Provide this, styleReferences, or both - together they hold a style most tightly (the text pins the style, the references show it applied), which is the recommended way to extend an existing set across multiple calls. | |
| width | No | Delivered width in pixels. Give both width and height for an exact box (every image lands on it, one uniform scale, the shorter axis padded); give only one and the other axis hugs each subject at that scale plus the margin (so images in the set differ on it); give neither and images arrive at their native size with no scaling or distortion - the highest detail, though dimensions then vary between generations. The per-axis range is given in the tool description; a given axis outside it is rejected, and the hugging axis is whatever each subject needs. A fixed size guarantees consistent dimensions across images and generations but applies Lanczos resampling which may soften fine detail; if the user will post-process the images, recommend leaving both unset. | |
| format | No | Output format: png, jpg, or webp. Defaults to png. | |
| height | No | Delivered height in pixels; see width for how the two combine (both: an exact box; one: the other axis hugs each subject; neither: native size). | |
| sizing | No | How subjects are scaled. relative (the default) keeps the sizes the model gave them in relation to one another: one scale for the whole set, so a small subject stays small in its frame. fill scales each subject on its own to fill the frame less the margin, touching it on one axis, so every image reads at the same visual weight (icon-set convention); that gives up relative size and enlarges any subject smaller than the frame, which the result reports when it happens. | |
| quality | No | Image quality for jpg/webp (1-100). Defaults to 90. | |
| subjects | Yes | Either a list of subject names (e.g. ["home", "search"]) or objects with description and filename (e.g. [{"description": "compass rose", "filename": "overview.webp"}]). Each subject must name a drawable subject and be distinct: entries differing only in case, punctuation, or spacing are rejected as the same subject. A subject with no Latin letters or numbers (a name written entirely in another script) needs the object form with a filename, since delivered files are named in ASCII. Subject text can use only letters, numbers, dashes, spaces, and apostrophes, and must start and end with a letter or number. | |
| unpackTo | No | Path on the caller's local filesystem where the generated files should be saved. The server does NOT write here. After this call returns, you (the calling client) must download images.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL expires (the result states when). | |
| background | No | Background as a 6-char hex color #RRGGBB (e.g. #ffffff, #2c3e50). Default is #ffffff. For transparent output, call the generate_transparent_image_set tool instead - this tool only produces solid-color backgrounds. Do not mention background in the style or subject descriptions. | |
| validation | No | How to handle the automatic style/subject check before generating. One of: suggest (the default) - if the style and descriptions need cleanup for a consistent set, the cleaned version is returned as a suggestion for you to review before any image is generated; skip - skip the cleanup suggestions and generate exactly as given (the non-drawable-content and repeated-subject rejection rules above still apply; no mode skips them), set this when resubmitting a prompt you already revised from a previous suggestion (so your approved wording is used as-is and not re-checked, which avoids further suggestions) or when you are confident the prompt is already clean; auto-apply - if cleanup is needed, apply it and generate in one step without returning a suggestion. Omit for the default. | |
| minimumMargin | No | Minimum margin in pixels around each subject. Defaults to 20. At most 15% of the smallest given axis when width or height is given, at most 80 when neither is; negative values are rejected. With relative sizing the actual margin varies by subject and never falls below this (only the set's largest subject sits exactly on it); with fill sizing every subject touches it on one axis. | |
| styleReferences | No | Up to 3 reference images that define the style, alone or alongside the style parameter (with both, the text pins the style and the references show it applied - the tightest hold, recommended when extending an existing set). Each entry is a ref_ token from the create_reference tool: create an upload slot, send the image file with the curl command it returns, then pass the token here. Image data itself never goes in a tool call; ref_ tokens are the only accepted form. Uploads take PNG, JPEG, or WebP; size and dimension limits are given in the create_reference tool's description, and oversized images are rejected with a clear message - larger reference images do not improve results. The images are used as style guides only: their rendering technique carries over, their subjects do not appear in the output. Provide at least one of style and styleReferences. |
| Name | Required | Description |
|---|---|---|
| style | No | The style the set was generated with. |
| format | No | The delivered image format. |
| images | No | The generated images: subject name and filename inside the zip. |
| zipURL | No | Download URL for the zip of generated images. Time-limited; expiresAt states the deadline. |
| unpackTo | No | The caller-supplied local extraction path, echoed back. |
| expiresAt | No | When the download URL expires. |
| remaining | No | Credits remaining after this call. |
| background | No | The background color used; absent for transparent sets. |
| manifestURL | No | |
| rejectedStyle | No | Present only when the request was rejected because the style does not appear to describe a visual style: the submitted style text. No generation ran and nothing was charged; revise the style (or drop it and use styleReferences) and resubmit. |
| suggestedStyle | No | Present only on a validation suggestion: the cleaned style text, for review. An empty string means the cleanup removed the style entirely (nothing in it was usable as a style) - replace it, or use styleReferences. Absent on refs-only requests. No generation ran and nothing was charged. |
| rejectedSubjects | No | Present only when the request was rejected because some subjects do not appear to name distinct, drawable subjects: the exact rejected entries. No generation ran and nothing was charged; revise or remove these subjects and resubmit. |
| suggestedSubjects | No | Present only on a validation suggestion: the cleaned subject list, one entry per image. Adopt these, or resubmit your own wording with validation set to skip. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic safety profile (not read-only, not destructive, open-world, not idempotent). The description goes well beyond that with credit cost per call, a rate-limit error and backoff instruction, the zip-download return contract with URL expiry, the mandatory download-then-extract sequence for unpackTo, and the full validation mode flow (suggest/skip/auto-apply).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the sibling routing are correctly front-loaded in the first two paragraphs, but the body is very long and repeats itself — the no-background-in-style rule appears three times, 'do not put the image count in the style' twice, and the frame/border prohibition both as a bullet and in the connection rule. Each rule is individually useful, yet the sheer volume makes triage harder than it needs to be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter, credit-costing, open-world generation tool with an output schema present, the description covers everything an agent needs: credit cost, sequencing, validation workflow, download/expiry handling, subject/style authoring constraints, and per-parameter interactions. Return-value details are 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.
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 genuine meaning beyond the schema: the icon base-size table tying subject count to export_icons crispness, the relative-vs-fill sizing trade-off, and the 'text plus references holds a style tightest' guidance. Much of the size/quality material does restate what the width/height/format parameters already document, keeping it just short of a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource — 'Generate a cohesive SET of custom images on a SOLID-COLOR background, each one a separate isolated subject' — which pins down both the operation and the output shape. It then explicitly differentiates from generate_transparent_image_set (transparent backgrounds) and generate_illustration (single composed scenes), so an agent can route correctly without opening sibling schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names the alternatives and the exact conditions that select them: transparent backgrounds go to generate_transparent_image_set, single composed scenes go to generate_illustration, and later size changes go to edit_image_set. It also states operational sequencing ('Run generation calls sequentially, never in parallel'), which is usage guidance an agent would otherwise get wrong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a cohesive SET of custom images with TRANSPARENT backgrounds, each one a separate isolated subject sharing one visual style (icons, logos, sprites, UI assets that need to drop onto any backdrop). The style parameter says how everything is drawn; the subjects parameter says what to draw. The style can also come from reference images via the styleReferences parameter - alone, or best combined with the style text (text plus references holds a style tightest), so an existing set can be extended in its original style across many calls. Returns a zip download URL. Each call costs 1 credit. When a solid colored background fits the user's use case, generate_image_set (1 credit per call) is the faster choice. Run generation calls sequentially, never in parallel - only one generation runs at a time per API key.
Output formats: PNG (lossless) or WebP. JPG is not supported because it has no alpha channel.
Size and quality considerations match generate_image_set: leaving width and height unset delivers native resolution (best quality, varies between generations); fixing them resamples to that box, and fixing one axis lets the other hug each subject.
IMPORTANT - style and subject description rules for best results: The style applies to every image in the set, so it is what keeps them visually consistent. Put HOW the images are drawn (technique, palette, surface treatment) in the style, and make each subject description only about WHAT that one subject is, not how it looks. A quick test for any phrase: is it WHAT the subject is, or HOW it is drawn? HOW belongs in the style, shared across the set.
Get the style and the subject descriptions right with the user before you call. When their request puts how an image is drawn, a background, or a scene into a subject description (or names the subjects to draw in the style rather than as separate entries in the subjects list), fix it as you compose the call: routine moves of shared technique into the style you can just make, but when a change drops or alters something they explicitly asked for, tell them what you are adjusting and why first. Each call costs a credit, so it is worth getting this right up front rather than spending one on a framed or scene-filled result.
The style describes the visual treatment of the images (e.g. 'watercolor', 'pixel art', 'stained glass'). It must NOT mention background color, image count, layout, or sizing.
Do not list the subjects to draw in the style (e.g. 'illustrations of a fox, an owl, and a deer'); the style is only the shared visual treatment, and the subjects belong in the subjects list, one per entry. A category or theme word is fine (e.g. 'insect illustration').
Do not put background color or background descriptions in the style or subject descriptions.
Avoid framing the style as a type of painted canvas ('oil painting', 'acrylic painting', 'gouache painting', 'pastel painting'). These tend to produce each image as a rectangular framed canvas with its own colored background, rather than an isolated subject. Prefer 'illustration' or a specific technique: 'watercolor illustration', 'pen-and-ink sketch', 'ink wash', 'relief-etching', 'pastel drawing', 'woodblock print'.
Avoid color-field or atmospheric phrasings in the style ('luminous backgrounds of violet, rose, and gold', 'set against jewel-tone fields', 'dreamlike rainbow atmosphere'). These instruct the image model to fill each image with colored atmosphere, producing framed compositions rather than isolated subjects. Describe only the linework, palette, and technique of the subjects themselves.
Do not describe an aged, weathered, cracked, or textured surface, ground, wall, panel, or paper that the whole artwork sits on ('on aged wood', 'cracked fresco wall', 'aged parchment surface'); name the art tradition(s) or style(s) instead ('fresco-style illustration'). Texture that belongs to a subject's own material is fine ('a weathered bronze shield', 'a cracked ceramic vase').
No captions, labels, or annotations. Text that is part of the depicted object is fine (e.g. 'STOP' on a stop sign, 'EXIT' on an exit sign).
No grid lines, borders, frames, or separators.
No overlapping or collage-style arrangements.
Do not connect the subjects to each other or give them shared physical elements: no wires, cords, chains, ropes, ribbons, vines, or threads running between subjects, no frame or banner they share, no phrasing like 'connected by' or 'strung together', and no single continuous line or tube forming multiple subjects. Each subject must be drawable in complete isolation; connections inside one subject (a chain on an amulet, laces on a boot) are fine.
No dramatic/long drop shadows (subtle shadows are fine).
Image descriptions should describe WHAT to depict, not where to position it.
Each image is ONE isolated subject, not a scene. Describe the subject with its pose or action and anything it directly holds, rides, or interacts with, but not the surrounding setting, environment, landscape, or sky. For a single composed scene (a figure set within an environment), use generate_illustration instead.
Do not use size words (large, tiny, small, etc.) on the overall image subject (e.g. 'a large elephant', 'a tiny mouse') - all images are produced at the same size. Size words on details within the image are fine (e.g. 'a plate with a small insignia').
Maximum 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. Image description max length: 200 characters each.
Size: width and height are separate parameters, each 256 to 512 pixels when given. Both given is an exact box; one given fixes that axis and the other hugs each subject (so images in the set differ on it, and it may fall below 256); neither given delivers native resolution, which is also the path to larger images.
Sizing: relative (the default) keeps the sizes the model gave the subjects in relation to one another, one scale for the whole set; fill scales each subject on its own to fill its frame less the margin, the icon-set convention, giving up relative size and enlarging subjects smaller than the frame (the result says by how much). Both can be changed later with edit_image_set.
Icons: the subject count sets how large a batch's icons can later be exported with export_icons, crisp at every density: about a 136px base size with 13 to 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".
If a "Rate limit exceeded" error is returned, wait the suggested number of seconds before retrying. Do not retry immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | Visual style for all images, e.g. flat minimalist, hand-drawn sketch, 3D glossy, pixel art. Text that does not describe a visual style is rejected. Provide this, styleReferences, or both - together they hold a style most tightly (the text pins the style, the references show it applied), which is the recommended way to extend an existing set across multiple calls. | |
| width | No | Delivered width in pixels. Give both width and height for an exact box (every image lands on it, one uniform scale, the shorter axis padded); give only one and the other axis hugs each subject at that scale plus the margin (so images in the set differ on it); give neither and images arrive at their native size with no scaling or distortion. The per-axis range is given in the tool description; a given axis outside it is rejected, and the hugging axis is whatever each subject needs. | |
| format | No | Output format: png or webp (jpg has no alpha channel and is rejected). Defaults to png. | |
| height | No | Delivered height in pixels; see width for how the two combine (both: an exact box; one: the other axis hugs each subject; neither: native size). | |
| sizing | No | How subjects are scaled. relative (the default) keeps the sizes the model gave them in relation to one another: one scale for the whole set, so a small subject stays small in its frame. fill scales each subject on its own to fill the frame less the margin, touching it on one axis, so every image reads at the same visual weight (icon-set convention); that gives up relative size and enlarges any subject smaller than the frame, which the result reports when it happens. | |
| quality | No | Image quality for webp (1-100). Defaults to 90. | |
| subjects | Yes | Either a list of subject names (e.g. ["home", "search"]) or objects with description and filename (e.g. [{"description": "compass rose", "filename": "overview.webp"}]). Each subject must name a drawable subject and be distinct: entries differing only in case, punctuation, or spacing are rejected as the same subject. A subject with no Latin letters or numbers (a name written entirely in another script) needs the object form with a filename, since delivered files are named in ASCII. Subject text can use only letters, numbers, dashes, spaces, and apostrophes, and must start and end with a letter or number. | |
| unpackTo | No | Path on the caller's local filesystem where the generated files should be saved. The server does NOT write here. After this call returns, you (the calling client) must download images.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL expires (the result states when). | |
| validation | No | How to handle the automatic style/subject check before generating. One of: suggest (the default) - if the style and descriptions need cleanup for a consistent set, the cleaned version is returned as a suggestion for you to review before any image is generated; skip - skip the cleanup suggestions and generate exactly as given (the non-drawable-content and repeated-subject rejection rules above still apply; no mode skips them), set this when resubmitting a prompt you already revised from a previous suggestion (so your approved wording is used as-is and not re-checked, which avoids further suggestions) or when you are confident the prompt is already clean; auto-apply - if cleanup is needed, apply it and generate in one step without returning a suggestion. Omit for the default. | |
| minimumMargin | No | Minimum margin in pixels around each subject. Defaults to 20. At most 15% of the smallest given axis when width or height is given, at most 80 when neither is; negative values are rejected. With relative sizing the actual margin varies by subject and never falls below this (only the set's largest subject sits exactly on it); with fill sizing every subject touches it on one axis. | |
| styleReferences | No | Up to 3 reference images that define the style, alone or alongside the style parameter (with both, the text pins the style and the references show it applied - the tightest hold, recommended when extending an existing set). Each entry is a ref_ token from the create_reference tool: create an upload slot, send the image file with the curl command it returns, then pass the token here. Image data itself never goes in a tool call; ref_ tokens are the only accepted form. Uploads take PNG, JPEG, or WebP; size and dimension limits are given in the create_reference tool's description, and oversized images are rejected with a clear message - larger reference images do not improve results. The images are used as style guides only: their rendering technique carries over, their subjects do not appear in the output. Provide at least one of style and styleReferences. |
| Name | Required | Description |
|---|---|---|
| style | No | The style the set was generated with. |
| format | No | The delivered image format. |
| images | No | The generated images: subject name and filename inside the zip. |
| zipURL | No | Download URL for the zip of generated images. Time-limited; expiresAt states the deadline. |
| unpackTo | No | The caller-supplied local extraction path, echoed back. |
| expiresAt | No | When the download URL expires. |
| remaining | No | Credits remaining after this call. |
| background | No | The background color used; absent for transparent sets. |
| manifestURL | No | |
| rejectedStyle | No | Present only when the request was rejected because the style does not appear to describe a visual style: the submitted style text. No generation ran and nothing was charged; revise the style (or drop it and use styleReferences) and resubmit. |
| suggestedStyle | No | Present only on a validation suggestion: the cleaned style text, for review. An empty string means the cleanup removed the style entirely (nothing in it was usable as a style) - replace it, or use styleReferences. Absent on refs-only requests. No generation ran and nothing was charged. |
| rejectedSubjects | No | Present only when the request was rejected because some subjects do not appear to name distinct, drawable subjects: the exact rejected entries. No generation ran and nothing was charged; revise or remove these subjects and resubmit. |
| suggestedSubjects | No | Present only on a validation suggestion: the cleaned subject list, one entry per image. Adopt these, or resubmit your own wording with validation set to skip. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the operation profile (write, open-world, non-idempotent, non-destructive), so the description carries the real burden and delivers: 1-credit-per-call cost, the zip download URL return, sequential-only execution, validation mode semantics (suggest/skip/auto-apply) and how to resubmit an approved prompt, and reference-token-only image input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose, alternatives, and cost are front-loaded, and the dense rule list is justified by the large number of failure modes for a style-consistency tool. It loses a point for length and for restating schema content (e.g. the sizing/width-height mechanics appear in both the prose and the parameter descriptions).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter generation tool with an output schema (so return shape need not be described), the description still covers the non-obvious operational context an agent needs: credit cost, sequential execution, validation workflow, reference token flow, and unpackTo requiring a client-side download. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds hard rules the schema omits: style max 500 chars and image descriptions max 200, max 16 subjects, distinctness/rejection rules, the ASCII filename requirement for non-Latin subjects, and the icon base-size-vs-subject-count table. These materially reduce invocation errors beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb (Generate), resource (a SET of custom images), and the defining trait (transparent backgrounds, each an isolated subject sharing one visual style). It also names the concrete artifact types (icons, logos, sprites, UI assets) and distinguishes itself from generate_image_set (solid backgrounds, faster).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing rules are given: use generate_image_set when a solid background fits, and generate_illustration for a single composed scene within an environment. It also states operational sequencing (run generation calls sequentially, never in parallel; one generation per API key) and retry behavior on rate-limit errors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full record of generations of yours by id: each one's download URL and expiry, promptJSON (the original call, with its style and subjects, so the generation can be extended or reproduced), its current delivery settings, its style-reference sources and its set lineage. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| generations | Yes | The ids of the generations to get: the random segment of each one's download URL. |
| Name | Required | Description |
|---|---|---|
| notFound | No | Ids that were not found for this API key or whose download window has closed. |
| generations | Yes | The generations found, in the order asked for, each with its full record. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish a safe read (readOnly, idempotent, non-destructive), and the description adds meaningful information beyond them: up to 50 ids per call, missing ids are reported without failing while an all-missing batch does fail, and the call costs no credits. These are the operational details an agent needs before batching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then response payload, then id sourcing, then failure semantics, then limits and cost. Every clause carries a distinct fact and none is redundant with the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a rich output schema, the description still covers the things structured data does not: batch size limit, partial-failure behavior, and zero credit cost. 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter's meaning (random segment of the download URL) is already documented and the baseline is 3. The description adds genuine semantics on top: the ids' provenance and the 50-id ceiling per call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ("Get the full record of generations... by id") and enumerates exactly what the record contains: download URL and expiry, promptJSON, delivery settings, style-reference sources, set lineage. This is distinguishable from sibling list_recent_generations, which by contrast only surfaces ids.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States explicitly where the ids come from ("list_recent_generations or from a generation's download URL"), which routes the agent to the correct upstream call. It does not, however, give explicit when-not-to-use guidance versus e.g. list_recent_generations or delete_generations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your recent successful generations and return their download URLs again. Use this to recover a generation whose result message was lost (for example a dropped connection mid-call): generations are billed when they complete, and their downloads stay available until their original expiry even if the response never arrived; re-listing does not extend the expiry. Generations made on the logospell.com generate page appear here too. Returns 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 (sets) or prompt (illustrations), its image count, whether it can be edited, and its set lineage. For a generation's full record (the original call as promptJSON, its style-reference sources and its current delivery settings), for example to extend or reproduce a set, pass its id to get_generations. Costs no credits.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum 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. | |
| offset | No | How 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. |
| Name | Required | Description |
|---|---|---|
| total | Yes | How many unexpired generations this key has in all. More than offset plus the rows returned means there are more to page through with offset. |
| generations | Yes | Recent successful generations, newest first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely non-inferable behavior: generations are billed on completion, downloads persist until the original expiry even if the response never arrived, re-listing does NOT extend expiry, and the call costs no credits. That is exactly the context the annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and the recovery use case; every sentence carries information. Slightly dense with nested parentheticals and repeats the expiry/download-URL point across sentences, which costs a little economy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing, the description covers the things an agent actually needs to decide and act: cost, expiry semantics, billing timing, paging, and the handoff to get_generations. Nothing material is missing for a read-only listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the baseline is 3, but the description adds paging semantics (newest first, one page at a time, total reflects the full count) and a cross-reference to get_generations for id-based retrieval, which goes beyond the raw schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List your recent successful generations') plus the distinctive behavior of re-returning download URLs, which separates it from get_generations (full record by id) and the delete_* siblings. An agent can route correctly 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('recover a generation whose result message was lost, e.g. a dropped connection mid-call') and names the alternative for the full-record case ('pass its id to get_generations'). Also flags that logospell.com page generations appear here, which is a non-obvious inclusion rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| total | Yes | How many references are live on this API key. |
| references | Yes | Your live references, most recently used or uploaded first. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
buy_creditsgenerate_image_set1 field changedInput schema / properties / subjects / itemsPrevious 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"
+ }
+ ]
+}generate_transparent_image_set1 field changedInput schema / properties / subjects / itemsPrevious 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"
+ }
+ ]
+}create_reference4 fields changedInput schema / properties / sourceImage / descriptionPrevious value: -"Optional, with sourceGeneration: the delivered image filename to use as the reference, exactly as listed by list_recent_generations or the generation's manifest (e.g. \"a_lotus_cradling_a_glowing_pearl.png\"). An image larger than the reference limits is downscaled to fit automatically."New 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."Output schema / properties / expiresAt / descriptionAdded value: +"When the reference expires if left unused, RFC3339."Output schema / properties / ref / descriptionAdded value: +"Token to pass to a tool's reference-image parameter."Output schema / properties / uploadURL / descriptionAdded value: +"URL to PUT or POST the image file to."delete_generationdelete_generationsdelete_referencedelete_referencesedit_image_set2 fields changedOutput schema / properties / levers / descriptionAdded value: +"The delivery levers now in force: width, height, canvas, minimumMargin, sizing, format, quality, background."Output schema / properties / zipURL / descriptionAdded value: +"The set's download, unchanged, now serving the new delivery."export_icons2 fields changedOutput schema / properties / ledger / descriptionAdded value: +"The export's account of itself: per tree (web, ios, android, flutter) the densities, format, largest file and fidelity (crisp, or soft, meaning some blur, with the largest enlargement past source pixels), and every file with its tree, subject, density and pixel size. Also inside the zip as ledger.json."Output schema / properties / ledger / properties / sizing / descriptionPrevious value: -"The set's sizing the export followed: relative or fit."New value: +"The set's sizing the export followed: relative or fill."generate_illustration8 fields changedOutput schema / properties / expiresAt / descriptionAdded value: +"When the download URL expires."Output schema / properties / format / descriptionAdded value: +"The delivered image format."Output schema / properties / height / descriptionAdded value: +"Delivered height in pixels."Output schema / properties / imageFilename / descriptionAdded value: +"The illustration's filename inside the zip."Output schema / properties / remaining / descriptionAdded value: +"Credits remaining after this call."Output schema / properties / unpackTo / descriptionAdded value: +"The caller-supplied local extraction path, echoed back."Output schema / properties / width / descriptionAdded value: +"Delivered width in pixels."Output schema / properties / zipURL / descriptionAdded value: +"Download URL for the zip containing the illustration. Time-limited; expiresAt states the deadline."generate_image_set8 fields changedOutput schema / properties / background / descriptionAdded value: +"The background color used; absent for transparent sets."Output schema / properties / expiresAt / descriptionAdded value: +"When the download URL expires."Output schema / properties / format / descriptionAdded value: +"The delivered image format."Output schema / properties / images / descriptionAdded value: +"The generated images: subject name and filename inside the zip."Output schema / properties / remaining / descriptionAdded value: +"Credits remaining after this call."Output schema / properties / style / descriptionAdded value: +"The style the set was generated with."Output schema / properties / unpackTo / descriptionAdded value: +"The caller-supplied local extraction path, echoed back."Output schema / properties / zipURL / descriptionAdded value: +"Download URL for the zip of generated images. Time-limited; expiresAt states the deadline."generate_transparent_image_set8 fields changedOutput schema / properties / background / descriptionAdded value: +"The background color used; absent for transparent sets."Output schema / properties / expiresAt / descriptionAdded value: +"When the download URL expires."Output schema / properties / format / descriptionAdded value: +"The delivered image format."Output schema / properties / images / descriptionAdded value: +"The generated images: subject name and filename inside the zip."Output schema / properties / remaining / descriptionAdded value: +"Credits remaining after this call."Output schema / properties / style / descriptionAdded value: +"The style the set was generated with."Output schema / properties / unpackTo / descriptionAdded value: +"The caller-supplied local extraction path, echoed back."Output schema / properties / zipURL / descriptionAdded value: +"Download URL for the zip of generated images. Time-limited; expiresAt states the deadline."get_generationslist_recent_generations18 fields changedInput schema / properties / limit / descriptionPrevious value: -"Maximum number of recent generations to return (default 5). There is no ceiling: pass a large number to list everything, and read total in the output to know whether anything was left out."New value: +"Maximum 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."Input schema / properties / offsetAdded value: +{
+ "description": "How 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.",
+ "type": "integer"
+}Output schema / properties / generations / descriptionAdded value: +"Recent successful generations, newest first."Output schema / properties / generations / items / properties / edited / descriptionPrevious 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 edit_image_set has changed this set's delivery from what was generated."Output schema / properties / generations / items / properties / iconCeiling / descriptionPrevious 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; absent when no base size does."Output schema / properties / generations / items / properties / id / descriptionPrevious value: -"The generation's id - the random segment of its download URLs, accepted by 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, export_icons and create_reference's sourceGeneration."Output schema / properties / generations / items / properties / imagesAdded value: +{
+ "description": "How many images it delivered.",
+ "type": "integer"
+}Output schema / properties / generations / items / properties / leversRemoved value: -{
- "additionalProperties": false,
- "description": "The delivery levers now in force for a set (width, height, minimumMargin, format, quality, background): the first delivery's until edit_image_set changes them. Absent on illustrations and on sets from before editing existed.",
- "properties": {
- "background": {
- "type": "string"
- },
- "canvas": {
- "type": "string"
- },
- "format": {
- "type": "string"
- },
- "height": {
- "type": "integer"
- },
- "minimumMargin": {
- "type": "integer"
- },
- "quality": {
- "type": "integer"
- },
- "sizing": {
- "type": "string"
- },
- "width": {
- "type": "integer"
- }
- },
- "required": [
- "minimumMargin",
- "format"
- ],
- "type": [
- "null",
- "object"
- ]
-}Output schema / properties / generations / items / properties / nativeHeightRemoved value: -{
- "type": "integer"
-}Output schema / properties / generations / items / properties / nativeWidthRemoved value: -{
- "description": "The canvas this set would be delivered on at native size (its trimmed frame plus margin): the size any re-delivery compares against.",
- "type": "integer"
-}Output schema / properties / generations / items / properties / parents / descriptionPrevious 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 style references: the set lineage, for gathering a whole set's ids."Output schema / properties / generations / items / properties / promptAdded value: +{
+ "description": "An illustration's prompt, as written; absent for sets.",
+ "type": "string"
+}Output schema / properties / generations / items / properties / promptJSONRemoved value: -{
- "description": "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."
-}Output schema / properties / generations / items / properties / styleAdded value: +{
+ "description": "The style a set was generated with, as written; absent for illustrations and for sets styled by reference images alone.",
+ "type": "string"
+}Output schema / properties / generations / items / properties / styleReferencesRemoved 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"
- ]
-}Output schema / properties / generations / items / properties / toolAdded value: +{
+ "description": "The tool that made it.",
+ "type": "string"
+}Output schema / properties / generations / items / requiredPrevious value: -[
- "id",
- "created",
- "expiresAt",
- "zipURL",
- "promptJSON"
-]New value: +[
+ "id",
+ "tool",
+ "created",
+ "expiresAt",
+ "zipURL",
+ "images"
+]Output schema / properties / total / descriptionPrevious value: -"How many unexpired generations this key has in all. Greater than the number of rows returned means the listing was cut short by limit; ask again with a larger limit."New value: +"How many unexpired generations this key has in all. More than offset plus the rows returned means there are more to page through with offset."list_referencesdelete_generationdelete_referenceexport_icons1 field changedOutput schema / properties / zipURL / descriptionPrevious value: -"The export zip; fetch and extract it as your first action after the call, the link is short-lived (it expires with the set)."New value: +"The export zip; fetch and extract it as your first action after the call, the link expires with the set."generate_illustration1 field changedInput schema / properties / unpackTo / descriptionPrevious value: -"Path on the caller's local filesystem where the generated illustration should be saved. The server does NOT write here. After this call returns, you (the calling client) must download illustration.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL is short-lived."New value: +"Path on the caller's local filesystem where the generated illustration should be saved. The server does NOT write here. After this call returns, you (the calling client) must download illustration.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL expires (the result states when)."generate_image_set1 field changedInput schema / properties / unpackTo / descriptionPrevious value: -"Path on the caller's local filesystem where the generated files should be saved. The server does NOT write here. After this call returns, you (the calling client) must download images.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL is short-lived."New value: +"Path on the caller's local filesystem where the generated files should be saved. The server does NOT write here. After this call returns, you (the calling client) must download images.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL expires (the result states when)."generate_transparent_image_set1 field changedInput schema / properties / unpackTo / descriptionPrevious value: -"Path on the caller's local filesystem where the generated files should be saved. The server does NOT write here. After this call returns, you (the calling client) must download images.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL is short-lived."New value: +"Path on the caller's local filesystem where the generated files should be saved. The server does NOT write here. After this call returns, you (the calling client) must download images.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL expires (the result states when)."list_recent_generations1 field changedOutput schema / properties / generations / items / properties / promptJSON / descriptionPrevious value: -"The original call, verbatim, exactly as the batch's own prompt.json records it - the same bytes that ship inside the zip. Its shape follows the tool named in its own tool field. Sets carry style, subjects as {description, filename} pairs, format, quality, minimumMargin, validation, width and height when an axis was fixed, background for solid-background sets, and styleReferences as zip-relative paths when the call used them. Illustrations carry prompt, width, height, format, quality and filename. Read subjects[].description to reproduce a set: a subject given in object form has a description that differs from its filename, so search.webp may have been asked for as a magnifying glass."New value: +"The batch's own prompt.json, verbatim - the same bytes that ship inside the zip. Its style, subjects and styleReferences are the original call and no edit can change them; its delivery levers (width, height, canvas, minimumMargin, format, quality, background) are the batch's current delivery, which edit_image_set rewrites, so reusing this reproduces the set as it stands now rather than as first delivered. The edited flag says whether that has happened. Its shape follows the tool named in its own tool field. Sets carry style, subjects as {description, filename} pairs, format, quality, minimumMargin, validation, width and height when an axis was fixed, background for solid-background sets, and styleReferences as zip-relative paths when the call used them. Illustrations carry prompt, width, height, format, quality and filename. Read subjects[].description to reproduce a set: a subject given in object form has a description that differs from its filename, so search.webp may have been asked for as a magnifying glass."edit_image_setexport_iconsgenerate_image_set5 fields changedInput schema / properties / heightAdded value: +{
+ "description": "Delivered height in pixels; see width for how the two combine (both: an exact box; one: the other axis hugs each subject; neither: native size).",
+ "type": "integer"
+}Input schema / properties / minimumMargin / descriptionPrevious value: -"Minimum margin in pixels around each subject. Defaults to 20. At most 15% of the smallest requested dimension when a size is given, at most 80 without one; negative values are rejected. All images in a set share one set of dimensions; the actual margin varies by subject and never falls below this."New value: +"Minimum margin in pixels around each subject. Defaults to 20. At most 15% of the smallest given axis when width or height is given, at most 80 when neither is; negative values are rejected. With relative sizing the actual margin varies by subject and never falls below this (only the set's largest subject sits exactly on it); with fill sizing every subject touches it on one axis."Input schema / properties / sizeRemoved value: -{
- "description": "Image dimensions (e.g. 512 for square, 256x512 for non-square). Per-axis minimum and maximum are given in the tool description; values outside the range are rejected. If omitted, images are delivered at their native size with no scaling or distortion - this preserves maximum detail but output dimensions vary between generations. Specifying a size guarantees consistent dimensions across all images and generations but applies Lanczos resampling which may soften fine details. If the user plans to post-process the images, recommend omitting size to get the highest quality results.",
- "type": "string"
-}Input schema / properties / sizingAdded value: +{
+ "description": "How subjects are scaled. relative (the default) keeps the sizes the model gave them in relation to one another: one scale for the whole set, so a small subject stays small in its frame. fill scales each subject on its own to fill the frame less the margin, touching it on one axis, so every image reads at the same visual weight (icon-set convention); that gives up relative size and enlarges any subject smaller than the frame, which the result reports when it happens.",
+ "type": "string"
+}Input schema / properties / widthAdded value: +{
+ "description": "Delivered width in pixels. Give both width and height for an exact box (every image lands on it, one uniform scale, the shorter axis padded); give only one and the other axis hugs each subject at that scale plus the margin (so images in the set differ on it); give neither and images arrive at their native size with no scaling or distortion - the highest detail, though dimensions then vary between generations. The per-axis range is given in the tool description; a given axis outside it is rejected, and the hugging axis is whatever each subject needs. A fixed size guarantees consistent dimensions across images and generations but applies Lanczos resampling which may soften fine detail; if the user will post-process the images, recommend leaving both unset.",
+ "type": "integer"
+}generate_transparent_image_set5 fields changedInput schema / properties / heightAdded value: +{
+ "description": "Delivered height in pixels; see width for how the two combine (both: an exact box; one: the other axis hugs each subject; neither: native size).",
+ "type": "integer"
+}Input schema / properties / minimumMargin / descriptionPrevious value: -"Minimum margin in pixels around each subject. Defaults to 20. At most 15% of the smallest requested dimension when a size is given, at most 80 without one; negative values are rejected. All images in a set share one set of dimensions; the actual margin varies by subject and never falls below this."New value: +"Minimum margin in pixels around each subject. Defaults to 20. At most 15% of the smallest given axis when width or height is given, at most 80 when neither is; negative values are rejected. With relative sizing the actual margin varies by subject and never falls below this (only the set's largest subject sits exactly on it); with fill sizing every subject touches it on one axis."Input schema / properties / sizeRemoved value: -{
- "description": "Image dimensions (e.g. 512 for square, 256x512 for non-square). Per-axis minimum and maximum are given in the tool description; values outside the range are rejected. If omitted, images are delivered at their native size with no scaling or distortion.",
- "type": "string"
-}Input schema / properties / sizingAdded value: +{
+ "description": "How subjects are scaled. relative (the default) keeps the sizes the model gave them in relation to one another: one scale for the whole set, so a small subject stays small in its frame. fill scales each subject on its own to fill the frame less the margin, touching it on one axis, so every image reads at the same visual weight (icon-set convention); that gives up relative size and enlarges any subject smaller than the frame, which the result reports when it happens.",
+ "type": "string"
+}Input schema / properties / widthAdded value: +{
+ "description": "Delivered width in pixels. Give both width and height for an exact box (every image lands on it, one uniform scale, the shorter axis padded); give only one and the other axis hugs each subject at that scale plus the margin (so images in the set differ on it); give neither and images arrive at their native size with no scaling or distortion. The per-axis range is given in the tool description; a given axis outside it is rejected, and the hugging axis is whatever each subject needs.",
+ "type": "integer"
+}list_recent_generations8 fields changedOutput schema / properties / generations / items / properties / deliveredAtAdded value: +{
+ "description": "When the current delivery was cut: the generation time, or the time of the last edit_image_set.",
+ "type": "string"
+}Output schema / properties / generations / items / properties / editableAdded value: +{
+ "description": "True when this set can be re-delivered with edit_image_set (it has a source to cut from).",
+ "type": "boolean"
+}Output schema / properties / generations / items / properties / editedAdded value: +{
+ "description": "True when edit_image_set has changed this set's delivery from what was generated; a reset makes it false again.",
+ "type": "boolean"
+}Output schema / properties / generations / items / properties / iconCeilingAdded value: +{
+ "description": "The largest base size, in pixels, at which export_icons keeps every density of this set crisp (no subject enlarged past its source pixels) at its current levers; absent when no base size does. Fixed by the subject count at generation; edits to margin or sizing move it.",
+ "type": "integer"
+}Output schema / properties / generations / items / properties / leversAdded value: +{
+ "additionalProperties": false,
+ "description": "The delivery levers now in force for a set (width, height, minimumMargin, format, quality, background): the first delivery's until edit_image_set changes them. Absent on illustrations and on sets from before editing existed.",
+ "properties": {
+ "background": {
+ "type": "string"
+ },
+ "canvas": {
+ "type": "string"
+ },
+ "format": {
+ "type": "string"
+ },
+ "height": {
+ "type": "integer"
+ },
+ "minimumMargin": {
+ "type": "integer"
+ },
+ "quality": {
+ "type": "integer"
+ },
+ "sizing": {
+ "type": "string"
+ },
+ "width": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "minimumMargin",
+ "format"
+ ],
+ "type": [
+ "null",
+ "object"
+ ]
+}Output schema / properties / generations / items / properties / nativeHeightAdded value: +{
+ "type": "integer"
+}Output schema / properties / generations / items / properties / nativeWidthAdded value: +{
+ "description": "The canvas this set would be delivered on at native size (its trimmed frame plus margin): the size any re-delivery compares against.",
+ "type": "integer"
+}Output schema / properties / generations / items / properties / promptJSON / descriptionPrevious value: -"The original call, verbatim, exactly as the batch's own prompt.json records it - the same bytes that ship inside the zip. Its shape follows the tool named in its own tool field. Sets carry style, subjects as {description, filename} pairs, format, quality, minimumMargin, validation, size when one was requested, background for solid-background sets, and styleReferences as zip-relative paths when the call used them. Illustrations carry prompt, width, height, format, quality and filename. Read subjects[].description to reproduce a set: a subject given in object form has a description that differs from its filename, so search.webp may have been asked for as a magnifying glass."New value: +"The original call, verbatim, exactly as the batch's own prompt.json records it - the same bytes that ship inside the zip. Its shape follows the tool named in its own tool field. Sets carry style, subjects as {description, filename} pairs, format, quality, minimumMargin, validation, width and height when an axis was fixed, background for solid-background sets, and styleReferences as zip-relative paths when the call used them. Illustrations carry prompt, width, height, format, quality and filename. Read subjects[].description to reproduce a set: a subject given in object form has a description that differs from its filename, so search.webp may have been asked for as a magnifying glass."list_recent_generations7 fields changedOutput schema / properties / generations / items / properties / imagesRemoved value: -{
- "type": "integer"
-}Output schema / properties / generations / items / properties / namesRemoved value: -{
- "items": {
- "type": "string"
- },
- "type": [
- "null",
- "array"
- ]
-}Output schema / properties / generations / items / properties / promptJSONAdded value: +{
+ "description": "The original call, verbatim, exactly as the batch's own prompt.json records it - the same bytes that ship inside the zip. Its shape follows the tool named in its own tool field. Sets carry style, subjects as {description, filename} pairs, format, quality, minimumMargin, validation, size when one was requested, background for solid-background sets, and styleReferences as zip-relative paths when the call used them. Illustrations carry prompt, width, height, format, quality and filename. Read subjects[].description to reproduce a set: a subject given in object form has a description that differs from its filename, so search.webp may have been asked for as a magnifying glass."
+}Output schema / properties / generations / items / properties / styleRemoved value: -{
- "type": "string"
-}Output schema / properties / generations / items / properties / styleReferences / descriptionPrevious value: -"The style references this generation was made with, in call order, each identified by the delivered image it came from when known. Absent when no references were used."New value: +"The style references this generation was made with, in call order, each identified by the delivered image it came from when known, and reusable via create_reference. Distinct from promptJSON.styleReferences, which records the same references as zip-relative paths inside the original call. Absent when no references were used."Output schema / properties / generations / items / properties / toolRemoved value: -{
- "type": "string"
-}Output schema / properties / generations / items / requiredPrevious value: -[
- "id",
- "tool",
- "created",
- "expiresAt",
- "images",
- "zipURL"
-]New value: +[
+ "id",
+ "created",
+ "expiresAt",
+ "zipURL",
+ "promptJSON"
+]list_recent_generations3 fields changedInput schema / properties / limit / descriptionPrevious value: -"Maximum number of recent generations to return (default 5, max 20)."New value: +"Maximum number of recent generations to return (default 5). There is no ceiling: pass a large number to list everything, and read total in the output to know whether anything was left out."Output schema / properties / totalAdded value: +{
+ "description": "How many unexpired generations this key has in all. Greater than the number of rows returned means the listing was cut short by limit; ask again with a larger limit.",
+ "type": "integer"
+}Output schema / requiredPrevious value: -[
- "generations"
-]New value: +[
+ "generations",
+ "total"
+]list_recent_generations4 fields changedOutput schema / properties / generations / items / properties / idAdded value: +{
+ "description": "The generation's id - the random segment of its download URLs, accepted by create_reference's sourceGeneration.",
+ "type": "string"
+}Output schema / properties / generations / items / properties / parentsAdded value: +{
+ "description": "Ids of the generations whose delivered images seeded this one's style references - the set lineage. Absent when this generation extended nothing.",
+ "items": {
+ "type": "string"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}Output schema / properties / generations / items / properties / styleReferencesAdded value: +{
+ "description": "The style references this generation was made with, in call order, each identified by the delivered image it came from when known. Absent when no references were used.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "from": {
+ "description": "The generation id this reference image came from; accepted by create_reference's sourceGeneration.",
+ "type": "string"
+ },
+ "image": {
+ "description": "The delivered image filename inside that generation; accepted by create_reference's sourceImage.",
+ "type": "string"
+ },
+ "uploaded": {
+ "description": "True for a hand-uploaded reference that came from no generation.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}Output schema / properties / generations / items / requiredPrevious value: -[
- "tool",
- "created",
- "expiresAt",
- "images",
- "zipURL"
-]New value: +[
+ "id",
+ "tool",
+ "created",
+ "expiresAt",
+ "images",
+ "zipURL"
+]generate_image_set1 field changedInput schema / properties / subjects / descriptionPrevious value: -"Either a list of subject names (e.g. [\"home\", \"search\"]) or objects with description and filename (e.g. [{\"description\": \"compass rose\", \"filename\": \"overview.webp\"}]). Each subject must name a drawable subject and be distinct: entries differing only in case, punctuation, or spacing are rejected as the same subject. A subject with no Latin letters or numbers (a name written entirely in another script) needs the object form with a filename, since delivered files are named in ASCII."New value: +"Either a list of subject names (e.g. [\"home\", \"search\"]) or objects with description and filename (e.g. [{\"description\": \"compass rose\", \"filename\": \"overview.webp\"}]). Each subject must name a drawable subject and be distinct: entries differing only in case, punctuation, or spacing are rejected as the same subject. A subject with no Latin letters or numbers (a name written entirely in another script) needs the object form with a filename, since delivered files are named in ASCII. Subject text can use only letters, numbers, dashes, spaces, and apostrophes, and must start and end with a letter or number."generate_transparent_image_set1 field changedInput schema / properties / subjects / descriptionPrevious value: -"Either a list of subject names (e.g. [\"home\", \"search\"]) or objects with description and filename (e.g. [{\"description\": \"compass rose\", \"filename\": \"overview.webp\"}]). Each subject must name a drawable subject and be distinct: entries differing only in case, punctuation, or spacing are rejected as the same subject. A subject with no Latin letters or numbers (a name written entirely in another script) needs the object form with a filename, since delivered files are named in ASCII."New value: +"Either a list of subject names (e.g. [\"home\", \"search\"]) or objects with description and filename (e.g. [{\"description\": \"compass rose\", \"filename\": \"overview.webp\"}]). Each subject must name a drawable subject and be distinct: entries differing only in case, punctuation, or spacing are rejected as the same subject. A subject with no Latin letters or numbers (a name written entirely in another script) needs the object form with a filename, since delivered files are named in ASCII. Subject text can use only letters, numbers, dashes, spaces, and apostrophes, and must start and end with a letter or number."AI game assets for agents: consistent sprites, 2D animations, tiles, maps, music and engine exports.
Image processing for AI agents: resize, convert, compress, crop, and web-ready AI-generated images.
Agent-Native design tool - create and edit visual designs with agent assistance
Generate and edit images, video, voice, lip-sync and 3D models from your AI agent.
Add one secure layer between your agents and this server.