aicut

Generate an AI image

generate_image

Destructive

Generates an AI image on the signed-in aicut account and puts the aicut card in front of the user. It waits for the image server-side for as long as one request safely can (about 24 seconds), so it usually returns the finished image with its url directly. WHEN: the user asks for an image. Call list_models first if you have not this session (an unpublished combination is rejected). get_recipe starter-image has the first-image steps. CONSENT: a real person's picture only with their permission, never a public figure or celebrity. AFTER: succeeded is finished; queued or processing was not ready in time: wait_for_generation with the returned id and media: "image". THE CARD: this call already opened the aicut card: do not call show_generation for this job. WAIT: wait_for_generation (this id, media), again at once while terminal: false, then one short line; no get_* polling, timers, background shells or narrating the wait. No card? Give the user the url. TIMING: an image usually finishes in under 90 seconds and can take up to about 4 minutes; this call waits about 24 seconds for it itself. COST: this spends the user's tokens. SPENDS TOKENS: price with estimate_only: true, ask in the SAME message as the price, and wait for a go that names THIS purchase (SPENDING RULES, this server's instructions). IDEMPOTENCY: a reused idempotency_key REPLAYS the first job whatever the settings: never reuse one for a new generation (this server's instructions).

Input Schema

Name	Required	Description
`wait`	No	`false` returns the job id at once (no wait of about 24 seconds): for several images, start them all, then ONE `wait_for_generation` with `ids`. Default true.
`model`	Yes	Model id exactly as `list_models` returns it (for example `gpt-image-2.5`). The user's pick, else the one `list_models` marks `recommended`; never a cheaper one to save them tokens.
`images`	No	Input image URLs to edit or use as references, on the models that accept them: public https URLs (aicut fetches and stores them) or earlier generations' URLs on this account.
`prompt`	No	What the image should show. The model's `prompt` parameter in `list_models` gives its character limit.
`quality`	No	Quality tier, on the models that publish a `quality` parameter; higher costs more. Only if the user asked; never to save tokens, never carried over.
`resolution`	No	One of the model's published options (for example `1k`); higher costs more. Only if the user asked; never to save tokens, never carried over.
`aspect_ratio`	No	One of the model's published `aspect_ratios` (for example `9:16`).
`estimate_only`	No	Price only; creates nothing.
`idempotency_key`	No	Retry-safety key (IDEMPOTENCY).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026

changedInput schema / properties / model / description

Previous value: -"Model id exactly as `list_models` returns it (for example `nano-banana-2`). Use the one the user asked for; never substitute a cheaper model to save them tokens."New value: +"Model id exactly as `list_models` returns it (for example `gpt-image-2.5`). The user's pick, else the one `list_models` marks `recommended`; never a cheaper one to save them tokens."

First observedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: the ~24 second server-side wait and the fact a `url` is usually returned directly, the 90s–4min timing envelope, that tokens are spent and must be priced with `estimate_only: true` and consented to, and that a reused `idempotency_key` REPLAYS the first job regardless of settings. The destructive/openWorld/no-idempotency hints are all corroborated rather than contradicted, and the money-spend and idempotency-replay hazards are the exact context an agent needs.

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 verb, resource, and the ~24s wait behavior, and the labeled sections (WHEN, CONSENT, AFTER, THE CARD, WAIT, TIMING, COST) make it scannable. It is long for a tool description and has mild redundancy — "COST: this spends the user's tokens" is immediately restated by "SPENDS TOKENS," and the 24-second wait is repeated in TIMING — but the density is defensible for a costly, multi-param, card-managing operation.

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, the description supplies the return contract itself: `url`, `id`, and the `succeeded`/`queued`/`processing` status states plus what to do for each. For a 9-parameter, token-spending, destructive operation it also covers consent, cost, timing, and card state, leaving nothing an agent needs in order to call it and follow up correctly.

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; the description still earns a bump by explaining the batch `wait: false` pattern, that `model` must come from `list_models` (never a cheaper one), and the crucial replay semantics of `idempotency_key` that the schema only gestures at as "Retry-safety key." It does not add syntax detail for `resolution`/`quality`/`aspect_ratio` beyond what the schema already says.

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 ("Generates an AI image on the signed-in aicut account") plus the immediate user-visible side effect (the card is opened). It explicitly distinguishes this from the sibling it interacts with ("do not call `show_generation` for this job") and from `wait_for_generation`, so an agent can route correctly without opening other schemas.

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?

WHEN is stated (user asks for an image), with the prerequisite chain (`list_models` first, `get_recipe` starter-image) and the consent exclusion (real person only with permission, never a public figure). The AFTER/WAIT sections tell the agent exactly what to do for `succeeded` vs `queued`/`processing` and forbid `get_*` polling, timers, and background shells — explicit when/when-not with named alternatives.

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

All aicut tools Inspect

Try in Browser