aicut

Upscale an image

upscale_image

Destructive

Increases an existing image's resolution and returns the new job's id immediately (it does NOT wait). Same image, more pixels. WHEN: the user asks to upscale, enhance, sharpen or increase the resolution of a picture they have, including one an earlier generate_image returned. It is not how you change what is IN the picture (generate_image with the picture as a reference). WHICH MODEL (upscale_factor has each one's factors): topaz-upscale-image is the general-purpose safe default. seedvr-upscale-image is priced by the size of its output. recraft-creative-upscale-image decides its own output size and REPAINTS detail: a reinterpretation, not a faithful enlargement. Ask the user when the choice is not obvious. 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. COST: this spends the user's tokens, and the three models price differently. topaz-upscale-image: 0.32 tokens up to 24 megapixels of OUTPUT, 0.64 up to 48, 1.28 up to 96, 5.44 above that. seedvr-upscale-image: 0.025 tokens per output megapixel (a 1024x1024 picture at 4x is about 0.42). recraft-creative-upscale-image: a flat 1 token. The image's dimensions are MEASURED BY THE SERVER from the file, never taken from anything you say: that measurement is the price. PNG, JPEG and WebP are readable; anything else (AVIF, HEIC, TIFF, GIF), a picture below the model's minimum size or one whose result would exceed its output limit is REFUSED with nothing charged: re-encode to PNG or JPEG. The estimate_only quote is what the job charges. An external url costs one media-ingest slot: quote and create from the SAME url to pay it once. 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
`model`	Yes	Which upscaler. They differ in price by more than any other setting: use the one the user asked for. REQUIRED: if the user gave none, put your pick and its price in the priced ask; never one chosen to save tokens, never carried over.
`source_image`	Yes	URL of the image to upscale. A URL from this account's generations or uploads, or a public https URL (imported first); another account's is refused. A PHOTO FROM THE USER'S OWN MACHINE QUALIFIES: upload it first with `upload_media_widget` (or `upload_media` where no card renders) and pass the url `confirm_upload` returns.
`estimate_only`	No	Price only; creates nothing.
`upscale_factor`	No	Times larger. topaz: 1, 2 or 4; seedvr: any whole number 1 to 10; recraft takes NONE and REFUSES the request if you send one. Default 2 on the two that take it. A result over the model's output limit is refused before anything is charged. Only if the user asked; never to save tokens, never carried over.
`idempotency_key`	No	Retry-safety key (IDEMPOTENCY).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only say the call is write/not-idempotent/open-world/destructive; the description goes far beyond by disclosing the async job model, the fact that the card is already opened (so `show_generation` must be skipped), the exact wait loop via `wait_for_generation`, per-model token pricing, and server-side dimension measurement. It also documents refusal behavior (unsupported formats, minimum size, output-limit overflow) with nothing charged, which is the mutation-risk context the destructiveHint alone cannot convey.

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 lead sentence front-loads the two facts an agent needs most (what it does, that it does not wait), and labelled sections (WHEN, WHICH MODEL, WAIT, COST, IDEMPOTENCY) make it skimmable. It is dense and heavily capitalized, and the cost/wait/idempotency material could be tightened, but almost every sentence carries operational weight.

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 5-parameter, no-output-schema, token-spending async job, nothing an agent needs is missing: pricing tiers, format support, refusal conditions, the estimate-only quote path, the shared-url ingest-slot caveat, and idempotency replay semantics are all stated. No contradiction with the annotations (`idempotentHint: false` describes the operation, while the `idempotency_key` replay note describes an explicit opt-in guard).

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?

Schema coverage is 100%, so baseline would be 3, but the description adds real decision value: it explains why `model` dominates cost, warns that `recraft-creative-upscale-image` repaints detail and refuses `upscale_factor` entirely, and states that dimensions are measured by the server rather than supplied. That is meaning the schema does not carry.

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?

"Increases an existing image's resolution and returns the new job's id immediately" names a specific verb and resource and states the async return contract. It also explicitly separates itself from `generate_image` ("It is not how you change what is IN the picture"), so an agent can route between the two without opening either schema.

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?

The WHEN block gives concrete trigger phrases (upscale, enhance, sharpen, increase resolution) and the negative case (content changes belong to `generate_image` with a reference). Per-model guidance plus "Ask the user when the choice is not obvious" and the mandatory estimate-then-confirm flow cover when-to-use and when-to-stop-and-ask fully.

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