Skip to main content
Glama

generate_image

Generate one or more images from a text prompt, billed to the caller's credits.

Requires authentication. Anonymous image generation is available only via the REST API (POST /v1/image-generators/{id}/runs); the MCP transport always authenticates.

Resolution order for the generator (highest priority first):

  1. A deployed generator ref (uuid@version or bare UUID): pins the deployed version config.

  2. The model control path (authenticated one-off, ephemeral). Not usable from published templates.

  3. A tier generator ref (system:<tier>): resolves to the tier's current best model (auto-upgrade). Available tiers: system:image-standard (default), system:image-premium, system:image-edit (image-to-image, requires reference_image_url).

  4. Default: system:image-standard when no generator or model is given.

generator and model are mutually exclusive.

For image_to_image generators, reference_image_url is required and must be a public HTTP or HTTPS URL. For text_to_image generators, providing reference_image_url is rejected.

Billing: spend is deducted from the caller's monthly credit balance. BudgetExhausted (402) and AccountSuspended (403) propagate if the balance is zero or the account is suspended.

visibility sets the access level of the hosted copy of each image: public (default) returns a link that opens in any browser; private returns a link only you can open and forward to people you choose, while the plain URL stays locked.

Returns: {run_id, model_tier_or_model, image_url, image_urls, width, height, num_images, cost_usd, duration_ms, status, created_at, error_code, error_message, hosted_images}. hosted_images carries the durable Goodeye-hosted copy of each image with its url (the browser-viewable link) and visibility. The prompt is never stored; only its hash is persisted on the run row.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
payloadYesPayload for ``generate_image``: produce one or more images from a prompt, billed to the caller's credit balance. Supply ``generator`` to use a named system tier (e.g. ``system:image-standard``) or a deployed generator by ``uuid@version``. Supply ``model`` for an authenticated one-off using a concrete model identifier. ``generator`` and ``model`` are mutually exclusive; omitting both resolves to the default tier.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / payload / properties / skill_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Optional skill UUID for provenance. Access-checked: a skill the caller cannot see surfaces as NotFound rather than being stamped onto the run."
      +}
    • addedInput schema / properties / payload / properties / skill_ref
      Added value: +{
      +  "anyOf": [
      +    {
      +      "maxLength": 256,
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Free-form skill label (slug, name) for human-readable provenance."
      +}
    • addedInput schema / properties / payload / properties / skill_version
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Skill version invoking this run, paired with ``skill_id``."
      +}
    • removedInput schema / properties / payload / properties / workflow_id
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "Optional workflow UUID for provenance. Access-checked: a workflow the caller cannot see surfaces as NotFound rather than being stamped onto the run."
      -}
    • removedInput schema / properties / payload / properties / workflow_ref
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "maxLength": 256,
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "Free-form workflow label (slug, name) for human-readable provenance."
      -}
    • removedInput schema / properties / payload / properties / workflow_version
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "integer"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "Workflow version invoking this run, paired with ``workflow_id``."
      -}
  2. Changed1 schema field changed
    • addedInput schema / properties / payload / properties / visibility
      Added value: +{
      +  "default": "public",
      +  "description": "Access level for the hosted copy of each generated image. ``public`` (default) returns a link that opens in any browser. ``private`` returns a link only you can open and forward to people you choose, while the plain URL stays locked. Anonymous generations are always public.",
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations are all false (not read-only, not idempotent), so the description carries the disclosure burden and delivers richly: it reveals MCP-transport always authenticates (anonymous only via REST), billing deducted from monthly credit balance, BudgetExhausted (402) and AccountSuspended (403) propagation, the public/private visibility behavior, and that the prompt is never stored (only its hash persisted). This far exceeds what the annotations express and adds genuine safety/cost context.

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 the core purpose and well structured into a numbered resolution list and labeled sections (authentication, billing, visibility, returns). Every sentence carries information, and the length is justified by the tool's complexity (11 nested params). Minor redundancy: the visibility explanation is duplicated almost verbatim in the schema description, which could be trimmed.

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 high-complexity tool with a nested payload and an output schema (which covers the return shape), the description is remarkably complete: it covers authentication, billing and error propagation, the generator resolution order, mutual exclusivity, per-type reference_image_url rules, and prompt-privacy. Nothing an agent needs to call it 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 each of the 11 payload fields is already documented, giving a baseline of 3. The description adds value on top: the generator resolution priority (deployed > model > tier > default), the generator/model mutual exclusivity rule, and the billing-per-image semantics for num_images. The visibility text is somewhat redundant with the schema, but the resolution-order context is net-new and material.

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 states a specific verb+resource: 'Generate one or more images from a text prompt, billed to the caller's credits.' This clearly distinguishes the tool from siblings like get_image, list_images, upload_image, and delete_image. The scope (prompt→image, billing) is unambiguous and does not restate the name.

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?

Extremely explicit guidance: a numbered resolution order for the generator (deployed ref > model > tier > default), the mutual exclusivity of generator and model, and the requirement/rejection rules for reference_image_url by generator type (image_to_image requires it, text_to_image rejects it). An agent is told exactly how to select among the parameter paths, with no inference required.

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.