Skip to main content
Glama

Generate Image

generate-image

Generate a standalone image from a text prompt, or edit/restyle images supplied as references.

When to use: Use this tool based on the requested output, not assumed model limitations such as an inability to render text.

If the user explicitly asks for an image, picture, photo, illustration, artwork, sticker, icon, graphic, or 2d vector, use this tool. The explicitly named output takes priority over design-like content within it, including text, statistics, labels, callouts, or an infographic-like composition. For example, "create an image about coffee with bold stat callouts" uses generate-image.

Use create-design when the requested output itself is an editable Canva page or layout, such as "create an infographic". "Create an image of an infographic" still uses generate-image. The verb "create" or "design" alone does not make the request a Canva design.

When not to use: Do not use when the requested output itself is a designed page or layout, such as an infographic, poster, wallpaper, flyer, presentation, or social media post; use create-design. To add, position, resize, or replace content inside an existing design, use the design-editing workflow instead; the image is source media and the design page is the edit target.

Image references and attachments: For image-to-image generation or editing, add one MEDIA entry to imageReferences for every reference image. Pass the ID of an existing Canva MEDIA content reference directly.

Before using a user-provided attachment as a reference, upload it to Canva: call create-upload-url, then send the attachment's raw bytes to the returned upload URL exactly as instructed. Each upload URL is single-use, so call create-upload-url separately for every attachment. Wait for every upload to succeed, then use the mediaId from each upload response as a separate MEDIA entry in imageReferences. For example, after uploading two attachments (replace the illustrative IDs with their returned mediaIds):

{
  "prompt": "Restyle both reference images as watercolor illustrations",
  "imageReferences": [
    {"type": "MEDIA", "id": "MAAAAAAAAAAA"},
    {"type": "MEDIA", "id": "MBBBBBBBBBBB"}
  ]
}

Use exactly one imageReferences entry per successfully uploaded attachment. Never combine multiple media IDs into one string or object, and never put an upload URL in imageReferences. Do not pass assistant-hosted attachment URLs directly to this tool. If any attachment cannot be uploaded, do not silently omit it; explain the failure to the user.

Omit imageReferences for pure text-to-image generation.

Result: This call returns only a jobId, not the finished image. When this tool's UI widget is shown, the widget polls get-generate-image-job itself and displays the image when ready - do not poll it yourself. Only when no widget is shown, pass the jobId to get-generate-image-job and keep checking until the job succeeds or fails.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
promptYesText prompt describing the image to generate
aspectRatioNoDesired output aspect ratio, applied on a best-effort basis. When editing a previously generated image, reuse the exact `aspectRatio` enum value used to generate that image if that value is present in prior conversation or tool-call context, unless the user explicitly requests a different ratio. If the prior enum value is unavailable, omit this argument. For a new image without an explicit ratio, omit this argument. Do not retry solely if the returned image does not exactly match the requested ratio. When provided, `aspectRatio` must be exactly one of the enum values listed below. Translate the user's request into the matching enum value; for example, for `1:1`, send `SQUARE_1_1`. Never send a raw ratio such as `1:1` or a descriptive word such as `square`. If the user provides both an explicit numeric ratio and conflicting descriptive wording, use the numeric ratio to choose the enum value. - `SQUARE_1_1`: Use for "square" or "1:1". - `LANDSCAPE_16_9`: Use for "landscape", "wide", "widescreen", or "16:9". - `LANDSCAPE_5_4`: Use for an explicit "5:4". - `LANDSCAPE_4_3`: Use for an explicit "4:3". - `LANDSCAPE_3_2`: Use for an explicit "3:2". - `LANDSCAPE_2_1`: Use for an explicit "2:1", "panoramic", or "ultra-wide". - `PORTRAIT_9_16`: Use for "portrait", "tall", "vertical", or "9:16". - `PORTRAIT_4_5`: Use for an explicit "4:5". - `PORTRAIT_3_4`: Use for an explicit "3:4". - `PORTRAIT_2_3`: Use for an explicit "2:3". - `PORTRAIT_1_2`: Use for an explicit "1:2".
user_intentNoMandatory description of what the user is trying to accomplish with this tool call. This should always be provided by LLM clients. Please keep it concise (255 characters or less recommended).
imageReferencesNoOptional source images to guide generation, such as for image editing. Each must be a MEDIA content reference. For a GeneratedImageResult, reference its media_id, never its design_id or applied_page_id. Omit for pure text-to-image generation.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobIdYesIdentifies the job this call started. Pass it to the companion poll tool to check on the job.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly=false, destructive=false, openWorld=true, idempotent=false), and the description adds substantial context beyond them: it returns only a jobId, the widget polls get-generate-image-job so the agent should not poll itself, upload URLs are single-use, and attachments must be uploaded first. This is a rare case of rich behavioral disclosure.

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?

It is long, but well front-loaded with bolded section headers (When to use / When not to use / Image references / Result) and every section carries non-redundant instructions. It is appropriately sized for a tool with a multi-step upload-and-poll workflow, though some prose could be tightened.

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?

Given the high complexity and the existence of an output schema, the description still supplies the missing operational context: the async jobId flow, widget-driven polling behavior, and the upload prerequisite. Nothing an agent needs to call and follow up correctly is absent.

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, but the description goes further on imageReferences: one MEDIA entry per successfully uploaded attachment, never combine IDs, never pass an upload URL, omit entirely for text-to-image. This is workflow semantics the schema cannot express, though much still lives in the schema's own aspectRatio documentation.

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 states a specific verb and resource ('Generate a standalone image from a text prompt, or edit/restyle images supplied as references') and explicitly distinguishes the tool from the sibling create-design, including the edge case 'Create an image of an infographic' vs 'create an infographic'. An agent can select it without opening any 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?

It provides explicit when-to-use and when-not-to-use sections, names the alternative tool (create-design) with the precise condition that selects it, and clarifies that the verb 'create'/'design' alone does not route to create-design. Nearly every selection ambiguity is pre-resolved.

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