aicut

Make a video from a niche

generate_from_niche

Destructive

Runs ONE niche on the signed-in account: starts the video, puts the aicut card in front of the user and returns the new job's id immediately. It does NOT wait for the video. WHEN: the user wants one of the formats list_niches lists. Read that niche in full first: slug and revision come from it, values answer its text and select inputs by key, media fills its image inputs. A setting you leave out is the niche's default. 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: a video takes 1-3 minutes, up to about 6: do not assume it failed before then. COST: this spends the user's tokens. A 409 revision_changed means the niche or its price moved: read it again and ask again at the new price. 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). The flow: get_recipe niche-run.

Input Schema

Name	Required	Description
`slug`	Yes	The niche's `slug`, from `list_niches`.
`audio`	No	Sound on the video, where `settings.options.audio_selectable` is true. Only if the user asked; never to save tokens, never carried over.
`media`	No	One entry per picked image.
`model`	No	A `settings.options.models` value. Only if the user asked; never to save tokens, never carried over.
`values`	No	Answers to the text and select inputs, by input `key`: the user's own words, or a select's `options` value (own words only where `allow_custom`).
`revision`	Yes	The `revision` of the niche as you read it (`list_niches` with `slug`).
`resolution`	No	One of the niche's `settings.options.resolutions`; higher costs more. Only if the user asked; never to save tokens, never carried over.
`aspect_ratio`	No	A `settings.options.aspect_ratios` value. Only if the user asked; never to save tokens, never carried over.
`estimate_only`	No	Price only; creates nothing.
`idempotency_key`	No	Retry-safety key (IDEMPOTENCY).
`duration_seconds`	No	One of the niche's `settings.options.durations_seconds`; longer costs more. Only if the user asked; never to save tokens, never carried over.

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?

Despite annotations already covering mutation/open-world status, the description adds substantial behavior: immediate job-id return, card side effect, wait protocol, 1–3 minute timing, token spend, 409 revision-changed handling, and idempotency-key replay semantics.

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?

It is dense but front-loaded and deliberately structured with WHEN, THE CARD, WAIT, TIMING, COST, SPENDS TOKENS, and IDEMPOTENCY labels. For an 11-parameter costly generation tool, every section carries operational value.

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?

The description covers the full operational flow: preconditions, card behavior, asynchronous return, waiting rules, cost confirmation, revision conflicts, and idempotency. With no output schema, it still gives enough return-context by naming the job id and url fallback.

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 adds useful mapping semantics (slug/revision come from the niche, values answer inputs by key, media fills image inputs, omitted settings use defaults), but most field-level detail is already in the schema.

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 opening sentence states a specific verb and resource: run one niche, start a video, show the aicut card, and return the new job id immediately. It also explicitly states it does NOT wait, which distinguishes it from wait/polling siblings.

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?

It gives explicit WHEN guidance tied to `list_niches`, tells the agent to read the niche first, and routes follow-up behavior to `wait_for_generation` while forbidding `show_generation` and `get_*` polling for this flow. Alternatives and exclusions are both present.

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