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. A set made with sameScene is sent its first scene and its last scene instead, along with any style references: each new scene is drawn from the set's first scene and from the scene before it, the first new scene from the set's last scene, so write each new scene as only what is different from the scene before it. 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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "generation": "<generation>",
      "scenes": "<scenes>"
    },
    "name": "extend_illustration_set"
  }
}

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.4/5.0
Behavior3/5

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

Annotations already declare the safe-write profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), and the description adds real context beyond them: 1 credit per call, up to 6 scenes, 2500-char scene limit, refusal of non-distinct scenes before charging, the joined-batch listing behavior, and the restarted download window. It does not contradict any annotation, but much of its length is delivery/UI procedure rather than tool behavior, so the incremental behavioral disclosure is solid rather than exceptional.

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

Conciseness4/5

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

Purpose is front-loaded in sentence one and constraints are cleanly bulleted. The final paragraph on showing images runs long with some restatement ("Show each image exactly as delivered, as its own file" / "Files on disk or a link in your context are not delivery"), but nearly every sentence carries a distinct instruction.

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?

Covers everything an agent needs for a mutation tool with 5 parameters and no enums: cost, batch size cap, scene length cap, concurrency rule, refusal semantics, inheritance model for style and sameScene sets, and post-call delivery handling. An output schema exists, so return values need not be described and are not.

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 already 100%, so the schema documents width, height, scenes, unpackTo and generation. The description still adds meaning the schema does not: what the generation id inherits (style text, style references, the named batch's format and quality), how sameScene sets chain scenes (each scene written as only the delta from the prior one), and how the first new scene seeds from the set's last scene.

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 and resource ("Add more scenes to a set made with generate_illustration_set") and immediately ties the tool to the sibling that creates sets, so an agent can tell creation from extension without opening a schema.

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

Usage Guidelines5/5

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

Gives explicit routing rules: "To change the style, start a new set instead; to change only how a batch is delivered, use edit_set," plus a hard sequencing constraint ("Run generation calls sequentially, never in parallel") and the retry rule for rate-limit errors. When-not-to-use and alternatives are both named.

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