Skip to main content
Glama

extend_illustration_set

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

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

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

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

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

Input Schema

NameRequiredDescriptionDefault
widthNoOptional width in pixels, together with height: one of the supported pixel pairs generate_illustration_set lists. Left out, the named batch's current size.
heightNoOptional height in pixels, together with width. Left out, the named batch's current size.
scenesYesWhat each illustration shows, one entry per illustration: either a list of scene descriptions or objects with description and filename (e.g. [{"description": "a harbor market at dawn", "filename": "hero.webp"}]). A scene is prose and may name a setting, a moment, the light and the camera. Entries must describe distinct illustrations; without a filename, the file is named from the start of its scene.
unpackToNoPath on the caller's local filesystem where the generated files should be saved. The server does NOT write here. After this call returns, you (the calling client) must download images.zip from the returned zip URL, extract it to this path yourself, then report the path to the user. Make the download your immediate next action when the result arrives, before any commentary; the download URL expires (the result states when).
generationYesThe id of any batch in the set to extend: the random segment of its download URL (.../download/<id>/images.zip), also returned by list_recent_generations. The new batch is drawn exactly as that set: the same style text and style references, and the named batch's format and quality.

Output Schema

NameRequiredDescriptionDefault
styleNo
formatNoThe delivered image format.
imagesNoThe illustrations: each one's file name inside the zip, its scene, and its pixel width and height.
zipURLNoDownload URL for the zip of illustrations. Time-limited; expiresAt states the deadline.
unpackToNoThe caller-supplied local extraction path, echoed back.
expiresAtNoWhen the download URL expires.
remainingNoCredits remaining after this call.
manifestURLNo
rejectedStyleNoPresent only when the request was rejected because the style does not appear to describe a visual style: the submitted style text. No generation ran and nothing was charged; revise the style (or drop it and use styleReferences) and resubmit.
rejectedScenesNoPresent only when the request was rejected because some scenes do not appear to describe distinct illustrations: the exact rejected entries. No generation ran and nothing was charged; revise or remove them and resubmit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / scenes / description
      Previous value: -"What each illustration shows, one entry per picture: either a list of scene descriptions or objects with description and filename (e.g. [{\"description\": \"a harbor market at dawn\", \"filename\": \"hero.webp\"}]). A scene is prose and may name a setting, a moment, the light and the camera. Entries must describe distinct pictures; without a filename, the file is named from the start of its scene."New value: +"What each illustration shows, one entry per illustration: either a list of scene descriptions or objects with description and filename (e.g. [{\"description\": \"a harbor market at dawn\", \"filename\": \"hero.webp\"}]). A scene is prose and may name a setting, a moment, the light and the camera. Entries must describe distinct illustrations; without a filename, the file is named from the start of its scene."
    • changedOutput schema / properties / rejectedScenes / description
      Previous value: -"Present only when the request was rejected because some scenes do not appear to describe distinct pictures: the exact rejected entries. No generation ran and nothing was charged; revise or remove them and resubmit."New value: +"Present only when the request was rejected because some scenes do not appear to describe distinct illustrations: the exact rejected entries. No generation ran and nothing was charged; revise or remove them and resubmit."
  2. Changed4 schema fields changed
    • addedOutput schema / properties / images / items / properties / bytes
      Added value: +{
      +  "description": "The image file's size in bytes.",
      +  "type": "integer"
      +}
    • addedOutput schema / properties / images / items / properties / maskLevels
      Added value: +{
      +  "description": "Under a file size limit (maxKB): how many transparency levels this image kept; 256 is exact.",
      +  "type": "integer"
      +}
    • addedOutput schema / properties / images / items / properties / overBudget
      Added value: +{
      +  "description": "Under a file size limit (maxKB): true when this image is still over the limit at the lowest step (quality 70, or the set's own when that is lower).",
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / images / items / properties / quality
      Added value: +{
      +  "description": "Under a file size limit (maxKB): the quality this image was delivered at.",
      +  "type": "integer"
      +}
  3. Added

TDQS

A4.5/5.0
Behavior4/5

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

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

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

Conciseness3/5

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

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

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

Completeness5/5

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

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

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

Parameters4/5

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

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

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

Purpose5/5

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

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

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

Usage Guidelines5/5

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

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

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources