Skip to main content
Glama

edit_set

Idempotent

Change how an existing image set, character set or illustration set is delivered, without generating again: its width and height (both, one, or neither, exactly as on the set tools), its canvas when no size is fixed (one canvas for the whole set, or each image wrapped around its own subject), its minimum margin, its sizing (relative or fill), its format and quality, a file size limit per image on webp (maxKB), and for a character set or a transparent image set its background (any color, or transparent). The set is delivered again from its full-resolution source and its download is replaced in place: the same download URL now serves the new delivery, and get_generations reports the new levers. Free; no credits are spent. What the pictures show (the style or character, the subjects, variations or scenes, and the references) cannot be edited - a different picture is a new set.

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

A lever left out keeps its current value, so one call can change one thing. Any earlier state, the original delivery included, is one edit away: nothing is kept as history because the same levers always produce the same bytes. Editing never extends a set's download window.

jpg has no alpha: asking for jpg on a set delivered transparent composes the images over white unless a background color is in force (given in the same call or kept from an earlier edit); jpg together with background "transparent" is rejected. background applies to character sets and transparent image sets only. Not available for sets generated before editing existed (they have no source).

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

Input Schema

NameRequiredDescriptionDefault
maxKBNoNew file size limit for each image, in KB, webp only: each image is encoded under it as on the set tools, its quality and the precision of its transparent edges lowered together only where needed, down to quality 70; a set below 70 keeps its quality and lowers only its edges. An image still over the limit is named in the result. 0 removes the limit. Left out, the current limit stays.
resetNotrue restores every lever to the first delivery's (the set as it was generated), read from the set's own record; any other lever given in the same call is applied on top of that.
widthNoNew delivered width in pixels, or 0 to stop fixing the width. Left out, the current width stays. Width and height combine exactly as on the set tools: both fixed is an exact box, one fixed lets the other hug each subject, neither is native size. On an illustration set they go together, as one of its own sizes (see the tool description).
canvasNoWith NEITHER width nor height fixed, what the images land on: uniform (the default) puts the whole set on one canvas, the size it was generated at, every image alike; subject wraps each image around its own subject, so the images differ in size the way the subjects do. Says nothing when a size is fixed. Left out, the current value stays.
formatNoNew format: png, webp, or jpg. Left out, the current format stays. jpg has no alpha: on a set delivered transparent it composes the images over white unless a background color is in force (given in the same call or kept from an earlier edit).
heightNoNew delivered height in pixels, or 0 to stop fixing the height. Left out, the current height stays.
sizingNoNew sizing: relative keeps the sizes the model gave the subjects in relation to one another (one scale for the set); fill scales each subject on its own to fill the frame less the margin, so every image reads at the same visual weight, at the cost of relative size and of enlarging subjects smaller than the frame (the result reports by how much). Left out, the current sizing stays.
qualityNoNew quality (1-100) for webp and jpg; ignored for png. Left out, the current quality stays.
backgroundNoCharacter sets and transparent image sets only: a #RRGGBB color composes every image over it and delivers an opaque set; "transparent" delivers the images with their alpha. Left out, the current background stays. Rejected on an image set generated on a color, whose color is in its pixels and cannot change.
generationYesThe id of the set to edit - the random segment of its download URL, as list_recent_generations returns it. One batch of a set per call; a set that grew over several calls is edited batch by batch.
minimumMarginNoNew minimum margin in pixels around each subject, with the set tools' bounds. Left out, the current margin stays.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • addedInput schema / properties / maxKB
      Added value: +{
      +  "description": "New file size limit for each image, in KB, webp only: each image is encoded under it as on the set tools, its quality and the precision of its transparent edges lowered together only where needed, down to quality 70; a set below 70 keeps its quality and lowers only its edges. An image still over the limit is named in the result. 0 removes the limit. Left out, the current limit stays.",
      +  "type": [
      +    "null",
      +    "integer"
      +  ]
      +}
    • addedOutput schema / properties / images / items / properties / bytes
      Added value: +{
      +  "description": "The image file's size in bytes.",
      +  "type": "integer"
      +}
    • addedOutput schema / properties / images / items / properties / maskLevels
      Added value: +{
      +  "description": "Under a file size limit (maxKB): how many transparency levels this image kept; 256 is exact.",
      +  "type": "integer"
      +}
    • addedOutput schema / properties / images / items / properties / overBudget
      Added value: +{
      +  "description": "Under a file size limit (maxKB): true when this image is still over the limit at the lowest step (quality 70, or the set's own when that is lower).",
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / images / items / properties / quality
      Added value: +{
      +  "description": "Under a file size limit (maxKB): the quality this image was delivered at.",
      +  "type": "integer"
      +}
    • changedOutput schema / properties / levers / description
      Previous value: -"The delivery levers now in force: width, height, canvas, minimumMargin, sizing, format, quality, background; an illustration set has only width, height, format and quality."New value: +"The delivery levers now in force: width, height, canvas, minimumMargin, sizing, format, quality, background, and maxKB when a file size limit is set; an illustration set has only width, height, format and quality."
    • addedOutput schema / properties / levers / properties / maxKB
      Added value: +{
      +  "type": "integer"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / background / description
      Previous value: -"Transparent sets only: a #RRGGBB color composes every image over it and delivers an opaque set; \"transparent\" restores the alpha. Left out, the current background stays. Rejected on a solid-background set, whose color is in its pixels and cannot change."New value: +"Character sets and transparent image sets only: a #RRGGBB color composes every image over it and delivers an opaque set; \"transparent\" delivers the images with their alpha. Left out, the current background stays. Rejected on an image set generated on a color, whose color is in its pixels and cannot change."
    • changedInput schema / properties / format / description
      Previous value: -"New format: png, webp, or jpg. Left out, the current format stays. jpg has no alpha: on a transparent set it composes the images over white unless a background color is in force (given in the same call or kept from an earlier edit)."New value: +"New format: png, webp, or jpg. Left out, the current format stays. jpg has no alpha: on a set delivered transparent it composes the images over white unless a background color is in force (given in the same call or kept from an earlier edit)."
  3. Added

TDQS

A4.5/5.0
Behavior5/5

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

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

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

Conciseness3/5

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

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

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

Completeness5/5

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

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

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

Parameters4/5

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

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

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

Purpose5/5

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

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

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

Usage Guidelines4/5

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

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

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources