Skip to main content
Glama

Generate an image

generate_image
Destructive

Generate an image from a prose prompt with a platform-specific aspect ratio. Optionally use up to 6 reference keys, then get a media key for posts.

Instructions

Make one image from a prompt written as a scene in prose, in the aspect ratio of the platform it is for, optionally conditioned on up to 6 reference_keys from the media library (a logo, a product shot, an earlier image). quality "premium" is the dearer model. Returns the image as a media key with a URL; put the key in posts_create mediaKeys. SPENDS CREDIT: about $0.016 of engine cost a default call, billed with the plan's margin; budgetUsd caps it (default 2, max 10) and chargedUsd says what it cost. Needs the write scope.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesA 2-6 word filename for this image, the way you would describe it to a colleague - e.g. "founder desk golden hour". Becomes the file the user sees in their Assets.
sizeNo1K draft, 2K final.
promptYesThe full scene as 2-5 sentences of flowing prose, directing medium, subject, setting, light, and composition — YES "A photorealistic overhead shot of a cluttered founder desk at golden hour, one glowing laptop as the focal point, deep negative space on the right", NOT "desk, laptop, startup, 4k, trending, professional". When reference_keys are given, also say what each referenced object does in the scene.
qualityNostandard = the default model (default). premium = the fidelity escalation, several times the price.
budgetUsdNoOptional: the most this call may spend, in dollars, default 2, max 10.
aspectRatioYesLinkedIn feed image: 4:5. Wide header: 16:9.
reference_keysNoUp to 6 media keys to condition on: brand-asset keys from the digest, mediaKeys of earlier generated images, or chat-upload keys. Omit for a purely imagined scene.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
toolYes
mediaYes
outputNoThe tool's own result, shaped by the tool.
chargedUsdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.4

TDQS

A4.1/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, and the description goes well beyond them: it discloses the credit spend (~$0.016 per default call), that budgetUsd caps it (default 2, max 10), that chargedUsd reports actual cost, and that the write scope is required. This is exactly the cost/side-effect context an agent needs before invoking a paid mutation.

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 action and resource before the cost detail, and the credit/scope warnings are placed last where they belong. Slightly redundant with the schema on budgetUsd and the premium tier, but no sentence is wasted.

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 seven-parameter paid generation tool the description covers medium, sizing input, budget ceiling, output key handoff, and auth scope, and an output schema exists so return values need not be explained. The only real gap is the absence of explicit when-to-use-this-vs-find_photo/generate_footage routing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all seven parameters, and the description largely restates it (budgetUsd default/max, premium as 'the dearer model'). It adds only marginal framing, e.g. that premium quality and reference_keys are discretionary, so the baseline 3 applies.

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 ('Make one image from a prompt'), plus its key scope constraints (aspect ratio, up to 6 reference keys). An agent can tell it apart from generate_footage/render_thumbnail by the image medium and the prose-prompt requirement, without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Gives operational context ('in the aspect ratio of the platform it is for', 'put the key in posts_create mediaKeys', 'omit [reference_keys] for a purely imagined scene') but never states when to choose this over siblings like generate_footage, find_photo, or render_thumbnail. Usage is implied rather than routed.

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