Skip to main content
Glama

Generate Image

xbrush_image_generate

Generate images from text prompts with XBrush AI models. Submit an async request and poll the returned ID to fetch your generated images.

Instructions

Generate images from a text prompt using XBrush AI models. Submits async — poll the returned request_id with xbrush_get_request.

Args: model (string, required): Model ID (e.g. z-image-turbo). Use xbrush_list_models to see options. prompt (string, required): Text description of the image. n (int, optional): Number of images (1-8). Default: 1. negative_prompt (string, optional): Elements to exclude. width (int, optional): Width in pixels (256-4096). Megapixel-based models (flux., z-image-turbo, ...) use it directly (default 1024). Resolution-based models ignore it UNLESS aspect_ratio:"custom" (see aspect_ratio). height (int, optional): Height in pixels (256-4096). Same rules as width. resolution (string, optional): Resolution tier for resolution-based models (gpt-image-2, seedream-, nano-banana-pro/2), e.g. "1K"/"2K"/"4K". aspect_ratio (string, optional): Aspect ratio for resolution-based models. gpt-image-2/-edit: 1:1, 3:2, 2:3, 4:3, 3:4, 4:5, 16:9, 9:16, 21:9, 1.91:1 (1K/2K); only 16:9/9:16/21:9/1.91:1 at 4K. Special value "custom": gpt-image-2/-edit output the exact width×height you pass (both required; each a multiple of 16, longest edge ≤3840, total pixels 655,360–8,294,400) — e.g. width:1024,height:1152,aspect_ratio:"custom" returns 1024×1152. quality (string, optional): low/medium/high — gpt-image-2/-edit only. seed (int, optional): Random seed for reproducibility.

Note: resolution-based models (gpt-image-2, seedream-*, nano-banana-pro/2) ignore width/height — passing them returns an error. Exception: aspect_ratio:"custom" with width+height yields an EXACT pixel size on gpt-image-2/-edit (other resolution models may only keep the ratio or ignore it).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nNoNumber of images to generate (1-8). Default: 1.
seedNoRandom seed for reproducible results.
modelYesImage model to use (e.g. z-image-turbo, flux.2-pro, seedream-5.0-pro, nano-banana-pro). Use xbrush_list_models to see available models.
widthNoOutput width in pixels (256-4096) for megapixel-based models (flux.*, z-image-turbo, etc.). Default: 1024. Resolution-based models (gpt-image-2, seedream-*, nano-banana-*) normally ignore it — but with aspect_ratio:"custom", gpt-image-2/-edit output exactly width×height (both required).
heightNoOutput height in pixels (256-4096) for megapixel-based models. Default: 1024. Resolution-based models ignore it unless aspect_ratio:"custom" (see width).
promptYesText description of the image to generate.
qualityNoOutput quality tier. Applies to byResolutionAndQuality models (gpt-image-2/-edit); higher = better and more expensive. Server default is high if omitted.
resolutionNoOutput resolution tier for resolution-based models (gpt-image-2, seedream-*, nano-banana-pro/2). Examples: "1K", "2K", "4K". Ignored by megapixel-based models — use width/height for those.
aspect_ratioNoAspect ratio for resolution-based models (e.g. "16:9"). gpt-image-2/-edit support 1:1, 3:2, 2:3, 4:3, 3:4, 4:5, 16:9, 9:16, 21:9, 1.91:1 at 1K/2K — at 4K only 16:9, 9:16, 21:9, 1.91:1. Special value "custom" makes gpt-image-2/-edit use width×height as the exact output size (both required, each a multiple of 16, longest edge ≤3840, total pixels 655,360–8,294,400; missing dimensions or out-of-range values return 400). seedream-* / nano-banana-* accept their own sets; an unsupported value is rejected with the list of allowed ratios.
negative_promptNoElements to exclude from the generated image.
Behavior5/5

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

The description discloses the asynchronous submission behavior, the need to poll the returned request_id, and detailed model-specific behaviors including error conditions ('passing them returns an error') and the exact-size exception for aspect_ratio:'custom'. Annotations provide only basic hints (readOnlyHint=false, etc.), so this context is valuable beyond what annotations offer.

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?

The description is front-loaded with a clear one-line purpose, followed by an async note and a structured argument list. It is long but every section covers distinct parameter semantics or model-specific interactions; the bullet list improves scannability. Minor redundancy with schema descriptions keeps it from being maximally concise.

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 10-parameter tool with no output schema, the description covers all arguments, model families, default behavior, error conditions, and the follow-up polling mechanism via xbrush_get_request. It also provides concrete examples for the most complex parameter (aspect_ratio), making it exceptionally complete for correct invocation.

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?

Although the schema covers 100% of parameters, the description adds meaningful semantics by grouping models into megapixel-based vs resolution-based, clarifying which parameters apply to which model types, and explaining the special 'custom' aspect_ratio behavior with a concrete example. This substantially aids correct parameter selection beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Generate images from a text prompt using XBrush AI models,' clearly identifying the operation and resource. However, it does not explicitly differentiate from siblings like xbrush_image_edit or xbrush_image_upscale, relying on the tool name and phrase 'from a text prompt' for implicit distinction.

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?

The description provides context (text-to-image generation, async flow with xbrush_get_request) and points to xbrush_list_models for model selection, but it never states when to prefer this tool over alternatives or when not to use it. Usage is implied rather than explicitly guided.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lweight/xbrush-api-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server