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 cut 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.

TDQS

A4.8/5.0

Behavior5/5

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

Even with annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description adds substantial behavioral context: the download URL is replaced in place, no credits are spent, left-out levers retain their current value, no history is kept because identical levers produce identical bytes, and editing never extends the download window. It also details jpg alpha composition and background constraints, going well beyond the annotations.

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 long but deliberately front-loaded with the core purpose and primary caveat ('without generating again'). Every sentence carries useful constraints or behaviors. While it could be trimmed slightly, given the tool's complexity with 10 parameters and many edge cases, the length is justified and well-structured.

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 tool with 10 parameters, complex interactions, and multiple constraints, the description covers all necessary aspects: levers and their combinations, limitations (illustrations, pre-history sets), side effects (URL replacement, no history), and the generation id source. An output schema exists, so return values are already covered. Nothing essential is missing.

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 description coverage is 100%, so the baseline is 3. However, the description adds global semantics not present in any single parameter: the rule that a left-out lever keeps its current value, the interaction between width/height and canvas, and the jpg/background coupling. These cross-parameter rules meaningfully enhance understanding beyond the already-rich schema, justifying a 4.

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 enumerates exactly what levers can change (width, height, canvas, margin, sizing, format, quality, background) and clearly distinguishes from generation tools by noting style, subjects, and references cannot be edited. This is precise and unambiguous.

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?

The description explicitly states when to use this tool (to alter an existing set's delivery without generating) and when not to: 'Style, subjects and references are generation and cannot be edited - a different picture is a new set.' It also excludes illustrations and pre-existing sets without sources. This provides clear decision criteria relative to sibling tools like generate_image_set.

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 targets a clearly distinct operation: three generation tools are explicitly differentiated by output type (single illustration vs. solid-color set vs. transparent set), while reference upload, editing, export, credit checking, and listing are all unambiguous. Cross-references between tools further eliminate any boundary confusion.

Naming Consistency5/5

All eight tools follow the same snake_case verb_noun pattern: check_, create_, edit_, export_, generate_, list_. The three generate_* tools share a common prefix with distinct objects, making the naming predictable and scannable.

Tool Count5/5

Eight tools is well-scoped for a logo/icon generation service: three generation variants, one editing tool, one export tool, one reference upload mechanism, plus account and history utilities. Each tool earns its place without redundancy or bloat.

Completeness5/5

The tool surface covers the full creative lifecycle: reference preparation (create_reference), generation (three variants), post-processing (edit_image_set), delivery conversion (export_icons), and session management (list_recent_generations, check_credits). Deletion is unnecessary because references and downloads expire naturally, so there are no dead ends.

Resources

Need Help?