Logospell

edit_image_set

Idempotent

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

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Output Schema

TableJSON Schema

Name	Required	Description
`width`	No
`height`	No
`images`	No
`levers`	No
`zipURL`	No
`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.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

AddedSep 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond annotations, it discloses that the download URL is replaced in place, list_recent_generations reflects new levers, no credits are spent, no history is kept, deterministic bytes result from identical levers, and the download window is never extended. It also explains jpg alpha limitations and background constraints.

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

Conciseness4/5

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

The description is well-organized and front-loaded with the core purpose, but it repeats some details that already appear in the parameter schema, such as jpg alpha behavior and width/height combination rules. Still, every major behavioral constraint earns its place.

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

Completeness5/5

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

For a complex 10-parameter tool, the description is remarkably complete: it covers eligibility, cost, idempotency, history behavior, download lifecycle, format edge cases, and restrictions. Combined with the detailed schema and output schema, an agent has everything needed to invoke it correctly.

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

Parameters4/5

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

The input schema already has 100% coverage with detailed descriptions, so the baseline is 3. The main description adds cross-cutting semantics such as omitted levers keeping current values, reset restoring the first delivery, and identical levers producing identical bytes, which goes beyond the individual parameter entries.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Change how an existing image set is delivered, without generating again.' It clearly distinguishes itself from generation tools by stating style, subjects, and references cannot be edited, and that 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 Guidelines5/5

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

It gives clear when-to-use context: edit delivery of an existing set without regenerating. It also gives explicit when-not-to-use boundaries: not for illustrations, not for sets without a source, and not for changing generative content. This effectively routes the agent toward generation tools for new pictures.

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

All Logospell tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation5/5

Each tool has a clearly distinct role: generation is split by output type (single illustration vs. solid-color set vs. transparent set), and the remaining tools handle references, delivery editing, icon export, credit checking, and listing. The three generation tools are heavily cross-referenced with explicit guidance on when to use each, leaving no boundary ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (check_credits, create_reference, edit_image_set, export_icons, generate_illustration, list_recent_generations). The two set-generation variants differ by a descriptive adjective but still follow the same generate_*_set shape, so the naming pattern remains predictable.

Tool Count5/5

Eight tools is well-scoped for an image generation service: three generation variants, one reference-upload helper, one delivery editor, one export tool, one credit checker, and one history/retrieval tool. Each tool serves a distinct workflow step without unnecessary redundancy.

Completeness4/5

The core lifecycle is well covered: generate (all three modes), upload references, edit delivered sets, export icons, check credits, and retrieve past generations. The only notable gap is that illustrations cannot be edited or re-delivered after generation, though the tool descriptions make this an explicit design constraint rather than an oversight.

Resources

Need Help?