Skip to main content
Glama

Generate images

generate_image

Generate on-brand images (photography, scenes, product shots) from prompts. Not a design: no headline, logo or layout - use generate_design for those. One call takes every image the user asked for: one entry in images per different image, never one call per image. To build on images the user picked ("like this one but tighter", "the same scene from another angle"), name them in that entry's referenceCreativeIds rather than starting from scratch. Cost: charged per image, 30 credits at quality standard, 20 at fast (the cheaper model). A call makes images × count of them. Call with dryRun: true first and tell the user the cost. Once they agree, pass the quoted credits as expectedCredits; a call that would cost a different amount is refused. Give each new generation a new requestId, and repeat it unchanged only on a retry: a retry within 2 minutes returns the first result and is not charged again. Without a requestId, the same arguments within 2 minutes count as a retry. Needs generation allowed over MCP (see get_workspace); a dry run still quotes when it is not, and says why the call would be refused in wouldRefuse. Returns jobs, one jobId per entry in images, creditsCharged and creditsRemaining; ready in 1 to 5 minutes. If a job panel shows, it tracks the work: do not poll, end your turn with one line saying it is under way, and later use show_creatives with the creativeIds you are told. Otherwise call wait_for_jobs with the jobIds until allFinal is true.

Input Schema

NameRequiredDescriptionDefault
countNoHow many variations of each entry to make. Defaults to 1. The call makes images × count images, each charged.
dryRunNotrue: return the exact cost (credits, breakdown, balanceAfter) without charging or starting anything, and wouldRefuse when the organization's spending controls would refuse the real call.
imagesYesEvery image the user asked for, one entry per different image. Each becomes its own job.
brandIdNoA brand id from get_workspace or list_brands, or the brand's name. Omit it when the organization has a single brand.
qualityNoDefaults to standard.
entityIdsNoIds from list_entities of the products, places, ambassadors or design elements the design must feature. The designer uses that entity's real images, so only name what the user asked for.
requestIdNoYour own unique id for this request. Use a new one for every new request, even with the same arguments. Repeat it unchanged only to retry this exact call within 2 minutes; the retry returns the first result.
aspectRatioYesThe canvas shape, by name or ratio ("9:16" is portrait_9_16).
designSystemIdNoA design system id from list_design_systems, the look to make it in. Omit for the brand's default design system.
expectedCreditsNoThe credits the dryRun quoted and the user agreed to. The call is refused if it would cost a different amount.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / brandId / description
      Previous value: -"A brand id from get_workspace or list_brands. Omit it when the organization has a single brand."New value: +"A brand id from get_workspace or list_brands, or the brand's name. Omit it when the organization has a single brand."
    • changedInput schema / properties / count / description
      Previous value: -"How many different images to make. Defaults to 1. Each one is charged."New value: +"How many variations of each entry to make. Defaults to 1. The call makes images × count images, each charged."
    • addedInput schema / properties / images
      Added value: +{
      +  "description": "Every image the user asked for, one entry per different image. Each becomes its own job.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "name": {
      +        "description": "A short name for this image, echoed back with its jobId as concept.",
      +        "type": "string"
      +      },
      +      "prompt": {
      +        "description": "What this image should show, in plain words.",
      +        "type": "string"
      +      },
      +      "referenceCreativeIds": {
      +        "description": "Ids of finished images in the brand's library (from list_creatives, search_library, get_upload or a job of this conversation) to build on: the one the user picked and wants another like, changed as the prompt says. Only images the user pointed at. A carousel is sent as every one of its pages, and each page counts toward the images one generation takes.",
      +        "items": {
      +          "type": "string"
      +        },
      +        "type": "array"
      +      }
      +    },
      +    "required": [
      +      "prompt"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 12,
      +  "minItems": 1,
      +  "type": "array"
      +}
    • removedInput schema / properties / prompt
      Removed value: -{
      -  "description": "What the image should show, in plain words.",
      -  "type": "string"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "prompt",
      -  "aspectRatio"
      -]New value: +[
      +  "images",
      +  "aspectRatio"
      +]
    • changedOutput schema / anyOf
      Previous value: -[
      -  {
      -    "additionalProperties": false,
      -    "properties": {
      -      "balanceAfter": {
      -        "type": "number"
      -      },
      -      "breakdown": {
      -        "type": "string"
      -      },
      -      "credits": {
      -        "type": "number"
      -      },
      -      "deduplicated": {
      -        "const": true,
      -        "description": "The same call was made in the last 2 minutes: this is its result, not charged again.",
      -        "type": "boolean"
      -      },
      -      "dryRun": {
      -        "const": true,
      -        "type": "boolean"
      -      },
      -      "wouldRefuse": {
      -        "description": "Set when the organization's MCP spending controls would refuse the real call: the refusal it would get.",
      -        "type": "string"
      -      }
      -    },
      -    "required": [
      -      "dryRun",
      -      "credits",
      -      "breakdown",
      -      "balanceAfter"
      -    ],
      -    "type": "object"
      -  },
      -  {
      -    "additionalProperties": false,
      -    "properties": {
      -      "creditsCharged": {
      -        "type": "number"
      -      },
      -      "creditsRemaining": {
      -        "type": "number"
      -      },
      -      "deduplicated": {
      -        "const": true,
      -        "description": "The same call was made in the last 2 minutes: this is its result, not charged again.",
      -        "type": "boolean"
      -      },
      -      "jobId": {
      -        "type": "string"
      -      },
      -      "watchToken": {
      -        "type": "string"
      -      }
      -    },
      -    "required": [
      -      "jobId",
      -      "watchToken",
      -      "creditsCharged",
      -      "creditsRemaining"
      -    ],
      -    "type": "object"
      -  }
      -]New value: +[
      +  {
      +    "additionalProperties": false,
      +    "properties": {
      +      "balanceAfter": {
      +        "type": "number"
      +      },
      +      "breakdown": {
      +        "type": "string"
      +      },
      +      "credits": {
      +        "type": "number"
      +      },
      +      "deduplicated": {
      +        "const": true,
      +        "description": "The same call was made in the last 2 minutes: this is its result, not charged again.",
      +        "type": "boolean"
      +      },
      +      "dryRun": {
      +        "const": true,
      +        "type": "boolean"
      +      },
      +      "wouldRefuse": {
      +        "description": "Set when the organization's MCP spending controls would refuse the real call: the refusal it would get.",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "dryRun",
      +      "credits",
      +      "breakdown",
      +      "balanceAfter"
      +    ],
      +    "type": "object"
      +  },
      +  {
      +    "additionalProperties": false,
      +    "properties": {
      +      "creditsCharged": {
      +        "type": "number"
      +      },
      +      "creditsRemaining": {
      +        "type": "number"
      +      },
      +      "deduplicated": {
      +        "const": true,
      +        "description": "The same call was made in the last 2 minutes: this is its result, not charged again.",
      +        "type": "boolean"
      +      },
      +      "jobs": {
      +        "items": {
      +          "additionalProperties": false,
      +          "properties": {
      +            "concept": {
      +              "type": "string"
      +            },
      +            "jobId": {
      +              "type": "string"
      +            },
      +            "watchToken": {
      +              "type": "string"
      +            }
      +          },
      +          "required": [
      +            "jobId",
      +            "watchToken"
      +          ],
      +          "type": "object"
      +        },
      +        "type": "array"
      +      }
      +    },
      +    "required": [
      +      "jobs",
      +      "creditsCharged",
      +      "creditsRemaining"
      +    ],
      +    "type": "object"
      +  }
      +]
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say it is a non-read-only, non-destructive, non-idempotent write. The description adds the facts an agent actually needs: per-image pricing (30 standard / 20 fast), a 2-minute free retry window keyed on requestId, the expectedCredits mismatch refusal, and the MCP-generation permission prerequisite surfaced through wouldRefuse on a dry run.

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?

Front-loaded with purpose and the alternative, and every sentence carries a distinct operational fact. It is dense and slightly sprawling across cost, retry and job-polling topics, but not padded; the return-value sentence overlaps somewhat with the output schema.

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 cost quoting, the confirm-then-call sequence, idempotency/retry handling, permission failure mode, expected latency (1-5 minutes) and the two follow-up paths (job panel vs wait_for_jobs). Nothing an agent needs to invoke and follow through correctly 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 coverage is 100%, so the baseline is 3. The description still adds real meaning by explaining the images array cardinality rule (one entry per distinct image, all in a single call) and how referenceCreativeIds differs from prompting from scratch, though it does not extend semantics for aspectRatio, quality or brandId beyond the schema.

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 on-brand images ... from prompts") and immediately names the excluded sibling ("Not a design: no headline, logo or layout - use generate_design for those"). An agent can distinguish this from generate_design without opening either 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_design for layouts, use referenceCreativeIds when the user points at existing images, one call for all requested images rather than one call per image. It also prescribes the dryRun-then-expectedCredits workflow and what to do instead of polling when a job panel appears.

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