Skip to main content
Glama

generate_logo_variations

Generate a SET of VARIATIONS of ONE logo - the logo recognizable in every image, each image showing it a different way - on one SOLID-COLOR background or a TRANSPARENT one: the logo restyled, in materials and finishes (gold foil, embroidery, neon, carved wood), in seasonal versions, or a mascot mark doing different things. The logo parameter is the logo itself, as 1 to 3 reference images; the optional brief parameter says what applies to every image, such as lettering to add; the optional variations parameter says how each image shows it, and left out, the model invents 16 variations from the logo; the background parameter is a color or "transparent". Returns a zip download URL. Cost: 1 credit per call. Run generation calls sequentially, never in parallel - only one generation runs at a time per API key.

For first ideas when there is no logo yet, use generate_concept_set.

Output formats: PNG (lossless), JPEG, or WebP; JPEG has no alpha channel, so a set delivered transparent is PNG or WebP.

Size and quality considerations match generate_image_set: leaving width and height unset delivers native resolution (best quality, varies between generations; relative sizing scales nothing but a variation far larger than the rest, fill scales each variation to its frame); fixing them resamples to that box, and fixing one axis lets the other hug each variation.

IMPORTANT - brief and variation rules for best results:

  • The brief is optional and applies to every image: a name, initials or a tagline to letter in, must-haves, and things to avoid. The logo itself comes from the logo images.

  • Listing the variations says exactly how each image shows the logo; leaving them out lets the model invent them, each file and caption numbered and named from what it shows (variation_01_cast_in_gold.png, "Variation 1: cast in gold"), and the logo is all it has to go on.

  • With a list, the logo keeps its shape unless the brief or a variation says otherwise; without one, the model varies its design too, keeping the logo's pictured elements and words. Each variation decides its style, material, color, finish, or what it is doing, and whatever a variation does not mention stays as the logo shows, so variations that name only an action keep the logo's look.

  • Each image is ONE isolated logo, not a scene: never describe a surrounding setting, scenery or backdrop.

  • Do not put background color or background descriptions in the variation text.

  • Lettering is welcome: the logo's own lettering is kept and restyled with it, and the brief or a variation can add a name, initials or a tagline.

  • Maximum 16 images per generation.

  • Brief description max length: 500 characters. Variation description max length: 200 characters each.

  • Size: width and height are separate parameters, each 256 to 512 pixels when given. Both given is an exact box; one given fixes that axis and the other hugs each variation (so images in the set differ on it, and it may fall below 256); neither given delivers native resolution, which is also the path to larger images.

  • Sizing: relative (the default) keeps the sizes the model gave the variations in relation to one another, one scale for the whole set; fill scales each variation on its own to fill its frame less the margin, the icon-set convention, giving up relative size and enlarging variations smaller than the frame (the result says by how much). Both can be changed later with edit_set.

  • More variations: call this tool again with the same logo and new variations, or none for another invented set. Logo variations have no extend tool.

  • 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": {
      "logo": "<logo>"
    },
    "name": "generate_logo_variations"
  }
}

Input Schema

NameRequiredDescriptionDefault
logoYesThe logo, as 1 to 3 images of it. Each entry is a ref_ token from the create_reference tool: create an upload slot, send the image file with the curl command it returns, then pass the token here. Image data itself never goes in a tool call; ref_ tokens are the only accepted form. Uploads take PNG, JPEG, or WebP; size and dimension limits are given in the create_reference tool's description. To use an image from one of your own recent sets, such as a concept chosen from generate_concept_set, fill the reference from it with create_reference's sourceGeneration and sourceImage: no upload needed.
briefNoOptional: what applies to every variation, in words: for example "Include our brand text, SUNNY BAKES, on each one." A name, initials or a tagline to letter in, must-haves and things to avoid go here; the logo itself comes from the logo images.
maxKBNoA file size limit for each image, in KB (1 KB = 1024 bytes), 10 to 10240; webp only (rejected with png or jpg). An image that fits keeps the quality set above; one that does not has its quality and the precision of its transparent edges lowered together, 5 quality points at a time down to 70, until it fits (a set below 70 keeps its quality and lowers only its edges), so images in a set can land at different qualities and the faintest edges of a busy transparent image can soften. An image still over the limit at the last step is delivered anyway and named in the result. For platforms that cap each file's size. Omit for no limit.
widthNoDelivered width in pixels. Give both width and height for an exact box (every image lands on it, one uniform scale, the shorter axis padded); give only one and the other axis hugs each variation at that scale plus the margin (so images in the set differ on it); give neither and images arrive at their native size (relative sizing scales nothing but a variation far larger than the rest, fill scales each variation to its frame) - the highest detail, though dimensions then vary between generations. The per-axis range is given in the tool description; a given axis outside it is rejected, and the hugging axis is whatever each variation needs. A fixed size guarantees consistent dimensions across images and generations but applies Lanczos resampling which may soften fine detail; if the user will post-process the images, recommend leaving both unset.
formatNoOutput format: png, jpg, or webp. Defaults to png. jpg has no alpha channel, so a set delivered transparent is png or webp.
heightNoDelivered height in pixels; see width for how the two combine (both: an exact box; one: the other axis hugs each variation; neither: native size).
sizingNoHow variations are scaled. relative (the default) keeps the sizes the model gave them in relation to one another: one scale for the whole set, so a small variation stays small in its frame. fill scales each variation on its own to fill the frame less the margin, touching it on one axis, so every image reads at the same visual weight (icon-set convention); that gives up relative size and enlarges any variation smaller than the frame, which the result reports when it happens.
qualityNoImage quality for jpg/webp (1-100). Defaults to 90.
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).
backgroundNoThe background every image sits on: a 6-char hex color #RRGGBB (e.g. #ffffff, #2c3e50), or "transparent" for images with no background that drop onto any backdrop. Default is #ffffff. Do not mention background in the brief or variation descriptions.
variationsNoOptional: leave it out and the model invents 16 variations from the logo, each delivered numbered and named from what it shows (variation_01_cast_in_gold.png). Otherwise how each image shows the logo, one entry per image: a style, a material, a finish, or what the mark is doing (e.g. ["cast in polished gold", "stitched as an embroidered patch", "waving hello"]), as text or objects with description and filename. Whatever an entry does not mention stays as the logo shows. Entries must be distinct: entries differing only in case, punctuation, or spacing are rejected as the same. Write each variation as plain text, with no list marker such as "1." or "-" in front, no square brackets, and no invisible characters.
minimumMarginNoMinimum margin in pixels around each variation. Defaults to 20. At most 15% of the smallest given axis when width or height is given, at most 80 when neither is; negative values are rejected. With relative sizing the actual margin varies by variation and never falls below this (only the set's largest variation sits exactly on it); with fill sizing every variation touches it on one axis.

Output Schema

NameRequiredDescriptionDefault
briefNo
formatNoThe delivered image format.
imagesNoThe generated images: each one's file name inside the zip, its variation, and its pixel width and height.
zipURLNoDownload URL for the zip of generated images. Time-limited; expiresAt states the deadline.
unpackToNoThe caller-supplied local extraction path, echoed back.
expiresAtNoWhen the download URL expires.
remainingNoCredits remaining after this call.
backgroundNoThe background color used, or transparent.
manifestURLNo
rejectedBriefNoPresent only when the request was rejected because the brief does not appear to be usable text: the submitted text. No generation ran and nothing was charged; revise it and resubmit.
rejectedVariationsNoPresent only when the request was rejected because some variations do not appear to describe distinct, drawable variations: 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. Added

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnly=false, openWorld=true, non-idempotent, non-destructive. Beyond that the description adds real value: cost of 1 credit per call, the serial-execution constraint, the zip URL return, and retry behavior on rate-limit errors. However, a large block of the text is post-delivery presentation instructions for the client rather than behavior of the tool itself, which dilutes the behavioral signal for a 12-parameter generation call.

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

Conciseness2/5

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

The purpose is front-loaded, but the body is bloated and duplicates the schema: width/height behavior, sizing semantics, and background are all restated at length after being fully documented in the parameters. The multi-paragraph image-delivery protocol is disproportionate to the tool's function and buries actionable rules mid-block.

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

Completeness4/5

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

An output schema exists, yet the description still states the return (a zip download URL), which is helpful, and it covers cost, limits, and quantity defaults for a complex tool. It is nearly complete; the gap is that the delivery instructions, not the generation behavior, take up most of the remaining space.

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 still adds non-structural rules the schema does not carry, such as brief max 500 characters, variation max 200 characters, max 16 images, variations must be distinct, and never put background descriptions in variation text. Those constraints meaningfully shape correct parameter construction.

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?

States a specific verb and resource ('Generate a SET of VARIATIONS of ONE logo'), defines the invariant (logo recognizable in every image), and names the sibling it is not for ('For first ideas when there is no logo yet, use generate_concept_set'). An agent can distinguish it from generate_image_set and generate_concept_set 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?

Explicit routing rules: use generate_concept_set when no logo exists, no extend tool exists for logo variations, and to get more variations re-call this tool with the same logo. It also gives operating conditions (run sequentially, one generation per API key, back off on rate-limit errors) and when to omit width/height for best quality.

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