Skip to main content
Glama

generate_image

Create new images or edit existing ones with Grok Imagine using a text prompt plus optional image files or URLs as references.

Instructions

Generate new images or edit existing ones with Grok Imagine.

Pass `image_paths` and/or `image_urls` to edit images or use them as
visual references. Multiple references are combined in a single call.

Args:
    prompt: Image description, or the edit instruction when references are provided.
    model: Image model (`grok-imagine-image` or `grok-imagine-image-pro`).
    image_paths: Local image files (JPG/PNG) used as edit sources or references.
    image_urls: Public image URLs used as edit sources or references.
    n: Number of images to generate (1–10).
    image_format: `"url"` (default) or `"base64"`. Base64 responses carry no URL,
        so they are always saved locally.
    aspect_ratio: Aspect ratio like `"16:9"`, `"1:1"`, or `"9:16"`.
    resolution: `"1k"` or `"2k"`.
    save: Write each image to `images/` and report the local path instead of the
        remote URL. Remote URLs are temporary, so save anything you want to keep.
    show_usage: Append a token usage and cost footer to the result (default False).

Returns:
    Markdown block listing each image as a saved local path when saving, otherwise
    as a temporary remote URL.

Input Schema

NameRequiredDescriptionDefault
nNo
saveNo
modelNogrok-imagine-image
promptYes
image_urlsNo
resolutionNo
show_usageNo
image_pathsNo
aspect_ratioNo
image_formatNourl

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.4
  2. Removed
  3. Changed1 schema field changedv1.0.1
    • addedInput schema / properties / show_usage
      Added value: +{
      +  "default": false,
      +  "title": "Show Usage",
      +  "type": "boolean"
      +}
  4. Added
  5. Removed
  6. Added
  7. Removed
  8. Changed5 schema fields changed
    • removedInput schema / properties / image_path
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "title": "Image Path"
      -}
    • addedInput schema / properties / image_paths
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Image Paths"
      +}
    • removedInput schema / properties / image_url
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "title": "Image Url"
      -}
    • addedInput schema / properties / image_urls
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Image Urls"
      +}
    • addedInput schema / properties / resolution
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Resolution"
      +}
  9. Added
  10. Removed
  11. Changed4 schema fields changed
    • addedInput schema / properties / aspect_ratio
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Aspect Ratio"
      +}
    • addedInput schema / properties / image_path
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Image Path"
      +}
    • addedInput schema / properties / image_url
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Image Url"
      +}
    • changedInput schema / properties / model / default
      Previous value: -"grok-2-image-1212"New value: +"grok-imagine-image"
  12. Changed2 schema fields changed
    • addedInput schema / properties / image_format
      Added value: +{
      +  "default": "url",
      +  "title": "Image Format",
      +  "type": "string"
      +}
    • removedInput schema / properties / response_format
      Removed value: -{
      -  "default": "url",
      -  "title": "Response Format",
      -  "type": "string"
      -}
  13. Changed1 schema field changedv1.0.0
    • addedInput schema / title
      Added value: +"generate_imageArguments"
  14. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden and does well: it warns that remote URLs are temporary and that base64 responses are always saved locally, and explains the save and show_usage side effects. It omits permission/auth requirements and any rate or cost limits beyond the optional usage footer.

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 one-line purpose followed by scannable Args/Returns sections; nearly every line earns its place. The Args list is long but justified by 10 undocumented parameters, with only minor redundancy around image_paths/image_urls.

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?

For a 10-parameter, no-annotation, no-output-schema tool, the description supplies a Returns section, save-locally vs temporary-URL behavior, and edit-mode routing. It is complete enough to call correctly, though it lacks error/permission context.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate and it does for every one of the 10 parameters: named model variants, allowed file types for image_paths, the 1–10 range for n, the url/base64 semantics of image_format, aspect-ratio examples, resolution values, and save/show_usage effects. This adds substantially more meaning than the bare 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 (generate/edit) and resource (images) with the Grok Imagine brand, and immediately distinguishes the two modes: creation vs. reference-based editing. An agent can distinguish it from generate_video and chat_with_vision 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 Guidelines4/5

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

Clearly states that passing image_paths/image_urls triggers edit/reference mode and that multiple references combine in one call, which is the key routing decision. It does not, however, name sibling alternatives (e.g. generate_video) or state when not to use this tool.

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