Skip to main content
Glama
imgly

CoDesign

Official
by imgly
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

asset_generate

Generate images with AI models for your designs. Supports text-to-image and image-to-image, returning workspace URIs for use in edits.

Instructions

Generate images (text-to-image, image-to-image) via the IMG.LY AI gateway.

Call with NO arguments first: returns the model catalog — pick a model, then call again with model + prompt (+ optional format aspect like "16:9").

For image-to-image, pass image_uris with workspace:// URIs (from import or earlier generations).

The first content part is JSON: { uri, httpUrl, mimeType, bytes }. uri (a workspace:// URI) is the durable handle — embed it in subsequent edit calls. httpUrl opens the asset directly. The parts after it are a labeled thumbnail of each generated image — look at them; the JSON alone does not tell you what was drawn.

Multi-output models (layerize-class: decompose an input image into layers) add an assets array to that JSON — one entry per image, { index, uri, httpUrl, mimeType, bytes }, in stack order (residual background first, then cutout layers). The top-level fields mirror assets[0]. Single-output results carry no assets array. Any non-image output the model produced is passed through VERBATIM under metadata — read it, it binds semantics to the assets (layerize, for example, ships a layers list in assets order with names, z order and bounding boxes in source pixels; cutouts are cropped to content, so place them by their bounding box).

Requires a free IMG.LY sign-in (the login tool); all other design tools work without an account.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNoModel id from the catalog (call with no arguments to list). Required to generate.
formatNoAspect ratio, e.g. "16:9" or "1:1".
promptNoWhat to generate. Required together with `model`.
image_urisNoworkspace:// image URIs used as inputs (image-to-image models).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

There are no annotations, so the description carries the full disclosure burden. It covers the no-argument catalog response, the structured first content part, durable workspace URIs, labeled thumbnails, multi-output assets in stack order, verbatim metadata, and the sign-in requirement — substantially more behavioral context than basic operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but warranted by the tool's complexity: invocation pattern, output format, multi-output behavior, and auth are each in their own focused segment. It is front-loaded with the core generation purpose and every sentence adds necessary routing or output semantics.

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?

With no output schema and no annotations, this definition covers what an agent needs to call the tool correctly: how to discover models, required parameters, optional format, image inputs, return-content structure, multi-output semantics, and the login prerequisite. Nothing essential 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, but the description adds meaningful operational meaning: model requires first listing the catalog, prompt pairs with model, format is an optional aspect such as 16:9, and image_uris come from import or earlier generations as workspace URIs. This goes beyond the schema's brief parameter descriptions.

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 opens with a specific action and resource: 'Generate images (text-to-image, image-to-image) via the IMG.LY AI gateway.' It further distinguishes generation from siblings by describing the no-argument catalog workflow and noting that generation requires login while 'all other design tools work without an account.'

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?

It gives explicit invocation guidance: 'Call with NO arguments first,' then call again with model and prompt, and for image-to-image pass image_uris. It also states the login prerequisite, but it does not explicitly name a when-not-to-use alternative or contrast with sibling tools such as edit or import beyond the mention of embedding URIs in subsequent edit calls.

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

Deploy Server

Other Tools