Generate game assets with AI: sprites, 3D models, animations, sound effects, music, and voices.
Scored across 35 tools
Most tools target distinct asset types and actions, with detailed descriptions and cross-references separating generation from editing and animation. Mild overlap exists between animateSprite and animateSpriteKeyframes, which can both handle start/end frame animation, but the descriptions make the intended use clear.
Names consistently use a verb-first lowerCamelCase pattern such as create*, edit*, list*, get*, and animate*. A few compound names like animateSpriteKeyframes, createVideoFromReferences, and animate3DModelPreset deviate slightly, but the pattern remains predictable and readable.
At 35 tools, the set exceeds the 25+ threshold and feels heavy even for a broad game-asset generation platform. While the multimodal scope justifies many tools, there are several near-variant generation endpoints plus discovery and admin utilities that increase navigation burden.
The server covers the full asset pipeline well: image, sprite, 3D, audio, video generation, editing, animation, job polling, account lookup, and documentation. Minor gaps remain, such as no text-to-3D generation, no asset deletion, and no in-server mechanism to combine a rigged model with a generated animation clip.
Generate text-driven skeletal animations for an already-rigged 3D model. Pass the rigged GLB in model (URL or base64; the 3D asset file, not an AI model name) and a motion prompt (e.g. "walking", "swinging its axe"). The model must already have a skeleton - rig it first with rigModel if not. The job result is num_variants candidate animations (default 4), each a standalone animation-only GLB (skeleton + one clip, no mesh) in glb_url plus an mp4 preview_url, so you can pick the best one and fuse it with your model in a game engine or three.js. mode selects the representation - rot_trans (default, rotation plus translation per bone, most faithful) or rot_only (rotation only, easier to retarget onto another skeleton in an engine). Animation quality is hit-or-miss, which is why multiple candidates are returned. Credits are held once per call regardless of variant count and refunded if the job fails or is cancelled. Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: This endpoint consumes 0.2 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full behavioral burden, and it delivers: it discloses that this is an async generation job returning {id, status}, that credits are held once and refunded on failure/cancellation, that quality is hit-or-miss, and that results are standalone animation-only GLBs with mp4 previews. It also explains the mode trade-off and output shape, which is far beyond what structured annotations would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but long, packing many necessary operational details into a few sentences. It is front-loaded with the core purpose and then moves through input, output, mode, quality, and credits. It is arguably slightly verbose, but each sentence earns its place given the asynchronous, credit-bearing, multi-variant behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no output schema, the description explains the job lifecycle, the poll target, the output artifact shape, and the credit contract. It even warns about unreliable animation quality and points to server instructions for the job/credit contract. Nothing critical for selecting and invoking this tool is missing, though exact response fields could always be more exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The top-level parameter has no schema description, so the description adds essential meaning: it clarifies `model` as a URL or base64 GLB, clarifies `mode` as rot_trans vs rot_only with retargeting implications, and explains `num_variants` as producing one candidate per variant. It does not cover `loop`, `augment_prompt`, or `request_id`, though those do have their own nested schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Generate text-driven skeletal animations for an already-rigged 3D model.' It also differentiates from siblings by naming rigModel for the rigging prerequisite and clarifying that `model` is a 3D asset file, not an AI model name. The purpose is unmistakable and distinct from animate3DModelPreset, animateSprite, and transferMotion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool: for an already-rigged model with a motion prompt, and explicitly says to rig first with rigModel if there is no skeleton. It also clarifies the model input format with an exclusion ('not an AI model name'). It does not explicitly contrast this with animate3DModelPreset or listAnimationPresets, so it stops short of a full when/when-not matrix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a curated animation preset to an already-rigged 3D model (retargeting). Pass the rigged GLB in model (URL or base64; the 3D asset file, not an AI model name) and a preset_id from the animation presets list (from listAnimationPresets) - only presets that expose a clip_url can be applied to a 3D model. The model must have a humanoid-template rig (rig it with rig_type humanoid_template or humanoid_template_hands). The job result is one retargeted animation - a standalone animation-only GLB in glb_url plus an mp4 preview_url - in the same animations envelope as the animate endpoint. crop_loop trims the clip to its seamlessly-looping span (omit to follow the preset's own loop flag); in_place removes net travel so the character moves on the spot, as game-engine locomotion expects (omit to keep the preset's own travel). Credits are held when the job is accepted and refunded if it fails or is cancelled. Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: This endpoint consumes 0.2 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the async job shape, polling via getApiJob, the exact output envelope, option effects, credit hold/refund behavior, and per-call cost. This is substantially more behavioral context than most tool descriptions provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
All sentences are information-dense and the purpose is front-loaded; the structure is a single paragraph rather than bullets, but every statement earns its place. It is longer than usual because it must compensate for low schema coverage and missing annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex async generation tool with no output schema and no annotations, the description covers prerequisites, input constraints, output, option semantics, polling, and credit contract. An agent has enough information to select and invoke the tool correctly without opening sibling schemas.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds key semantics beyond the schema: model must be a URL or base64 GLB, preset_id must come from listAnimationPresets and expose a clip_url, and it explains the meaning and omission behavior of crop_loop and in_place. It does not describe request_id, though that parameter is optional and self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: applying a curated animation preset to an already-rigged 3D model via retargeting. It also distinguishes this from other animation tools by requiring a preset_id from listAnimationPresets and by clarifying that model is a GLB asset, not an AI model name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear prerequisites: the model must already have a humanoid-template rig, and only presets exposing a clip_url are eligible. It names the presets source and the polling tool, but it does not explicitly contrast with animate3DModel or provide a when-not-to-use exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Animate a static sprite into a spritesheet driven by a motion text prompt (image-to-spritesheet): supply an initial_image (URL or base64) plus a motion_prompt like "walking" or "attack slash", and optionally a final_image to interpolate between a start and end frame. Describe the motion exactly and unambiguously, but do not over-describe it: an action the model already knows is one phrase, not a sequence of steps, and the character, art style, background and camera come from the image, not the prompt. For animations driven by up to three keyframes (including a middle frame), use animateSpriteKeyframes instead. The job result is a single sprite result: spritesheet_url (the sheet image), video_url (an mp4 of the animation - pass it as video to transferMotion or as spritesheet_video_url to createSpriteAudio; editSpritesheet takes spritesheet_url), num_frames/num_cols/num_rows (the grid layout), and, when requested, gif_url, individual_frame_urls and spritesheet_with_background_url. The hydra model also returns audio_url, a sound effect for the animation - there is no need to call createSpriteAudio afterwards; forge and forge-pixel produce no audio. The chosen model must support sprite animation and the duration must be valid for it; incompatible model/duration combinations return HTTP 400. Credits are held when the job is accepted; the final charge is max(rate × produced seconds, the model's minimum charge), never more than for the duration you requested, and the difference (or everything, if the job fails or is cancelled) is refunded. Choosing a tool: animateSprite (this one) when you can describe the motion in text; transferMotion when you want an exact motion copied from a reference video or one of the named presets from listAnimationPresets (e.g. a standard walk or attack cycle); generatePose first when the source image is not yet in the pose the animation should start from. Omit model to run on hydra (the default) - see the model field for the per-model rates and the 4-credit minimum charge on forge/forge-pixel. Pass an optional request_id to tag the result so you can locate it later via listGenerations (type spritesheet). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: credits/s × seconds, per model: Hydra 3/s (shortest duration 3s, so 9 credits minimum), Forge 1.5/s (min charge 4 credits), Forge Pixel 1.5/s (min charge 4 credits), Blitz 1.9/s (min charge 4 credits) [LEGACY], Eagle 2.6/s (min charge 4 credits) [LEGACY], Eagle with Audio 3.1/s (min charge 4 credits) [LEGACY]; [LEGACY] models are scheduled for removal - do not use them for new work; see this endpoint's full pricing table in the API docs.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating an animated spritesheet from a static image. Input images can either be provided in base64 or URL. If the image was generated using Ludo, ideally it should be generated using the "sprite", "sprite-vfx" or "ui_asset" type. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it discloses async job returns, credit hold/refund semantics, HTTP 400 failures for incompatible model/duration pairs, model-specific audio behavior, and differences between negative phrasing across models. This goes well beyond what the schema alone conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded with the core instruction, then alternatives, result shape, and async/credit behavior. It is long, but the tool is complex enough to justify the length. Minor redundancy exists because the per-model pricing and legacy warnings are repeated in both the description and the model field schema description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema or annotations, the description fully equips an agent: it enumerates return fields (spritesheet_url, video_url, num_frames, gif_url, etc.), explains downstream tool consumption, describes async polling, documents error conditions, and gives credit model details. Nothing essential for correctly selecting and invoking the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter. The description still adds meaning by clarifying motion_prompt writing rules, the optional final_image interpolation behavior, the default model (hydra), and how to use request_id with listGenerations. It does not duplicate all parameter details, but the schema already covers those.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Animate a static sprite into a spritesheet driven by a motion text prompt (image-to-spritesheet)'. It clearly states the two required inputs and differentiates itself from animateSpriteKeyframes, transferMotion, and generatePose, so an agent can distinguish it from siblings without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit and actionable: use this tool when the motion can be described in text, transferMotion when copying motion from a reference video or preset, and generatePose first when the source image needs a different starting pose. It also explains the async pattern (poll getApiJob) and when createSpriteAudio is unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Animate a sprite through up to three fixed keyframes - initial_image, middle_image and final_image (each a URL or base64) - producing a spritesheet that interpolates through the provided frames in order. At least one of initial_image or middle_image is required (a final_image alone has nothing to anchor the animation); any keyframe may be omitted. The motion_prompt is optional here - when omitted, the motion is derived purely from the keyframes. Runs on hydra (default; also returns audio_url), forge, or forge-pixel for pixel-art sprites - the models that support a middle keyframe; any other model returns HTTP 400. For just a start and end frame, animateSprite with final_image does the same job. The job result is the same sprite result as animateSprite (spritesheet_url, video_url, grid fields, optional GIF and frame URLs, audio_url on hydra). Credits are held when the job is accepted; the final charge is max(rate × produced seconds, the model's minimum charge), never more than for the duration you requested, and the difference (or everything, if the job fails or is cancelled) is refunded. Use animateSprite instead for the classic single-image + text-prompt animation. Pass an optional request_id to tag the result so you can locate it later via listGenerations (type spritesheet). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: credits/s × seconds, per model: Hydra 3/s (shortest duration 3s, so 9 credits minimum), Forge 1.5/s (min charge 4 credits), Forge Pixel 1.5/s (min charge 4 credits); see this endpoint's full pricing table in the API docs.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating an animated spritesheet that interpolates through up to three fixed keyframes (initial / middle / final). Runs on hydra (default), forge or forge-pixel - the models supporting a middle keyframe. Input images can be provided in base64 or URL. At least one of initial_image or middle_image must be provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly covers async behavior ('returns {id, status} - poll getApiJob'), credit hold/refund mechanics, per-model pricing and minimum charges, model-specific limitations (negative phrasing only on hydra, audio_url on hydra), and the result structure. It even documents failure modes like HTTP 400 for unsupported models and augment_prompt/margin_ratio_mode conflicts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured, front-loading the core purpose and keyframe requirement before covering models, alternatives, results, and pricing. Each section adds distinct value, though some redundancy exists (e.g., mentioning animateSprite twice and repeating pricing). It is appropriately sized for the tool's complexity and avoids tangential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested requestBody, many parameters, async job, credit system, model variations) and the absence of an output schema, the description is remarkably complete. It covers the return fields ('spritesheet_url, video_url, grid fields, optional GIF and frame URLs, audio_url on hydra'), prerequisite conditions, model-specific behavior, and pricing details. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaningful guidance beyond the schema by explaining the keyframe anchoring requirement, providing detailed motion_prompt phrasing advice (e.g., 'Do not over-describe', negative phrasing warnings on forge/forge-pixel), and clarifying the interplay between augment_prompt and margin_ratio_mode. This is more than repetition of schema descriptions, though some redundant details exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Animate a sprite through up to three fixed keyframes... producing a spritesheet that interpolates through the provided frames in order.' It uses specific verbs and resources and explicitly differentiates from the sibling animateSprite tool, mentioning 'For just a start and end frame, animateSprite with final_image does the same job' and 'Use animateSprite instead for the classic single-image + text-prompt animation.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use and when-not-to-use guidance. It states the prerequisite ('At least one of initial_image or middle_image is required'), model constraints ('any other model returns HTTP 400'), and directly points to the alternative tool for simpler animations. It also clarifies the optional motion_prompt behavior and when to omit it. All usage conditions are clearly spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a queued job you started through the API or MCP; the credits held for it are refunded. Jobs that are already running cannot be canceled (409). Returns the canceled job. This is free (no credits).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses side effects (credits refunded), cost (free), a key error condition (running jobs return 409), and the return value (the canceled job). This is substantive and useful, though it omits details like ownership requirements or irreversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no wasted words. The main action is front-loaded, followed by the refund behavior, the running-job restriction, and the no-cost note. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter cancellation tool with no output schema, the description covers purpose, conditions, side effects, cost, and return value. It is reasonably complete, though it could have mentioned where to obtain the job id or how to verify a job is queued.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain what 'id' refers to beyond 'a job.' The single parameter id is left entirely to inference from the tool name. For a low-coverage schema, the description should clarify the id's source or format, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource ('Cancel a queued job') and explicitly ties the tool to jobs started through the API or MCP. It distinguishes itself from sibling tools like getApiJob and listApiJobs by focusing on the cancellation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit conditions: queued jobs can be canceled, running jobs cannot (409). It also notes the operation is free. However, it does not mention alternatives like checking status via getApiJob or listApiJobs first, so guidance is strong but not fully comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a single source image into a textured 3D model (image-to-3D). The job result is a downloadable GLB model_url plus an array of snapshot image URLs rendered from different angles (handy for previews). Accepts optional mesh controls: target_num_faces (max triangle count, 1000-200000, default 50000), texture_size (1024 or 2048, default 2048), and texture_type ("pbr", "simple", or "none", default "pbr"). Credits are held when the job is accepted and refunded if it fails or is cancelled. Pass an optional request_id to tag the result so you can locate it later via listGenerations (type 3d). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: This endpoint consumes 3 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses async execution, the initial `{id, status}` response, polling via getApiJob, credit holding/refunding behavior, the 3-credit cost, and the downloadable result format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose and result, then optional controls, credit implications, and response flow. Every sentence adds operational value, and no space is wasted on filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an async generation tool with no output schema and no annotations, this description is unusually complete. It covers inputs, options, outputs, credit semantics, result discoverability, and the polling contract, leaving an agent well equipped to invoke and monitor the job correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does. It explains each meaningful parameter: image source, target_num_faces with range and default, texture_size with accepted values, texture_type enum options, and request_id behavior including deduplication and listGenerations filtering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific, actionable purpose: 'Convert a single source image into a textured 3D model (image-to-3D)'. It names the output artifact (GLB plus preview snapshots) and is clearly distinguishable from sibling tools like animate3DModel, rigModel, and createImage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use case explicit: converting a single source image to a 3D model. It does not list alternative tools or exclusions, but the context is clear enough that an agent can decide when this tool is appropriate versus the 3D animation or rigging siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce a looping background ambiance soundscape from a text description, such as "windy forest at dusk" or "busy tavern interior". The job result is a single audio result containing a URL. The description field is required and duration is capped at 10 seconds (0 means auto-pick based on the description). Credits are held when the job is accepted and refunded if it fails or is cancelled. Use this for continuous, atmospheric background loops; use createSoundEffect for short discrete sound effects, createMusic for musical pieces, and createAudioTransform to remix an existing audio sample. Pass an optional request_id to tag the result so you can locate it later via listGenerations (type audio). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: This endpoint consumes 2 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating a seamless looping ambiance soundscape from a text description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does so thoroughly. It discloses async behavior (returns {id, status} and requires polling getApiJob), credit handling (credits held on acceptance, refunded on failure/cancellation, 2 credits per call), duration cap, and request_id idempotency semantics. These are genuine behavioral insights beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about six sentences and packs in purpose, constraints, credit behavior, sibling routing, request_id guidance, and async polling instructions. It is front-loaded with the core purpose and only slightly verbose in the closing credit note, which is acceptable given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex async generation tool with no output schema, the description covers everything an agent needs: what it generates, input requirements, duration cap, credit cost and refund policy, result shape, polling mechanism, idempotency, and sibling tool routing. No critical gap is apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter-level context beyond the schema: it restates that description is required, summarizes duration 0 as auto-pick, and notes request_id can be used to locate results via listGenerations. This is helpful but largely redundant with the detailed schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Produce a looping background ambiance soundscape from a text description,' with concrete examples. It also names sibling tools (createSoundEffect, createMusic, createAudioTransform) and explains what each is for, making the tool's distinct purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Use this for continuous, atmospheric background loops; use createSoundEffect for short discrete sound effects, createMusic for musical pieces, and createAudioTransform to remix an existing audio sample.' It also clarifies required inputs, duration limits, request_id tagging, and async polling, leaving little ambiguity about when and how to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remix an existing audio sample (a sound effect, ambiance, or music clip) into a variation guided by a text prompt, for example turning a track into an 80s synthwave or metal version. Both the sample and the prompt are required; the sample is uploaded as a URL or base64 audio and must be at most 15MB or the call returns HTTP 400, and duration must be one of the allowed values (0 means match the source, otherwise multiples of 10 up to 180 seconds). The job result is a single audio result containing a URL. The optional modification_strength (0 to 1, default 0.6) controls how far the result departs from the original. Credits are held when the job is accepted and refunded if it fails or is cancelled. Use this to transform existing audio you already have; use createSoundEffect, createAmbiance, or createMusic to generate audio from scratch. Pass an optional request_id to tag the result so you can locate it later via listGenerations (type audio). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: This endpoint consumes 3 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for remixing an audio sample (sound effect, ambiance or music) into a variation guided by a text prompt |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does so thoroughly. It discloses async behavior, the {id, status} return shape, polling via getApiJob, the single audio result with a URL, credit hold/refund behavior, the 3-credit cost, and the HTTP 400 condition for oversized samples.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, required inputs, size limit, duration rules, result format, strength parameter, credit behavior, sibling alternatives, request_id, and async polling. It is front-loaded with the core purpose and gives examples before practical constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description covers all essential operational context: async job lifecycle, polling endpoint, result contents, credit semantics, size limit, valid durations, required inputs, and how to locate the result via listGenerations. Nothing critical is missing for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some context beyond the schema, such as the HTTP 400 consequence for exceeding 15MB and the request_id link to listGenerations, but most parameter meaning is already present in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Remix an existing audio sample ... into a variation guided by a text prompt', with concrete examples like '80s synthwave or metal version'. It clearly distinguishes this from generate-from-scratch siblings by saying 'use createSoundEffect, createAmbiance, or createMusic to generate audio from scratch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Use this to transform existing audio you already have; use createSoundEffect, createAmbiance, or createMusic to generate audio from scratch.' It also states the required inputs (sample and prompt), the 15MB limit, and the async polling flow via getApiJob, so an agent knows exactly when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate game-art images from a text prompt alone, selecting an image_type (e.g. sprite) and optionally art_style, perspective, and aspect_ratio. The job result is an array of image results, each with a url; request n (1-8) to control how many variations come back. Because it generates purely from text it takes no source image, so there is no upload size limit to trip. Credits are held when the job is accepted and refunded if it fails or is cancelled; the charge scales with the number of images produced. Use createImage to make new images from scratch; use generateWithStyle to match a reference image's art style, editImage to modify an existing image, and removeBackground to cut out a subject. Pass an optional request_id to tag the results so you can retrieve them later via listGenerations (type image). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: This endpoint consumes 0.5 credits per result.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating an image from text prompt |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers comprehensively. It discloses the async nature (returns {id, status}, poll via getApiJob), the result format (array of urls), credit handling (held on acceptance, refunded on failure/cancel, scales with n), and the consequence of no source image (no upload size limit). These are behavioral traits an agent needs to manage the job correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized, front-loading the core purpose and required parameters before diving into edge cases, credits, and alternatives. It is a touch long, but every sentence adds value; the only minor structural quibble is that the credit note appears at the end rather than being integrated with the credit-holding sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex async API with credits, no output schema, and many options, the description is remarkably complete. It covers the call contract (required prompt and image_type), immediate return type, eventual result shape, polling endpoint, credit lifecycle, and retrieval by request_id. It even points to server instructions for the full job/credit contract, so an agent has everything needed to invoke and handle the job correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaningful behavioral context: it explains n controls the number of variations, request_id enables result retrieval via listGenerations, and mentions image_type as a required selector. While the schema already documents each parameter, the description clarifies the intent and downstream effects, going beyond raw schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Generate game-art images from a text prompt alone', clearly stating the verb, resource, and method. It explicitly distinguishes createImage from sibling tools by naming generateWithStyle, editImage, and removeBackground, so an agent can immediately tell when this tool is the right choice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: 'Use createImage to make new images from scratch; use generateWithStyle to match a reference image's art style, editImage to modify an existing image, and removeBackground to cut out a subject.' This covers when to use and when not to use, with named alternatives, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce a piece of music from a text description, such as "epic orchestral battle theme" or "calm piano melody", with optional lyrics. The job result is a single audio result containing a URL. The description field is required; duration must be one of the allowed values (0 means auto, otherwise multiples of 10 up to 180 seconds) and out-of-range values return HTTP 400. Credits are held when the job is accepted and refunded if it fails or is cancelled. Use this for songs and musical scores; use createSoundEffect for short sound effects, createAmbiance for looping background soundscapes, and createAudioTransform to remix an existing audio sample. Pass an optional request_id to tag the result so you can locate it later via listGenerations (type audio). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: This endpoint consumes 3 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating music from a text description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so thoroughly: async job with {id, status}, single audio URL result, credits held and refunded on failure/cancellation, 3 credits per call, HTTP 400 for out-of-range duration, and idempotent request_id behavior are all disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place. It front-loads the core purposecars, then covers routing, parameters, credits, and async behavior without fluff. The structured flow makes even the long detail easy to absorb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description is remarkably complete: it explains the result shape, how to poll, what errors occur, the credit contract, how to tag and locate jobs, and which sibling tools to use instead. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant meaning beyond the schema: the required description field, accepted duration behavior with 0 as auto, credit consequences, error behavior, and request_id tagging for later retrieval via listGenerations. This goes well beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "Produce a piece of music from a text description." It names concrete examples and explicitly says "Use this for songs and musical scores," clearly separating it from createSoundEffect, createAmbiance, and createAudioTransform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit routing guidance: "Use this for songs and musical scores; use createSoundEffect for short sound effects..." It also explains when to use request_id with listGenerations and how to poll with getApiJob, covering both selection and operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce a short sound effect (SFX) from a text description, such as "laser gun firing" or "footsteps on gravel". The job result is a single audio result containing a URL. The description field is required, duration is capped at 10 seconds (0 means auto-pick based on the description), and you may set loop to true for a seamlessly looping effect. Credits are held when the job is accepted and refunded if it fails or is cancelled. Use this for short, discrete sounds; use createAmbiance for a continuous looping background soundscape, createMusic for musical pieces, and createAudioTransform to remix an existing audio sample. Pass an optional request_id to tag the result so you can locate it later via listGenerations (type audio). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: This endpoint consumes 2 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating a sound effect from a text description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers: credit hold/refund behavior, 2-credit cost, async job returning {id, status}, polling via getApiJob, and a single audio result containing a URL. These behavioral details go well beyond what the schema alone provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but tightly organized: purpose first, then concrete constraints, sibling routing, async contract, and credit cost. Every sentence carries operational value and none merely repeat the tool name or schema verbatim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description supplies the essential execution context: async status shape, polling instruction, result form, credit contract, and when to choose sibling tools. An agent has enough information to invoke the tool and handle the follow-up correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the baseline is 3. The description adds useful cross-tool and behavioral semantics: duration 0 means auto-pick, loop creates a seamlessly looping effect, and request_id lets the agent locate results via listGenerations. It does not mention augment_prompt, but the schema fully documents that parameter, so the gap is minor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Produce a short sound effect (SFX) from a text description', with concrete examples like 'laser gun firing'. It also explicitly distinguishes itself from createAmbiance, createMusic, and createAudioTransform, making sibling differentiation clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use this for short, discrete sounds; use createAmbiance for a continuous looping background soundscape, createMusic for musical pieces, and createAudioTransform to remix an existing audio sample.' It also tells the agent to poll getApiJob for the async result, so the follow-up action is specified rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert text to speech by cloning the voice from an audio sample you provide (voice-cloning text-to-speech). Both text and sample are required; the text is limited to 1000 characters and the sample is supplied as a URL or base64 audio that must be at most 15MB, with violations returning HTTP 400. The job result is a single audio result containing a URL. Credits are held when the job is accepted and refunded if it fails or is cancelled. Use this when you have a reference voice sample to clone; use createSpeechPreset to speak with a built-in named preset voice instead, and createVoice to design a brand-new voice from a text description rather than cloning one. Pass an optional request_id to tag the result so you can locate it later via listGenerations (type audio). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: This endpoint consumes 1 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for text-to-speech generation using voice cloning |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals the async job lifecycle ({id, status}, poll getApiJob), credit hold/refund behavior, 1000-character and 15MB constraints, HTTP 400 on violations, and the single-audio-URL result format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but information-dense, front-loading the core operation before constraints, credits, alternatives, and async behavior. A small redundancy exists around credit consumption, but every other sentence contributes necessary guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and an async generation flow, the description is remarkably complete: it explains inputs, constraints, error behavior, credits, result shape, polling, and sibling routing. An agent has enough context to invoke and monitor the job correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all parameters, so the baseline is 3; the description adds meaningful extra semantics such as the 15MB sample limit, requiredness of both text and sample, HTTP 400 behavior, and request_id idempotency/lookup usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Convert text to speech by cloning the voice from an audio sample you provide.' It also distinguishes this tool from createSpeechPreset and createVoice, making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this when you have a reference voice sample to clone' and names the alternatives: createSpeechPreset for preset voices and createVoice for designing a voice from text. It also includes when to use request_id for lookup via listGenerations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert text to speech using a named built-in preset voice, with optional emotion and language settings. Both text and voice_preset_id are required and the text is limited to 1000 characters; invalid input returns HTTP 400. The job result is a single audio result containing a URL. Credits are held when the job is accepted and refunded if it fails or is cancelled. Use this when you want a ready-made catalog voice and do not need to supply your own sample; use createSpeech to clone a voice from an audio sample instead, and createVoice to design a new voice from a text description. Pass an optional request_id to tag the result so you can locate it later via listGenerations (type audio). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: This endpoint consumes 1 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for text-to-speech generation using a voice preset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the required inputs, 1000-character limit, HTTP 400 on invalid input, single audio URL result, credit hold/refund policy, and the async return shape of {id, status}. This goes well beyond a generic create statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized and front-loads the core purpose, then moves through constraints, results, credits, alternatives, and async behavior. It is longer than average but every sentence adds a meaningful detail, except for a slight redundancy in the final credits line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description covers the full invocation lifecycle: request requirements, error behavior, job result URL, credit contract, async polling via getApiJob, and how request_id relates to listGenerations. An agent has enough context to call and follow up correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it repeats requiredness, max length, and request_id usage, all already present in the parameter descriptions. No substantial new parameter meaning is introduced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Convert text to speech using a named built-in preset voice.' It also explicitly differentiates from siblings by naming createSpeech (clone from sample) and createVoice (design from description), so an agent can select the right one immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit when-to-use statement ('Use this when you want a ready-made catalog voice and do not need to supply your own sample') and names the alternatives with their conditions. It also directs the agent to poll getApiJob for async jobs, removing ambiguity about follow-up.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a sound effect for a previously generated spritesheet animation. Pass, as spritesheet_video_url, the video_url you received from animateSprite, animateSpriteKeyframes, transferMotion, or editSpritesheet - it must belong to a spritesheet you generated within the last 7 days; arbitrary external videos are not accepted. Spritesheets generated with the hydra model already come with audio_url, so only call this for forge / forge-pixel output or to replace hydra's sound. Optionally add a prompt describing the sound you want. The job result is the URL of the generated audio file only; no video is returned. The audio is also attached to the spritesheet, so it appears as audio_url in listGenerations (type spritesheet), where the spritesheet keeps the request_id it was generated with. Pass an optional request_id to make this call idempotent and to find its job again; it must not be one you already used for another generation. Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: This endpoint consumes 3 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating audio for a previously generated spritesheet animation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses async job behavior ({id, status}, poll getApiJob), return value (audio URL only, no video), side effect (audio attached as audio_url in listGenerations), idempotency semantics, the 7-day validity window, and credit cost of 3 credits per call. This is exemplary behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence carries operational information: purpose, provenance constraint, applicability, result shape, attachment behavior, idempotency, and cost. It is front-loaded with the core purpose and the most important constraint. It is longer than typical descriptions, but the length is justified by the tool's complexity and lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description fully covers what an agent needs to know: how to construct the call, what the job result will be, how to poll, what side effects occur, and what it costs. The only deferred item is the detailed job/credit contract, which is explicitly referenced in the server instructions rather than omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three nested properties at 100% coverage, so the baseline is 3. The description adds meaningful value beyond the schema by linking spritesheet_video_url to outputs of specific sibling tools, emphasizing the 7-day freshness requirement, and clarifying that request_id must not be reused for other generations. This extra context justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Generate a sound effect for a previously generated spritesheet animation.' It also distinguishes this from generic audio generation by requiring the spritesheet_video_url to come from specific sibling tools and by stating hydra spritesheets already have audio_url. This clearly separates it from siblings like createSoundEffect and createAmbiance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: only for forge/forge-pixel output or to replace hydra's sound, and only for spritesheets generated within the last 7 days. It also explicitly excludes arbitrary external videos. This is strong routing information that prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a short video clip from a source image and a motion text prompt (image-to-video); a source image is required - to make a video from text alone, first createImage and animate that, or use createVideoFromReferences with reference images. Griffin (default, 480p) and Griffin HD (720p) both generate a soundtrack; no separate audio step is needed. The job result is the video URL and its actual duration in seconds. Optionally pass final_image to interpolate between a start and end frame. The chosen model and duration must be compatible (incompatible combinations return HTTP 400); see the model and duration fields for the values each model accepts. Credits are held when the job is accepted; the final charge is max(rate × produced seconds, the model's minimum charge), never more than for the duration you requested, and the difference (or everything, if the job fails or is cancelled) is refunded. Pass an optional request_id to tag the result so you can locate it later via listGenerations (type video). Related tools: use createImage for static images, animateSprite for sprite-sheet animation, and listGenerations (type video) to list videos you generated earlier. Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: credits/s × seconds, per model: Griffin 1.5/s (shortest duration 5s, so 7.5 credits minimum), Griffin HD 2/s (shortest duration 5s, so 10 credits minimum), Blitz 1/s (shortest duration 2s, so 2 credits minimum) [LEGACY], Eagle 1.3/s [LEGACY], Eagle with Audio 1.8/s [LEGACY]; [LEGACY] models are scheduled for removal - do not use them for new work; see this endpoint's full pricing table in the API docs.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating a video from a source image and motion prompt |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and handles it well: it discloses async job behavior, polling via getApiJob, generation of a soundtrack, credit hold/refund semantics, model/duration compatibility errors, and legacy model removal status. This far exceeds the minimum needed for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but it is front-loaded with the core purpose and required input, and nearly every sentence carries operational value. It loses a point for density and some overlap with schema-level details, but it remains well-structured and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity — async generation, pricing, compatibility rules, and many sibling tools — the description is remarkably complete. It covers prerequisites, alternatives, return shape, job polling, refund behavior, and result lookup, so an agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 semantic context: it explains why model/duration compatibility matters, gives per-model credit costs, notes the effect of optional final_image interpolation, and clarifies request_id's role in locating results via listGenerations. It does not fully re-explain every parameter, but that is acceptable since the schema already covers them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Generate a short video clip from a source image and a motion text prompt (image-to-video)', and explicitly states that a source image is required. It also differentiates itself from siblings by naming createVideoFromReferences, createImage, and animateSprite as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: use this tool when you have a source image and motion prompt. It also tells the agent what to do for text-only video ('first createImage and animate that, or use createVideoFromReferences with reference images') and names related tools for static images and sprite animation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a video from 1-5 reference images and a text prompt (references-to-video). Unlike createVideo, which animates a single source image, this composes a new scene that borrows characters, objects, and style from the reference images. Each image can be a URL or base64. Griffin (default, 480p) and Griffin HD (720p) generate a soundtrack; note the per-second rate here is higher than createVideo's for the same model. The job result is the video URL and its actual duration in seconds. Choose the output shape with aspect_ratio ("default" lets the model decide). The chosen model and duration must be compatible (incompatible combinations return HTTP 400). Credits are held when the job is accepted; the final charge is max(rate × produced seconds, the model's minimum charge), never more than for the duration you requested, and the difference (or everything, if the job fails or is cancelled) is refunded. Pass an optional request_id to tag the result so you can locate it later via listGenerations (type video). Related tools: createVideo for image-to-video, editVideo to modify a generated video. Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: credits/s × seconds, per model: Griffin 2.5/s (shortest duration 5s, so 12.5 credits minimum), Griffin HD 4/s (shortest duration 5s, so 20 credits minimum), Eagle 1.5/s [LEGACY], Eagle with Audio 2/s [LEGACY]; [LEGACY] models are scheduled for removal - do not use them for new work; see this endpoint's full pricing table in the API docs.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating a video from 1-5 reference images and a text prompt. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers: it discloses async behavior ('returns {id, status} - poll getApiJob'), the credit hold/refund policy ('Credits are held when the job is accepted; the final charge is max(...), never more than... and the difference... is refunded'), model/duration incompatibility errors ('incompatible combinations return HTTP 400'), the soundtrack generation for Griffin models, and legacy deprecation ('do not use them for new work'). These are meaningful behavioral traits that structured annotations would normally provide, so the description compensates well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough and front-loaded with the main purpose and contrast, which is good, but it is verbose and contains redundancy with the schema. The pricing block at the end largely repeats the model enum descriptions in the schema, and phrases like 'Each image can be a URL or base64' are already in the images parameter description. Every sentence adds some value, but several could be trimmed without loss, making it less concise than ideal for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core workflow (async job, polling, result format), credit handling, compatibility constraints, legacy deprecation, related tools, and return details. There is no output schema, so explaining 'The job result is the video URL and its actual duration in seconds' is essential and included. It does not enumerate all possible error conditions beyond HTTP 400, but it gives enough for an agent to use the tool correctly. Given the tool's complexity and absence of annotations, this is a high but not perfect level of completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds value beyond the schema. It explains the credit implications of model selection ('per-second rate here is higher than createVideo's for the same model') and details the pricing per model, which helps agents pick a cost-effective option. It also clarifies how request_id can be used to locate results via listGenerations, which is not fully spelled out in the schema. While the schema already documents each parameter's meaning, the description enriches the model and request_id semantics enough to justify a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Generate a video from 1-5 reference images and a text prompt (references-to-video).' It goes beyond a simple restatement by explicitly differentiating from the sibling tool: 'Unlike createVideo, which animates a single source image, this composes a new scene that borrows characters, objects, and style from the reference images.' An agent can immediately distinguish this tool from createVideo 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names the alternatives and the selection criterion: 'Related tools: `createVideo` for image-to-video, `editVideo` to modify a generated video.' It also clarifies the boundary with 'Unlike createVideo, which animates a single source image...' and describes the async workflow, making it clear when to use this tool and how to follow up via getApiJob. This is explicit when/when-not guidance, not just implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Design a new voice from a character description (such as "deep-voiced warrior" or "cheerful young girl") and have it speak a short line of text, returning a sample of that newly created voice. Both voice_description and text are required, the spoken text is limited to 200 characters or the call returns HTTP 400, and type selects "human" or "non-human" voices. The job result is a single audio result containing a URL. Credits are held when the job is accepted and refunded if it fails or is cancelled. Use this to invent and audition a voice from a description; use createSpeech for text-to-speech that clones a specific voice from an audio sample, and createSpeechPreset for text-to-speech using a named preset voice. Pass an optional request_id to tag the result so you can locate it later via listGenerations (type audio). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: This endpoint consumes 1 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating a voice sample from a character description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden, and it delivers: async {id,status} response, polling via getApiJob, final audio result with URL, HTTP 400 on text over 200 characters, credit hold/refund behavior, 1-credit cost, and request_id idempotency. This is rich behavioral disclosure well beyond the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than minimal but densely packed; each section contributes purpose, alternatives, constraints, async contract, or credits. It is front-loaded with the main purpose and clearly structured. Minor redundancy and deferral to server instructions prevent a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex async job with no output schema, the description covers everything needed to invoke correctly: required inputs, initial response, polling route, final audio URL, credit semantics, and sibling selection. The pointer to server instructions for the full job/credit contract is acceptable given the amount already disclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by emphasizing voice_description and text are required, translating maxLength into a concrete HTTP 400 failure, explaining type's human/non-human selection, and connecting request_id to listGenerations. It does not mention augment_prompt, but the schema documents it thoroughly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb-resource pair ('Design a new voice from a character description') and adds the 'speak a short line of text, returning a sample' behavior. It explicitly contrasts itself with createSpeech and createSpeechPreset, so an agent can distinguish it from siblings without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit routing: 'Use this to invent and audition a voice from a description; use createSpeech for ... clone ... createSpeechPreset for ... named preset voice.' It also states required fields, the 200-character constraint, type selection, request_id tagging, and async polling, leaving no ambiguity about when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify an existing image according to text instructions: supply a source image (URL or base64) and a prompt describing the changes (e.g. "add clouds", "warmer color scheme"), with an optional reference_image for extra style or content guidance. The job result is an array of image results, each with a url; request n (1-4) to control the number of edited variations. Provided images are uploaded and validated, and any image larger than 15MB is rejected with HTTP 400. Credits are held when the job is accepted and refunded if it fails or is cancelled; the charge scales with the number of images produced. Use editImage to transform a specific existing image; use createImage to generate from text alone, generateWithStyle to borrow a reference's art style, and removeBackground for the dedicated background-removal case. Pass an optional request_id to tag the results so you can retrieve them later via listGenerations (type image). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: This endpoint consumes 0.5 credits per result.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for editing an existing image based on text instructions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the upload/validation process, 15MB limit with HTTP 400 error, credit holding/refunding mechanism, async job behavior, and polling via getApiJob. This goes far beyond what the schema conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive but somewhat extended, touching on many aspects including usage, credits, and async behavior. It is front-loaded with the core purpose and usage, and the additional details are relevant. However, it could be slightly trimmed to avoid verbosity, though the structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a complex tool with async behavior, credit implications, and multiple parameters. It covers the critical aspects: how to use, prerequisites, error conditions, credits, polling, and result format. Nothing an agent needs to invoke it correctly is missing, especially given the rich schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides detailed descriptions for most parameters (image, prompt, n, request_id, augment_prompt, reference_image), achieving 100% coverage. The description adds context on how reference_image affects style/content and how request_id can be used with listGenerations, but this is a minor enhancement over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Modify an existing image according to text instructions' with specific examples of prompts. It distinguishes itself from siblings by explicitly naming alternatives and when to use them, such as createImage for text-alone generation and removeBackground for background removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives, stating 'Use editImage to transform a specific existing image; use createImage to generate from text alone, generateWithStyle to borrow a reference's art style, and removeBackground for the dedicated background-removal case.' It also notes the async nature and polling requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit a previously generated spritesheet: re-prompt its underlying animation (edit_mode "prompt"), extend the frame beyond its borders ("outpaint"), or repair a bad loop ("fix_loop"). Pass the spritesheet_url you received from animateSprite, animateSpriteKeyframes, transferMotion, or an earlier edit - it must be a spritesheet you generated within the last 7 days; arbitrary external images are not accepted. Omit duration, frames, frame_size, crop and model to keep the source spritesheet's values. A prompt is required for edit_mode "prompt", optional for "outpaint", and not accepted for "fix_loop"; optionally add up to 5 reference images (URL or base64) to guide the edit. The job result is the same result shape as animateSprite (spritesheet URL, frame layout, optional GIF or individual frames). Credits are held when the job is accepted; the final charge is max(rate × produced seconds, the model's minimum charge), never more than for the duration you requested, and the difference (or everything, if the job fails or is cancelled) is refunded. Prompt edits are priced per model (credits/second × duration); "outpaint" and "fix_loop" run a lighter pipeline in which model is ignored and are billed at a flat 1 credit per second of the output duration (the source spritesheet's duration unless you pass one). Outpaint decides the extra margin itself - there is no amount parameter. The result carries the same fields as animateSprite (spritesheet_url, video_url, grid fields); audio is generated only by prompt edits on hydra, so a fix on a hydra sheet comes back without audio_url. Pass an optional request_id to tag the result for later retrieval via listGenerations (type spritesheet). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: edit_mode "fix_loop" / "outpaint": flat 1 credit per second of output, no minimum, model ignored; edit_mode "prompt": per model as listed - credits/s × seconds, per model: Hydra 3/s (shortest duration 3s, so 9 credits minimum), Forge 2/s (min charge 4 credits), Forge Pixel 2/s (min charge 4 credits); see this endpoint's full pricing table in the API docs.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for editing a previously generated spritesheet. edit_mode selects the operation - prompt-driven edit (default), outpaint, or loop fixing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It covers async job behavior (returns {id,status}, poll getApiJob), credit holding/refund logic, pricing per model and edit mode, output shape parity with animateSprite, audio generation constraints, and the fact that outpaint has no amount parameter. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely informative. It is structured with a clear opening statement, then progressive details about parameters, result shape, and pricing. Every sentence adds necessary information; there is no fluff. It could be slightly more concise, but the complexity of the tool justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the lack of an output schema, and the absence of annotations, the description covers everything an agent needs: exact edit modes, parameter semantics, pricing rules, async job handling, credit refund behavior, and the resulting data shape. No critical piece of information is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema documents every field (100% coverage), the description adds critical meaning beyond the schema: which parameters to omit to inherit source values, conditional requirements per edit_mode, the impact of model on pricing and behavior (ignored for outpaint/fix_loop), and the result-shape details. It also clarifies that reference images are optional and limited to 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb-resource statement ('Edit a previously generated spritesheet') and immediately enumerates the three edit modes (prompt, outpaint, fix_loop). It also differentiates from siblings by requiring a spritesheet_url generated by animateSprite, animateSpriteKeyframes, transferMotion, or an earlier edit, and explicitly excludes arbitrary external images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance for each edit mode, states required and optional parameters per mode (e.g., prompt is required for 'prompt', not accepted for 'fix_loop'), and instructs to omit certain parameters to preserve source values. It also warns about the 7-day validity of the source spritesheet and that external URLs are rejected, leaving no ambiguity about preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit a previously generated video with a text prompt and optional reference images (video-to-video); runs on griffin-hd (720p, with soundtrack) and the output keeps the source video's duration unless you pass one. Pass the video url you received from createVideo, createVideoFromReferences, or an earlier edit - it must be a video you generated within the last 7 days; arbitrary external videos are not accepted. Optionally add up to 5 reference images (URL or base64) to guide the edit. The job result is the new video URL and its actual duration in seconds. Credits are held when the job is accepted; the final charge is max(rate × produced seconds, the model's minimum charge), never more than for the duration you requested, and the difference (or everything, if the job fails or is cancelled) is refunded. Pass an optional request_id to tag the result so you can locate it later via listGenerations (type video). Related tools: createVideo to generate the source clip, createVideoFromReferences for reference-driven generation. Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: credits/s × seconds, per model: Griffin HD 2/s (shortest duration 5s, so 10 credits minimum), Eagle 2/s [LEGACY]; [LEGACY] models are scheduled for removal - do not use them for new work; see this endpoint's full pricing table in the API docs.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for editing a previously generated video with a text prompt and optional reference images. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, and it delivers richly: async job semantics (returns {id, status}, poll getApiJob), the credit hold/refund formula, duration behavior (keeps source duration unless overridden), model legacy warnings, and the output contract (new video URL + actual duration). This goes well beyond a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then input constraints, billing, async behavior, and related tools in a logical order. It is long, but nearly every sentence earns its place given the billing and async complexity; only mild redundancy with the schema's model descriptions keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with a nested request body, async execution, no output schema, and a credit system, the description covers the essential operational facts: how to source the video, how to poll, what the result contains, and the pricing contract. Minor gaps (error handling, job duration expectations) are deferred to the server instructions, which is a reasonable boundary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter already has rich per-property descriptions (model enum with credits, video 7-day constraint, images maxItems, request_id idempotency). The description adds modest extra meaning, e.g. that duration defaults to the source video's length and the credit charge formula, but the schema already carries most of the semantic load, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb + resource + manner: 'Edit a previously generated video with a text prompt and optional reference images (video-to-video)'. It clearly distinguishes from siblings by naming createVideo and createVideoFromReferences as source-generating tools and by the video-to-video framing, which separates it from editImage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: input must be a video generated within the last 7 days via createVideo, createVideoFromReferences, or a prior edit, and arbitrary external videos are rejected. It names related tools with their roles ('createVideo to generate the source clip, createVideoFromReferences for reference-driven generation'), giving the agent a clear routing decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-pose an existing sprite into a new target pose while preserving the character, taking a source image (URL or base64), a pose name (or "Other" with a free-text description), and an optional n (1-4) for how many variations to produce. Only works with sprite image types (not icons, screenshots, etc.). The job result is an array of pose results, each containing the generated image url, the pose and description used, and a suggested motion_prompt tuned for that pose. Credits are held when the job is accepted and refunded if it fails or is cancelled; the charge scales with the number of images generated. This is typically the first step before animating: call generatePose to set the character's pose, then feed the result (and its suggested motion_prompt) into animateSprite for the best animation quality; use rotateSprite instead when you want to change the camera angle rather than the pose. Pass an optional request_id to tag the results so you can locate them later via listGenerations (type spritesheet). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: This endpoint consumes 0.5 credits per result.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating a new pose for an existing sprite |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that this is an async job returning {id, status} requiring polling via getApiJob, describes the result array and motion_prompt field, explains credit holding/refund behavior, and states the per-result credit cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence carries operational value: input format, output shape, credit mechanics, workflow placement, request_id tagging, and async polling behavior. It is front-loaded with the core purpose and has no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity, no output schema, and no annotations, this description is remarkably complete. It covers inputs, output structure, async polling, credit contract, sibling routing, and type restrictions. An agent has enough context to invoke the tool and interpret the result without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds cross-parameter context beyond the schema by summarizing image as URL/base64, explaining the 'Other' pose with free-text description, and tying request_id to listGenerations with type spritesheet. It does not mention augment_prompt, but the schema already fully documents that parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Re-pose an existing sprite into a new target pose while preserving the character.' It also distinguishes itself from siblings by stating when to use animateSprite versus rotateSprite and explicitly restricting input to sprite image types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit workflow guidance: call generatePose first, then feed the result and suggested motion_prompt into animateSprite for best animation quality, and use rotateSprite instead when changing camera angle rather than pose. It also states a clear negative condition: only sprite image types, not icons or screenshots.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate new images that match the visual style of a reference image: supply a style_image (URL or base64) plus a text prompt describing what to create and an optional image_type (defaults to sprite). The job result is an array of image results, each with a url; request n (1-4) to control the number of variations. The style_image is uploaded and validated, and an image larger than 15MB is rejected with HTTP 400. Credits are held when the job is accepted and refunded if it fails or is cancelled; the charge scales with the number of images produced. Use this instead of createImage when style consistency with an existing asset matters; use editImage to alter the content of a specific image rather than borrow its style, and removeBackground to isolate a subject. Pass an optional request_id to tag the results so you can retrieve them later via listGenerations (type image). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: This endpoint consumes 0.5 credits per result.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for generating new content while maintaining the visual style of a reference image |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses upload/validation behavior, the 15MB rejection with HTTP 400, credit holding and refunds, scaling charges, idempotency via request_id, and the async job contract returning {id, status}. This is unusually transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, front-loading the core purpose and inputs before covering routing, behavior, credits, and retrieval. Every sentence adds relevant decision-making or invocation detail; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—style transfer, async execution, multiple parameters, credit implications, and result retrieval—the description covers all necessary context. It specifies the result shape, polling path, credit contract, and how to retrieve tagged results, so an agent has everything needed to invoke it correctly without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaningful context beyond the schema: it explains how n controls variation count, clarifies that style_image can be URL or base64, and identifies request_id as a way to tag results and retrieve them later via listGenerations. This exceeds the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Generate new images that match the visual style of a reference image.' It further names the exact inputs and sibling tools it is not (createImage, editImage, removeBackground), so an agent can distinguish it without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit routing guidance: 'Use this instead of createImage when style consistency with an existing asset matters; use editImage to alter the content of a specific image rather than borrow its style, and removeBackground to isolate a subject.' It also explains the async polling flow and credit lifecycle, clarifying when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show your account's credit balance, plan and auto top-up settings. credits.available is what generations can spend right now (plan_credits + extra - used); resets_at is when the plan's monthly credits refill (unix seconds). When team_pool is true the balance is your team's shared pool, and auto_topup is null because the team owner manages it. Check this before an expensive generation instead of waiting for a 402. Buying credits and changing auto top-up happen in the web app at billing_url. This is a free read-only lookup (no credits, no generation).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well: it states this is a 'free read-only lookup (no credits, no generation)' and explains team_pool and auto_topup null behavior, which is not inferable from the tool name or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense, leading with the core purpose and then adding only necessary details: field semantics, team-pool behavior, a direct usage trigger, and the billing URL. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and zero parameters, the description is remarkably complete: it explains return values, edge-case behavior, cost implications, and the correct workflow. An agent can safely invoke this tool without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters)Skip, so the description appropriately requires no parameter explanation. The baseline for a zero-parameter tool is 4, and the description does not need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Show') and resource ('your account's credit balance, plan and auto top-up settings'), and names the exact fields returned. It is clearly distinguishable from the generative sibling tools because it describes a read-only account lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use the tool: 'Check this before an expensive generation instead of waiting for a 402.' It also tells the agent when not to use it for billing actions, directing those to the web app at billing_url.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll the status of a generation job started by any tool. Every generation tool returns {id, status}; call getApiJob with that id until status is succeeded (then read result, shaped exactly like the tool's documented output) or failed (read error). Poll every few seconds, or pass wait: 30 to long-poll - the call is held up to 30 seconds (max 60) and returns as soon as the job finishes.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The job id returned by a generation call (its `id` in the 202 response). | |
| wait | No | Seconds to long-poll for a terminal state (0-60). Defaults to 0 (return immediately). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does it well: it reveals polling semantics, terminal states (succeeded/failed), result/error fields, blocking behavior up to wait seconds, and early return on completion. Minor omission: no mention of authentication, rate limits, or behavior for unknown ids, but core runtime behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler: action, workflow, and polling strategy are each front-loaded in their sentence. Every clause earns its place, and the parenthetical limits are efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema or annotations, the description explains the full call contract: when to poll, what statuses indicate completion, how to read result/error, and how long a wait may block. For a simple two-parameter polling tool, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so a baseline of 3 applies, but the description adds real value: it ties id to the id returned by generation calls and explains the wait parameter's long-polling effect and default return behavior. This exceeds the schema's bare parameter definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource pair, 'Poll the status of a generation job', and explains the job lifecycle with {id, status}. This clearly differentiates it from sibling tools like cancelApiJob and listApiJobs, which deal with cancellation and listing rather than status polling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to call this tool: after any generation tool returns {id, status}, poll until terminal. It also gives polling cadence and long-poll guidance. It does not explicitly contrast with siblings (e.g., when to prefer listApiJobs or cancelApiJob), but the intended usage is unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse or read Ludo's own documentation in full - how to choose a sprite animation mode, when to use Generate Before / Generate After, how margins behave, which model suits a job, and each generator's known limitations. To answer a specific question, call searchDocs first: it returns just the sections that match. Use getDocs to see what documentation exists, or to read a whole document or named sections. This is the same documentation the Ludo web app shows its users, so it occasionally describes buttons rather than parameters; the substance applies to the API and MCP surfaces just the same. To browse, call it with NO parameters to get a table of contents - every document with its id, label and section titles, and no bodies - then call it again with doc (and optionally sections) to read only what you need. Fetching a whole document can return tens of thousands of characters, so prefer naming the sections, using titles copied from the table of contents. Section titles match ignoring case, spacing and punctuation: when only some requested titles exist you receive those sections plus unmatched_sections and available_sections, and when none exist (or doc is unknown) the call returns 400 listing the valid values so you can retry once. This is a free discovery endpoint: it does not charge credits and does not queue a job.
| Name | Required | Description | Default |
|---|---|---|---|
| doc | No | Which document to read, by id (the table of contents returned by the no-parameter call lists them). Omit to receive the table of contents. | |
| sections | No | Section titles to return from `doc`, copied from the table of contents (an array of titles; over plain REST, a comma-separated string, where a title that itself contains a comma is still matched whole). Matching ignores case, spacing and punctuation; titles that match nothing are reported back in `unmatched_sections` rather than guessed at. Only valid together with `doc`. Omit to return every section of the document. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and executes excellently. It discloses the read-only and free nature ('does not charge credits and does not queue a job'), the exact response structure for the no-parameter call, partial-match behavior via 'unmatched_sections' and 'available_sections', the 400 error with valid values for retries, the case/spacing/punctuation-insensitive matching semantics, and the size warning about tens of thousands of characters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but dense, with every sentence earning its place: what the tool does, sibling differentiation, a content-parity caveat, the browse workflow, a size warning, matching/error semantics, and cost behavior. It is front-loaded with purpose before details, and the structure flows logically from overview to edge cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must explain return values, cost, and failure modes on its own — and it does. It covers the TOC structure (id, label, section titles, no bodies), partial and total failure responses, how to retry once, and the fact that this endpoint costs nothing and queues no job. An agent has everything needed to invoke it correctly across all edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 genuinely useful semantics beyond the schema: that the no-parameter call returns a table of contents listing document ids, that sections should be copied from that TOC, that sections is only valid together with doc, and the REST comma-separated string caveat. It also explains the fallback behavior when titles don't match, which the schema does not address.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Browse or read Ludo's own documentation in full' and enumerates concrete use cases. It explicitly distinguishes itself from the sibling searchDocs by contrasting behaviors ('To answer a specific question, call searchDocs first' vs 'Use getDocs to see what documentation exists, or to read a whole document or named sections').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance, naming the alternative tool and the condition that selects it: 'To answer a specific question, call searchDocs first'. It also provides a concrete invocation workflow (call with NO parameters for the table of contents, then re-call with doc/sections) and a practical rule about preferring named sections over whole-document fetches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the available animation presets along with their perspectives and the eight supported compass directions (N, NE, E, SE, S, SW, W, NW). Synchronous GET with no request body: it returns an animations array (each with id, name, category, description, duration, preview_url, and - when the preset can be retargeted onto a rigged 3D model - clip_url), a deduplicated perspectives array, and the directions list. This is a free discovery endpoint and does not charge credits. Use it to obtain the preset_id, perspective, and direction values that transferMotion needs, and to find motion preset names you can reference when animating; pair it with transferMotion (to apply a preset onto a sprite), animateSprite (text-prompt animation), or animate3DModelPreset (apply a clip_url-backed preset to a rigged 3D model).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it declares 'Synchronous GET with no request body,' itemizes the exact response structure (animations array with fields, deduplicated perspectives, directions list), explains the conditional clip_url field, and states 'does not charge credits.' This goes beyond minimal disclosure and directly answers likely agent questions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then gives response structure, then usage guidance. Every sentence adds value: purpose, response detail, and linkage to sibling tools. It is concise despite being detailed, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description provides a detailed enum of the response fields and the deduplication behavior, which is essential for an agent to parse the result. It also covers cost, call type, and usage examples, making it complete for a no-parameter discovery endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so there are no parameter semantics needed. The baseline for zero parameters is 4, and the description does not attempt to describe nonexistent parameters. It instead focuses on output and usage, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List the available animation presets along with their perspectives and the eight supported compass directions (N, NE, E, SE, S, SW, W, NW).' It clearly differentiates from sibling tools by naming transferMotion, animateSprite, and animate3DModelPreset as the tools that consume this data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'Use it to obtain the preset_id, perspective, and direction values that transferMotion needs, and to find motion preset names you can reference when animating.' It also names alternatives and pairing tools, and mentions the endpoint is free, providing a clear decision factor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the generation jobs you started through the API or MCP, most recent first. Web-app jobs are not included. This is a free read-only lookup (no credits, no generation). Filter with a comma-separated status list; limit defaults to 50 and is capped at 100.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of jobs to return. Defaults to 50, capped at 100. | |
| status | No | Comma-separated statuses to include (queued, running, succeeded, failed, canceled). Defaults to all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It explicitly says this is a 'free read-only lookup (no credits, no generation)', discloses ordering, defaults, and the limit cap. This is strong transparency for a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each earning its place: scope and ordering, safety and cost, then filtering and limit behavior. No filler or redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with two optional parameters and no output schema, the description covers everything needed: scope, order, exclusions, read-only nature, filter syntax, default limit, and cap. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description repeats the comma-separated status behavior and the 50/100 limit without adding new parameter-level meaning, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('generation jobs' started through API/MCP), and ordering ('most recent first'). It also excludes web-app jobs, which clearly distinguishes it from getApiJob and listGenerations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when the tool applies: listing API/MCP-started generation jobs, not web-app jobs. It does not explicitly name alternatives like getApiJob or listGenerations, but the scope is precise enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your generation history across the API and the web app - filter by type, source (api|web|all), text search, and date range. Returns {items, page, page_size, has_more}; keep paging while has_more is true. API-originated results expire after 7 days - download anything you want to retain. For an in-flight job's status use getApiJob instead.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Which kind of generation to list | |
| search | No | Free-text search. Every whitespace-separated term must match (case-insensitive substring) the item's tags or one of its text fields (prompt, hints, style, label, ...), so "dwarf axe" narrows to items matching both. | |
| source | No | Which surface the items were generated from: api (your API/MCP generations, last 7 days only), web (your Ludo web studio generations, no time limit), or all (default, both) Default: "all". | |
| date_to | No | Only return items generated at or before this time (unix seconds) | |
| date_from | No | Only return items generated at or after this time (unix seconds) | |
| page_size | No | Items per page (1-100) Default: 20. | |
| request_id | No | Only return items tagged with this request_id when you generated them | |
| page_number | No | 1-based page number Default: 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the pagination contract (has_more-driven paging), output shape, and the 7-day expiration of API-originated results. It does not mention sorting or error behavior, but the disclosed behaviors are substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Each sentence earns its place: scope/filters, pagination protocol, retention warning, and alternative routing. It is front-loaded with the core purpose and contains no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description tells the agent what the response looks like, how to page through results, that results may expire, and which sibling tool to use for a different need. That is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's first sentence summarizes filter capabilities but does not add meaning beyond the schema. The only meaningful extra information is the pagination/output shape, which is behavior rather than parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: listing generation history across API and web app. It also gives the exact filtering dimensions (type, source, text, date), making the tool's scope immediately identifiable and distinct from job-status tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly routes in-flight job status checks to getApiJob instead, and it warns that API-originated results expire after 7 days so the agent knows when to download. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove the background from a single image, returning the subject isolated on a transparent background. Supply the source image (URL or base64); optionally set crop to trim the result to the content, and creative_edit (default true) for higher-quality output that may not match the input pixel-for-pixel - set it false when the subject must stay pixel-identical, e.g. an existing sprite you will animate. The job result is a single image result with a url (not an array). The image is uploaded and validated, and an image larger than 15MB is rejected with HTTP 400. Credits are held when the job is accepted and refunded if it fails or is cancelled. Use removeBackground for this dedicated cutout task; editImage can also remove backgrounds via a prompt but is better for broader edits, while createImage and generateWithStyle produce new images rather than process an existing one. Pass an optional request_id to tag the result so you can retrieve it later via listGenerations (type image). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: This endpoint consumes 0.5 credits per result.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for removing the background of an image |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations or output schema, the description carries the full burden and fully delivers. It discloses async job behavior, polling via getApiJob, the single-image URL result, upload validation, a 15MB HTTP 400 rejection, credit holding/refunding, and the 0.5 credits per result cost. There is no contradiction with any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place: purpose, parameter guidance, output shape, error behavior, credit handling, sibling routing, and async polling. It is front-loaded with the core purpose and structured so an agent can quickly extract the key call semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested requestBody, async execution, no output schema, and no annotations, this description covers all essential operational details: how to supply the image, what the result looks like, how to retrieve it, failure behavior, and cost. Nothing critical for correct invocation is left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already documents all parameters at 100% coverage, the description adds meaningful guidance beyond the schema: creative_edit's pixel-identity tradeoff, request_id's role in retrieving results via listGenerations, and crop's trimming behavior. This gives the agent practical decision-making information rather than just schema repetition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Remove the background from a single image, returning the subject isolated on a transparent background.' It also explicitly contrasts this tool with editImage, createImage, and generateWithStyle, so an agent can distinguish it from relevant siblings without guessing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says 'Use removeBackground for this dedicated cutout task' and names editImage as the alternative for broader edits, plus createImage/generateWithStyle as generation-only tools. It also gives a concrete condition: set creative_edit false when the subject must stay pixel-identical, e.g., an existing sprite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rig a 3D model: generate a skeleton and skin weights for an existing GLB so it can be animated. Accepts a URL or base64-encoded GLB in model (here model is the 3D asset file, not an AI model name - there is no model choice on the 3D tools). The job result is a downloadable model_url for the rigged GLB. rig_type selects the skeleton prior - general (default, any asset), humanoid (anime-style characters), game (classic game-character rigs), or the pinned humanoid templates for two-armed, two-legged characters: humanoid_template (standard 22-joint skeleton with named joints, required for animating from the preset library) and humanoid_template_hands (52 joints, five fingers per hand). joint_naming relabels the identified joints to a convention - smpl (default), mixamo, humanik, unreal, godot, rigify, or vroid - without changing the skeleton. Credits are held when the job is accepted and refunded if it fails or is cancelled. Rigging is non-destructive to geometry but replaces any prior skeleton, so animations made against an old rig no longer apply. Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: This endpoint consumes 1 credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It discloses that rigging is non-destructive to geometry but replaces any prior skeleton, that animations made against an old rig no longer apply, that credits are held on acceptance and refunded on failure/cancellation, and that the job is async returning {id, status} with polling via getApiJob. It also explains that joint_naming is purely a relabel and does not change the skeleton. This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized, front-loading the core purpose and then covering behavior, parameters, and job semantics. It is longer than average, but every sentence earns its place given the tool's complexity and the absence of annotations. A slight deduction for the parenthetical density in the rig_type explanation, which could be tightened, but overall it is structured effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex async tool with no annotations and no output schema, the description is remarkably complete. It covers input format, rig type selection, joint naming, credit handling, non-destructive behavior, prior-skeleton replacement, and the async job contract with polling. An agent has everything needed to select and invoke this tool correctly, including the critical caveat about preset compatibility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the schema's lack of parameter documentation. It does so comprehensively: it explains that `model` is the 3D asset file (not an AI model name), details each rig_type option including joint counts and suitability (e.g., templates only suit two-armed, two-legged characters), and explains each joint_naming convention with examples. The description adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Rig a 3D model: generate a skeleton and skin weights for an existing GLB so it can be animated.' It clearly distinguishes this from sibling tools like animate3DModel (which animates rather than rigs) and create3DModel (which creates rather than rigs). The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool versus alternatives: it names animate3DModelPreset and states that humanoid_template (or humanoid_template_hands) is required for preset animation, while the default general rig cannot take presets. It also clarifies that the input is a 3D asset file, not an AI model name, and that there is no model choice on the 3D tools. This is strong routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-render an existing sprite from a different camera viewpoint while keeping the same character and pose, taking a source image (URL or base64), a required camera_rotation azimuth (one of 0, 45, 90, 135, 180, -135, -90, -45 degrees), an optional camera_elevation (0, 30, or 60 degrees; omit to keep the current elevation), and an optional n (1-4) for the number of variations. Only works with sprite image types (not icons, screenshots, etc.). The job result is an array of rotate-sprite results, each with the generated image url and the camera_rotation and camera_elevation that were applied. Credits are held when the job is accepted and refunded if it fails or is cancelled; the charge scales with the number of images generated. Use this to produce alternate view angles of a character; use generatePose instead to change the character's pose rather than the camera, and animateSprite or transferMotion to bring a sprite to life. Pass an optional request_id to tag the results so you can retrieve them later via listGenerations (type spritesheet). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: This endpoint consumes 0.5 credits per result.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for rotating the camera view of an existing sprite |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses async behavior (returns {id, status}, poll getApiJob), credit handling (held, refunded on failure/cancel, 0.5 credits per result), and output shape (array with url and applied angles). It also states the 'same character and pose' reuse and sprite-only limitation, which are behavioral traits not in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded with purpose and constraints before alternatives and job semantics. Most sentences add unique value, though the parameter summary partly repeats what the schema already documents. For a complex async tool with credit implications, this length is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully describes the return value, async polling, credit cost, and API contract link. It gives enough context to call safely and to select among 30 sibling tools, including the sprite-type limitation and alternative tool routing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaning beyond the schema: image as URL or base64, camera_elevation omitted preserves current, n sets variation count, and request_id enables retrieval via listGenerations. It doesn't substantially enrich every field, but it provides a useful summary that helps the agent select values confidently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Re-render an existing sprite from a different camera viewpoint while keeping the same character and pose.' It also names sibling alternatives (generatePose, animateSprite, transferMotion), so an agent can distinguish rotateSprite from nearby tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this to produce alternate view angles of a character' and tells when to use alternatives: 'use generatePose instead to change the character's pose..., and animateSprite or transferMotion to bring a sprite to life.' It also constrains input types to sprites only, reducing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Ludo's own documentation with a plain-language question and get back only the few sections that answer it - the fastest way to learn how a feature is meant to be used before you generate with it (how to pick a sprite animation mode or model, how margins behave, what something costs, known limitations). Start here rather than reading whole documents. Each result carries doc and section, which you can pass straight to getDocs to re-read that section, and the section's full markdown content. Results are best first; weak matches are left out, so an empty results list means the documentation does not cover the question - rephrase it, or call getDocs with no parameters to browse the table of contents. This is the same documentation the Ludo web app shows its users, so it occasionally describes buttons rather than parameters; the substance applies to the API and MCP surfaces just the same. Returns up to n sections (default 3, max 10). If it answers 503 the search backend is briefly unavailable: call getDocs instead rather than retrying in a loop. This is a free discovery endpoint: it does not charge credits and does not queue a job.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | Maximum number of sections to return. Defaults to 3. | |
| query | Yes | What you want to know, in plain language, e.g. "how do I keep a sprite animation's colors consistent" or "what does a 3D model cost". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and handles it thoroughly: weak matches are omitted, empty results mean the documentation doesn't cover the question, results include doc/section/full markdown, 503 means the backend is unavailable, and the endpoint is free and does not queue a job. It also flags that the docs occasionally describe buttons rather than parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but appropriately packed with necessary behavioral and fallback information. It is front-loaded with purpose and actionable guidance, though a few clauses are slightly redundant ('Start here rather than reading whole documents' restates the fastest-way point).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully explains return shape (doc, section, content), ordering, empty results, n defaults, and error fallback. An agent has everything needed to invoke the tool correctly and interpret the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces that query is a plain-language question and n caps the number of sections, but it does not add meaningful parameter semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search') and resource ('Ludo's own documentation'), and explains the search is question-driven and returns only the few sections that answer it. It clearly differentiates from getDocs by saying results carry doc/section identifiers to pass to getDocs for re-reading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent when to start here ('before you generate', 'Start here rather than reading whole documents') and what to do when results are empty or the backend returns 503, including naming getDocs as the fallback. This is direct and actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transfer motion from a reference video or a named animation preset onto a static sprite image, producing an animated spritesheet that mimics the reference movement. Provide the sprite as image (URL or base64) plus either a video URL or a preset_id together with perspective and direction (all three from listAnimationPresets; if both video and preset_id are sent the video wins). The job result is the same sprite result as animateSprite: spritesheet_url, video_url, grid fields, optional GIF / frame / with-background URLs, and audio_url when the model is hydra. duration defaults to 1.5s where the chosen model offers it, otherwise to that model's shortest (hydra, the default, starts at 3s) - and a longer reference clip or preset is compressed to fit, so pass the preset's own duration (returned by listAnimationPresets) to keep its timing. It returns HTTP 400 if neither a video nor a complete preset_id/perspective/direction triple is supplied, if the named preset, perspective, or direction cannot be resolved, or if the model/duration combination is invalid. Credits are held when the job is accepted; the final charge is max(rate × produced seconds, the model's minimum charge) - the produced length follows the reference clip - and the difference (or everything, if the job fails or is cancelled) is refunded. Use this when you have an existing motion clip or preset to copy; prefer animateSprite to generate animation purely from a text prompt. Omit model to run on hydra (the default - most capable, and returns audio); pick forge for a cheaper run on simple motion, presets and matching poses; the model field lists rates. Pass an optional request_id to tag the result so you can retrieve it later via listGenerations (type spritesheet). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: credits/s × seconds, per model: Hydra 3/s (shortest duration 3s, so 9 credits minimum), Forge 2/s (min charge 4 credits), Forge Pixel 2/s (min charge 4 credits), Tango 4/s (min charge 4 credits) [LEGACY]; [LEGACY] models are scheduled for removal - do not use them for new work; see this endpoint's full pricing table in the API docs.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for transferring motion from a video onto a static sprite image, producing an animated spritesheet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden and does so thoroughly. It discloses async job behavior, polling via getApiJob, HTTP 400 failure conditions, credit holding and refunds, duration compression, model defaults, and the shape of the result via the animateSprite reference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and well organized, but it is long and partly redundant with the input schema. The pricing and LEGACY table repeats information already present in the model field, and the duration rules are stated both in prose and in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description covers all essentials: input requirements, alternatives, result fields, async return shape, error conditions, credit implications, and model guidance. There is no missing context an agent would need to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 goes beyond the schema by clarifying mutual exclusivity of video versus preset triple, the video-wins rule, duration defaults tied to model capability, and request_id result tagging. These aggregates add real decision-making value beyond individual parameter docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb-resource pair: 'Transfer motion from a reference video or a named animation preset onto a static sprite image, producing an animated spritesheet.' It also contrasts with sibling tools by noting that text-prompt animation should go to animateSprite instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'Use this when you have an existing motion clip or preset to copy; prefer animateSprite to generate animation purely from a text prompt.' It also gives concrete selection rules for model choice and the video-vs-preset precedence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upscale a previously generated video to twice its resolution (2x). Pass the video url you received from createVideo, createVideoFromReferences, or editVideo - it must be a video you generated within the last 7 days; arbitrary external videos are not accepted. Both dimensions of the source must be under 960 pixels: griffin (480p) output qualifies; griffin-hd (720p) output does not, landscape or portrait (only a square 720x720 would) - generate on griffin if you intend to upscale. A too-large source fails the job and the held credits are refunded. The job result is the new video URL (2x width and height, same duration) and its duration in seconds. Billed per second of video, independent of model; held when the job is accepted and refunded if it fails or is cancelled. Pass an optional request_id to tag the result so you can locate it later via listGenerations (type video). Related tools: createVideo for image-to-video, editVideo to modify a generated video. Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).
Credits: 0.2 credits per second of video.
| Name | Required | Description | Default |
|---|---|---|---|
| requestBody | Yes | Payload for upscaling a previously generated video to twice its resolution. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are none, so description carries full burden. It discloses async behavior (returns {id, status}), polling via getApiJob, credit billing per second, refund on failure/cancellation, and the result format (new URL and duration). It mentions credit hold and refund policy. It doesn't detail error handling or retry behavior, but covers main behaviors. No contradictions with annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is thorough and well-organized, but somewhat dense and lengthy. It front-loads key info (upscale to 2x, use generated videos) but includes multiple clauses and parentheticals (e.g., 'landscape or portrait (only a square 720x720 would)') that could be simplified. Still, every sentence adds value, and it's not bloated with fluff. A 4 for efficient but slightly overloaded structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, description provides comprehensive context: input constraints, billing, async nature, polling method, result format, and relationship to siblings. It even includes credit cost (0.2 credits/sec). An agent has everything needed to call and interpret the tool correctly, including failure/refund behavior. Very complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds value by explaining the video parameter's constraints (7-day, model-specific) and the request_id semantics (idempotency, listGenerations filter). This goes beyond schema, but since schema already covers these, the addition is moderate, not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action ('upscale a previously generated video'), resource (video url), and specific effect (2x resolution). It explicitly differentiates from siblings by mentioning createVideo, editVideo, and related tools, and is specific about input constraints (7-day old, 480p vs 720p). No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: pass a URL from specific generation tools, ensure source is under 960 pixels, use griffin for generation if upscaling is intended. Clearly states what is NOT accepted (external videos, griffin-hd outputs except square). It doesn't explicitly list alternatives for when not to use, but it thoroughly covers conditions and prerequisites, making it easy for an agent to decide correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates an API key. Returns 200 if valid, 403 if invalid.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does disclose the success/error status codes, which is useful, but it fails to explain how the API key is supplied (since the schema has zero params) or mention any potential side effects. The 200/403 detail is valuable but the input mechanism remains opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one efficient sentence that conveys the core purpose and expected responses with zero waste. It is ideally concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no schema, annotations, or output schema, the description covers the essential purpose and responses. The only gap is the lack of explanation on how the API key is provided, but given the zero-parameter design, this is likely handled externally, making the description largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description identifies the subject (API key) but does not clarify how the key is transmitted, given the empty schema. However, since no parameters are expected, the description does not need to detail parameter values; still, a note about implicit authentication context would improve it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'validates' and the resource 'API key', clearly stating what the tool does. It also provides distinct status codes (200/403) that set it apart from sibling tools, which are all media-related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates this is for checking API key validity, but it does not explicitly state when to use it or mention any alternatives. Given that all sibling tools are unrelated, some contextual guidance on when to invoke validation would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
getAccountlistGenerations1 field changedInput schema / properties / source / descriptionPrevious value: -"Which surface the items were generated from: api (your API/MCP/CLI generations, last 7 days only), web (your Ludo web studio generations, no time limit), or all (default, both) Default: \"all\"."New value: +"Which surface the items were generated from: api (your API/MCP generations, last 7 days only), web (your Ludo web studio generations, no time limit), or all (default, both) Default: \"all\"."listGenerations1 field changedInput schema / properties / source / descriptionPrevious value: -"Which surface the items were generated from: api (your API/MCP generations, last 7 days only), web (your Ludo web studio generations, no time limit), or all (default, both) Default: \"all\"."New value: +"Which surface the items were generated from: api (your API/MCP/CLI generations, last 7 days only), web (your Ludo web studio generations, no time limit), or all (default, both) Default: \"all\"."animateSprite1 field changedInput schema / properties / requestBody / properties / motion_prompt / descriptionPrevious value: -"Text description of the desired animation (e.g., \"walking\", \"jumping\", \"idle breathing\", \"attack slash\")."New value: +"Text description of the desired animation, e.g. \"walking\", \"idle breathing\", \"attack slash\", \"casting a fireball with both hands\". Describe exactly and unambiguously what the character should do. Specific or complex actions are fine; there is no need to simplify them. Do not over-describe, though: too much detail can harm the animation, and an action the model already knows should be named, not decomposed into its steps (\"walking\", never \"move the left foot forward, then the right foot\"). Do not restate what initial_image already shows (the character, its appearance and equipment, the art style, the background, the lighting, the camera), and leave frame count and timing to the frames and duration fields. Negative phrasing (\"no background\", \"do not move the camera\", \"without a weapon\") works only on hydra. On forge, forge-pixel and the legacy models it backfires: naming something you do not want makes it more likely to appear, so \"without a weapon\" tends to produce a weapon. On those models never phrase anything negatively; state only what should happen, and control everything else through the image and the other fields."animateSpriteKeyframes1 field changedInput schema / properties / requestBody / properties / motion_prompt / descriptionPrevious value: -"Optional text description of the desired animation (e.g., \"walking\", \"attack slash\"). When omitted, the motion is derived purely from the keyframes."New value: +"Optional text description of the desired animation, e.g. \"walking\", \"attack slash\". When omitted, the motion is derived purely from the keyframes. When provided, describe exactly and unambiguously what the character should do. Specific or complex actions are fine; there is no need to simplify them. Do not over-describe, though: too much detail can harm the animation, and an action the model already knows should be named, not decomposed into its steps (\"walking\", never \"move the left foot forward, then the right foot\"). Do not restate what the keyframes already show (the character, its appearance and equipment, the art style, the background, the lighting, the camera), and leave frame count and timing to the frames and duration fields. Negative phrasing (\"no background\", \"do not move the camera\", \"without a weapon\") works only on hydra. On forge and forge-pixel it backfires: naming something you do not want makes it more likely to appear, so \"without a weapon\" tends to produce a weapon. On those models never phrase anything negatively; state only what should happen, and control everything else through the keyframes and the other fields."editSpritesheet1 field changedInput schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, shortest duration 3s, so 9 credits minimum · Most capable all-around model, generates audio\n- \"forge\" (Forge): 2 credits/s, min charge 4 credits · Cost-effective for simple editing tasks\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min charge 4 credits · Best for low-res pixel art animations Default: \"forge\"."New value: +"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, shortest duration 3s, so 9 credits minimum · Most capable all-around model, generates audio\n- \"forge\" (Forge): 2 credits/s, min charge 4 credits · Cost-effective for simple editing tasks\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min charge 4 credits · Best for low-res pixel art animations Default: \"hydra\"."transferMotion2 fields changedInput schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, shortest duration 3s, so 9 credits minimum · Most capable all-around model, generates audio\n- \"forge\" (Forge): 2 credits/s, min charge 4 credits · Cost-effective for simple motion. Works best with Presets and matching poses\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min charge 4 credits · Best for low-res pixel art animations\n- \"tango\" (Tango): 4 credits/s, min charge 4 credits · LEGACY - scheduled for removal, do not use for new work\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"forge\"."New value: +"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, shortest duration 3s, so 9 credits minimum · Most capable all-around model, generates audio\n- \"forge\" (Forge): 2 credits/s, min charge 4 credits · Cost-effective for simple motion. Works best with Presets and matching poses\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min charge 4 credits · Best for low-res pixel art animations\n- \"tango\" (Tango): 4 credits/s, min charge 4 credits · LEGACY - scheduled for removal, do not use for new work\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"hydra\"."Input schema / properties / requestBody / properties / model / examplePrevious value: -"forge"New value: +"hydra"animateSprite1 field changedInput schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, shortest duration 3s, so 9 credits minimum · Most capable model, generates audio\n- \"forge\" (Forge): 1.5 credits/s, min charge 4 credits · Best for basic animations and relatively simple sprites\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min charge 4 credits · Best for low-res pixel art animations\n- \"blitz\" (Blitz): 1.9 credits/s, min charge 4 credits · LEGACY - scheduled for removal, do not use for new work\n- \"eagle\" (Eagle): 2.6 credits/s, min charge 4 credits · LEGACY - scheduled for removal, do not use for new work\n- \"eagle-audio\" (Eagle with Audio): 3.1 credits/s, min charge 4 credits · LEGACY - scheduled for removal, do not use for new work\nLegacy aliases: \"standard\" → blitz.\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"hydra\"."New value: +"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, shortest duration 3s, so 9 credits minimum · Most capable all-around model, generates audio\n- \"forge\" (Forge): 1.5 credits/s, min charge 4 credits · Use only for basic animations and simple sprites. Multiple tries might be needed\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min charge 4 credits · Best for low-res pixel art animations\n- \"blitz\" (Blitz): 1.9 credits/s, min charge 4 credits · LEGACY - scheduled for removal, do not use for new work\n- \"eagle\" (Eagle): 2.6 credits/s, min charge 4 credits · LEGACY - scheduled for removal, do not use for new work\n- \"eagle-audio\" (Eagle with Audio): 3.1 credits/s, min charge 4 credits · LEGACY - scheduled for removal, do not use for new work\nLegacy aliases: \"standard\" → blitz.\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"hydra\"."animateSpriteKeyframes1 field changedInput schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, shortest duration 3s, so 9 credits minimum · Most capable model, generates audio\n- \"forge\" (Forge): 1.5 credits/s, min charge 4 credits · Best for basic animations and relatively simple sprites\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min charge 4 credits · Best for low-res pixel art animations Default: \"hydra\"."New value: +"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, shortest duration 3s, so 9 credits minimum · Most capable all-around model, generates audio\n- \"forge\" (Forge): 1.5 credits/s, min charge 4 credits · Use only for basic animations and simple sprites. Multiple tries might be needed\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min charge 4 credits · Best for low-res pixel art animations Default: \"hydra\"."editSpritesheet1 field changedInput schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, shortest duration 3s, so 9 credits minimum · Most capable model, generates audio\n- \"forge\" (Forge): 2 credits/s, min charge 4 credits · Cost-effective for simple editing tasks\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min charge 4 credits · Best for low-res pixel art animations Default: \"forge\"."New value: +"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, shortest duration 3s, so 9 credits minimum · Most capable all-around model, generates audio\n- \"forge\" (Forge): 2 credits/s, min charge 4 credits · Cost-effective for simple editing tasks\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min charge 4 credits · Best for low-res pixel art animations Default: \"forge\"."transferMotion1 field changedInput schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, shortest duration 3s, so 9 credits minimum · Most capable model, generates audio\n- \"forge\" (Forge): 2 credits/s, min charge 4 credits · Cost-effective for simple motion. Works best with Presets and matching poses\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min charge 4 credits · Best for low-res pixel art animations\n- \"tango\" (Tango): 4 credits/s, min charge 4 credits · LEGACY - scheduled for removal, do not use for new work\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"forge\"."New value: +"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, shortest duration 3s, so 9 credits minimum · Most capable all-around model, generates audio\n- \"forge\" (Forge): 2 credits/s, min charge 4 credits · Cost-effective for simple motion. Works best with Presets and matching poses\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min charge 4 credits · Best for low-res pixel art animations\n- \"tango\" (Tango): 4 credits/s, min charge 4 credits · LEGACY - scheduled for removal, do not use for new work\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"forge\"."animate3DModel2 fields changedInput schema / properties / requestBody / properties / model / descriptionPrevious value: -"URL or base64-encoded already-rigged GLB to animate. Rig it first via the rig endpoint if it has no skeleton."New value: +"The already-rigged 3D asset to animate, as a URL or base64-encoded GLB file (not an AI model name). Rig it first with rigModel if it has no skeleton."Input schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."animate3DModelPreset3 fields changedInput schema / properties / requestBody / properties / in_place / descriptionPrevious value: -"Remove the animation's net travel so the character moves on the spot (engine-driven locomotion). Omit to follow crop_loop."New value: +"Remove the animation's net travel so the character moves on the spot (engine-driven locomotion). Omit to keep the preset's own travel."Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"URL or base64-encoded already-rigged GLB (rig it with a humanoid_template rig_type first)."New value: +"The already-rigged 3D asset, as a URL or base64-encoded GLB file (not an AI model name). Rig it with rigModel using rig_type humanoid_template or humanoid_template_hands first."Input schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."animateSprite5 fields changedInput schema / properties / requestBody / properties / crop / descriptionPrevious value: -"Crop sprite frames to fit content. Results in smaller spritesheets but inconsistent frame sizes across different animations. Default: false."New value: +"Crop sprite frames to fit content. Results in smaller spritesheets but inconsistent frame sizes across different animations. Default: true."Input schema / properties / requestBody / properties / crop / examplePrevious value: -falseNew value: +trueInput schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s\n- \"forge\" (Forge): 1.5 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min 4\n- \"blitz\" (Blitz): 1.9 credits/s, min 4 · LEGACY - scheduled for removal, do not use for new work\n- \"eagle\" (Eagle): 2.6 credits/s, min 4 · LEGACY - scheduled for removal, do not use for new work\n- \"eagle-audio\" (Eagle with Audio): 3.1 credits/s, min 4 · LEGACY - scheduled for removal, do not use for new work\nLegacy aliases: \"standard\" → blitz.\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"blitz\"."New value: +"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, shortest duration 3s, so 9 credits minimum · Most capable model, generates audio\n- \"forge\" (Forge): 1.5 credits/s, min charge 4 credits · Best for basic animations and relatively simple sprites\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min charge 4 credits · Best for low-res pixel art animations\n- \"blitz\" (Blitz): 1.9 credits/s, min charge 4 credits · LEGACY - scheduled for removal, do not use for new work\n- \"eagle\" (Eagle): 2.6 credits/s, min charge 4 credits · LEGACY - scheduled for removal, do not use for new work\n- \"eagle-audio\" (Eagle with Audio): 3.1 credits/s, min charge 4 credits · LEGACY - scheduled for removal, do not use for new work\nLegacy aliases: \"standard\" → blitz.\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"hydra\"."Input schema / properties / requestBody / properties / model / examplePrevious value: -"blitz"New value: +"hydra"Input schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."animateSpriteKeyframes8 fields changedInput schema / properties / requestBody / descriptionPrevious value: -"Payload for generating an animated spritesheet that interpolates through up to three fixed keyframes (initial / middle / final). Runs on the Forge family - the only models supporting a middle keyframe. Input images can be provided in base64 or URL. At least one of initial_image or middle_image must be provided."New value: +"Payload for generating an animated spritesheet that interpolates through up to three fixed keyframes (initial / middle / final). Runs on hydra (default), forge or forge-pixel - the models supporting a middle keyframe. Input images can be provided in base64 or URL. At least one of initial_image or middle_image must be provided."Input schema / properties / requestBody / properties / crop / descriptionPrevious value: -"Crop sprite frames to fit content. Results in smaller spritesheets but inconsistent frame sizes across different animations. Default: false."New value: +"Crop sprite frames to fit content. Results in smaller spritesheets but inconsistent frame sizes across different animations. Default: true."Input schema / properties / requestBody / properties / crop / examplePrevious value: -falseNew value: +trueInput schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- hydra: 3, 3.5, 4, 4.5, 5\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5\n- blitz: 1.2, 1.5, 2, 2.5, 3, 3.5, 4\n- eagle: 1, 2, 3, 4\n- eagle-audio: 1, 2, 3, 4 Default: 3."New value: +"Duration in seconds. Available values depend on the model:\n- hydra: 3, 3.5, 4, 4.5, 5\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5 Default: 3."Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s\n- \"forge\" (Forge): 1.5 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min 4\n- \"blitz\" (Blitz): 1.9 credits/s, min 4 · LEGACY - scheduled for removal, do not use for new work\n- \"eagle\" (Eagle): 2.6 credits/s, min 4 · LEGACY - scheduled for removal, do not use for new work\n- \"eagle-audio\" (Eagle with Audio): 3.1 credits/s, min 4 · LEGACY - scheduled for removal, do not use for new work\nLegacy aliases: \"standard\" → blitz.\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"forge\"."New value: +"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, shortest duration 3s, so 9 credits minimum · Most capable model, generates audio\n- \"forge\" (Forge): 1.5 credits/s, min charge 4 credits · Best for basic animations and relatively simple sprites\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min charge 4 credits · Best for low-res pixel art animations Default: \"hydra\"."Input schema / properties / requestBody / properties / model / enumPrevious value: -[
- "hydra",
- "forge",
- "forge-pixel",
- "blitz",
- "standard",
- "eagle",
- "eagle-audio"
-]New value: +[
+ "hydra",
+ "forge",
+ "forge-pixel"
+]Input schema / properties / requestBody / properties / model / examplePrevious value: -"forge"New value: +"hydra"Input schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."create3DModel1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."createAmbiance1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."createAudioTransform1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."createImage2 fields changedInput schema / properties / requestBody / properties / n / typePrevious value: -"number"New value: +"integer"Input schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."createMusic1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."createSoundEffect1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."createSpeech2 fields changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."Input schema / properties / requestBody / properties / text / descriptionPrevious value: -"Text to convert to speech (max 100 words)."New value: +"Text to convert to speech (max 1000 characters)."createSpeechPreset2 fields changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."Input schema / properties / requestBody / properties / text / descriptionPrevious value: -"Text to convert to speech (max 100 words)."New value: +"Text to convert to speech (max 1000 characters)."createVideo4 fields changedInput schema / properties / requestBody / properties / duration / examplePrevious value: -3New value: +5Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"griffin\" (Griffin): 1.5 credits/s\n- \"griffin-hd\" (Griffin HD): 2 credits/s\n- \"blitz\" (Blitz): 1 credits/s · LEGACY - scheduled for removal, do not use for new work\n- \"eagle\" (Eagle): 1.3 credits/s · LEGACY - scheduled for removal, do not use for new work\n- \"eagle-audio\" (Eagle with Audio): 1.8 credits/s · LEGACY - scheduled for removal, do not use for new work\nLegacy aliases: \"standard\" → blitz.\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"eagle\"."New value: +"Model to use. Available models:\n- \"griffin\" (Griffin): 1.5 credits/s, shortest duration 5s, so 7.5 credits minimum · Fast cinematic videos in any style, with audio, 480p\n- \"griffin-hd\" (Griffin HD): 2 credits/s, shortest duration 5s, so 10 credits minimum · Same as Griffin, but in 720p\n- \"blitz\" (Blitz): 1 credits/s, shortest duration 2s, so 2 credits minimum · LEGACY - scheduled for removal, do not use for new work\n- \"eagle\" (Eagle): 1.3 credits/s · LEGACY - scheduled for removal, do not use for new work\n- \"eagle-audio\" (Eagle with Audio): 1.8 credits/s · LEGACY - scheduled for removal, do not use for new work\nLegacy aliases: \"standard\" → blitz.\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"griffin\"."Input schema / properties / requestBody / properties / model / examplePrevious value: -"eagle"New value: +"griffin"Input schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."createVideoFromReferences3 fields changedInput schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"griffin\" (Griffin): 2.5 credits/s\n- \"griffin-hd\" (Griffin HD): 4 credits/s\n- \"eagle\" (Eagle): 1.5 credits/s · LEGACY - scheduled for removal, do not use for new work\n- \"eagle-audio\" (Eagle with Audio): 2 credits/s · LEGACY - scheduled for removal, do not use for new work\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"eagle\"."New value: +"Model to use. Available models:\n- \"griffin\" (Griffin): 2.5 credits/s, shortest duration 5s, so 12.5 credits minimum · Fast cinematic videos in any style, with audio, 480p\n- \"griffin-hd\" (Griffin HD): 4 credits/s, shortest duration 5s, so 20 credits minimum · Same as Griffin, but in 720p\n- \"eagle\" (Eagle): 1.5 credits/s · LEGACY - scheduled for removal, do not use for new work\n- \"eagle-audio\" (Eagle with Audio): 2 credits/s · LEGACY - scheduled for removal, do not use for new work\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"griffin\"."Input schema / properties / requestBody / properties / model / examplePrevious value: -"eagle"New value: +"griffin"Input schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."createVoice2 fields changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."Input schema / properties / requestBody / properties / text / descriptionPrevious value: -"Text for the voice to speak (max 20 words)."New value: +"Text for the voice to speak (max 200 characters)."editImage1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."editSpritesheet9 fields changedInput schema / properties / requestBody / properties / crop / descriptionPrevious value: -"Crop sprite frames to fit content. Results in smaller spritesheets but inconsistent frame sizes across different animations."New value: +"Crop sprite frames to fit content (omit to keep the source spritesheet's setting). Results in smaller spritesheets but inconsistent frame sizes across different animations."Input schema / properties / requestBody / properties / frame_size / descriptionPrevious value: -"Size of each frame in pixels (width and height). 0 is for maximum resolution. Defaults to the source spritesheet's frame size. Accepted values: 32, 64, 96, 128, 192, 256, 384, 0."New value: +"Size of each frame in pixels (width and height). 0 is for maximum resolution. Omit to keep the source spritesheet's frame size. Accepted values: 32, 64, 96, 128, 192, 256, 384, 0."Input schema / properties / requestBody / properties / frame_size / exampleRemoved value: -32Input schema / properties / requestBody / properties / frames / descriptionPrevious value: -"Number of frames in the output spritesheet. Defaults to the source spritesheet's frame count. Accepted values: 4, 9, 16, 25, 36, 49, 64."New value: +"Number of frames in the output spritesheet. Omit to keep the source spritesheet's frame count. Accepted values: 4, 9, 16, 25, 36, 49, 64."Input schema / properties / requestBody / properties / frames / exampleRemoved value: -4Input schema / properties / requestBody / properties / loop / exampleRemoved value: -trueInput schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s\n- \"forge\" (Forge): 2 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4 Default: \"forge\"."New value: +"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, shortest duration 3s, so 9 credits minimum · Most capable model, generates audio\n- \"forge\" (Forge): 2 credits/s, min charge 4 credits · Cost-effective for simple editing tasks\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min charge 4 credits · Best for low-res pixel art animations Default: \"forge\"."Input schema / properties / requestBody / properties / model / exampleRemoved value: -"forge"Input schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."editVideo3 fields changedInput schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"griffin-hd\" (Griffin HD): 2 credits/s\n- \"eagle\" (Eagle): 2 credits/s · LEGACY - scheduled for removal, do not use for new work\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"eagle\"."New value: +"Model to use. Available models:\n- \"griffin-hd\" (Griffin HD): 2 credits/s, shortest duration 5s, so 10 credits minimum · Same as Griffin, but in 720p\n- \"eagle\" (Eagle): 2 credits/s · LEGACY - scheduled for removal, do not use for new work\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"griffin-hd\"."Input schema / properties / requestBody / properties / model / examplePrevious value: -"eagle"New value: +"griffin-hd"Input schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."generatePose1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."generateWithStyle2 fields changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."Input schema / properties / requestBody / requiredPrevious value: -[
- "style_image",
- "prompt",
- "image_type"
-]New value: +[
+ "style_image",
+ "prompt"
+]getApiJob1 field changedInput schema / properties / id / descriptionAdded value: +"The job id returned by a generation call (its `id` in the 202 response)."removeBackground1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."rigModel3 fields changedInput schema / properties / requestBody / properties / model / descriptionPrevious value: -"URL or base64-encoded GLB to rig."New value: +"The 3D asset to rig, as a URL or base64-encoded GLB file (not an AI model name)."Input schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."Input schema / properties / requestBody / properties / rig_type / descriptionPrevious value: -"Which skeleton to build: general (any asset), humanoid (anime-style characters), game (classic game-character rigs), or the pinned humanoid templates with named joints required for the animation preset library - humanoid_template (22 joints) / humanoid_template_hands (52, five fingers per hand). Templates only suit two-armed, two-legged characters. Default: \"general\"."New value: +"Which skeleton to build. Pick humanoid_template (or humanoid_template_hands) if you intend to use animate3DModelPreset later - the default general rig cannot take presets. general (any asset), humanoid (anime-style characters), game (classic game-character rigs), or the pinned humanoid templates with named joints required for the animation preset library - humanoid_template (22 joints) / humanoid_template_hands (52, five fingers per hand). Templates only suit two-armed, two-legged characters. Default: \"general\"."rotateSprite1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."transferMotion11 fields changedInput schema / properties / requestBody / properties / crop / descriptionPrevious value: -"Crop sprite frames to fit content. Results in smaller spritesheets but inconsistent frame sizes across different animations. Default: false."New value: +"Crop sprite frames to fit content. Results in smaller spritesheets but inconsistent frame sizes across different animations. Default: true."Input schema / properties / requestBody / properties / crop / examplePrevious value: -falseNew value: +trueInput schema / properties / requestBody / properties / image / descriptionPrevious value: -"Payload for generating an animated spritesheet from a static image. Input images can either be provided in base64 or URL. If the image was generated using Ludo, ideally it should be generated using the \"sprite\", \"sprite-vfx\" or \"ui_asset\" type."New value: +"The static sprite to animate, as a URL or base64 image. Ideally an image generated with the \"sprite\", \"sprite-vfx\" or \"ui_asset\" image type."Input schema / properties / requestBody / properties / image / examplePrevious value: -"data:image/png;base64,..."New value: +"<url> OR data:image/png;base64,..."Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s\n- \"forge\" (Forge): 2 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4\n- \"tango\" (Tango): 4 credits/s, min 4 · LEGACY - scheduled for removal, do not use for new work\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"forge\"."New value: +"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, shortest duration 3s, so 9 credits minimum · Most capable model, generates audio\n- \"forge\" (Forge): 2 credits/s, min charge 4 credits · Cost-effective for simple motion. Works best with Presets and matching poses\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min charge 4 credits · Best for low-res pixel art animations\n- \"tango\" (Tango): 4 credits/s, min charge 4 credits · LEGACY - scheduled for removal, do not use for new work\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"forge\"."Input schema / properties / requestBody / properties / perspective / descriptionPrevious value: -"Perspective ID to use with the animation preset. When using a preset, `perspective` is required."New value: +"Camera perspective of the preset clip, by id (the `perspectives` list of listAnimationPresets, the same set for every preset): high = tactical steep top-down, horizon = side view at eye level, isometric = diagonal top-down with depth, low = hero low angle, top = directly overhead. Required when using a preset. Unrelated to the `perspective` of createImage, which is a free-text art direction."Input schema / properties / requestBody / properties / perspective / enumAdded value: +[
+ "high",
+ "horizon",
+ "isometric",
+ "low",
+ "top"
+]Input schema / properties / requestBody / properties / perspective / exampleAdded value: +"high"Input schema / properties / requestBody / properties / preset_id / descriptionPrevious value: -"ID of an animation preset to use instead of a video URL. Use the animation-presets endpoint to list available presets. When using a preset, `perspective` and `direction` are required."New value: +"ID of an animation preset to use instead of a video URL. Use listAnimationPresets to list available presets. When using a preset, `perspective` and `direction` are required."Input schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."Input schema / properties / requestBody / properties / video / descriptionPrevious value: -"URL of the video to use as motion source. You can use videos from the animateSprite endpoint or provide your own. Videos up to 4 seconds will produce better results. Either `video` or `preset_id` + `perspective` + `direction` must be provided."New value: +"URL of the video to use as motion source - the `video_url` of a spritesheet from animateSprite, or your own clip. Videos up to 4 seconds work best. Either `video` or `preset_id` + `perspective` + `direction` must be provided; when both are sent the video is used."upscaleVideo2 fields changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."Input schema / properties / requestBody / properties / video / descriptionPrevious value: -"URL of a video you generated in the last 7 days (returned by createVideo, createVideoFromReferences, or editVideo). External URLs are not accepted. Only videos below 960x960 pixels can be upscaled."New value: +"URL of a video you generated in the last 7 days (returned by createVideo, createVideoFromReferences, or editVideo). External URLs are not accepted. Both dimensions must be under 960 pixels (griffin 480p output qualifies; griffin-hd 720p output does not, except square)."animateSprite3 fields changedInput schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- hydra: 3, 3.5, 4, 4.5, 5\n- blitz: 1.2, 1.5, 2, 2.5, 3, 3.5, 4\n- eagle: 1, 2, 3, 4\n- eagle-audio: 1, 2, 3, 4\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5 Default: 3."New value: +"Duration in seconds. Available values depend on the model:\n- hydra: 3, 3.5, 4, 4.5, 5\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5\n- blitz: 1.2, 1.5, 2, 2.5, 3, 3.5, 4\n- eagle: 1, 2, 3, 4\n- eagle-audio: 1, 2, 3, 4 Default: 3."Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, min 4\n- \"blitz\" (Blitz): 1.9 credits/s, min 4\n- \"eagle\" (Eagle): 2.6 credits/s, min 4\n- \"eagle-audio\" (Eagle with Audio): 3.1 credits/s, min 4\n- \"forge\" (Forge): 1.5 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min 4\nLegacy aliases: \"standard\" → blitz. Default: \"blitz\"."New value: +"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s\n- \"forge\" (Forge): 1.5 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min 4\n- \"blitz\" (Blitz): 1.9 credits/s, min 4 · LEGACY - scheduled for removal, do not use for new work\n- \"eagle\" (Eagle): 2.6 credits/s, min 4 · LEGACY - scheduled for removal, do not use for new work\n- \"eagle-audio\" (Eagle with Audio): 3.1 credits/s, min 4 · LEGACY - scheduled for removal, do not use for new work\nLegacy aliases: \"standard\" → blitz.\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"blitz\"."Input schema / properties / requestBody / properties / model / enumPrevious value: -[
- "hydra",
- "blitz",
- "standard",
- "eagle",
- "eagle-audio",
- "forge",
- "forge-pixel"
-]New value: +[
+ "hydra",
+ "forge",
+ "forge-pixel",
+ "blitz",
+ "standard",
+ "eagle",
+ "eagle-audio"
+]animateSpriteKeyframes3 fields changedInput schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- hydra: 3, 3.5, 4, 4.5, 5\n- blitz: 1.2, 1.5, 2, 2.5, 3, 3.5, 4\n- eagle: 1, 2, 3, 4\n- eagle-audio: 1, 2, 3, 4\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5 Default: 3."New value: +"Duration in seconds. Available values depend on the model:\n- hydra: 3, 3.5, 4, 4.5, 5\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5\n- blitz: 1.2, 1.5, 2, 2.5, 3, 3.5, 4\n- eagle: 1, 2, 3, 4\n- eagle-audio: 1, 2, 3, 4 Default: 3."Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, min 4\n- \"blitz\" (Blitz): 1.9 credits/s, min 4\n- \"eagle\" (Eagle): 2.6 credits/s, min 4\n- \"eagle-audio\" (Eagle with Audio): 3.1 credits/s, min 4\n- \"forge\" (Forge): 1.5 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min 4\nLegacy aliases: \"standard\" → blitz. Default: \"forge\"."New value: +"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s\n- \"forge\" (Forge): 1.5 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min 4\n- \"blitz\" (Blitz): 1.9 credits/s, min 4 · LEGACY - scheduled for removal, do not use for new work\n- \"eagle\" (Eagle): 2.6 credits/s, min 4 · LEGACY - scheduled for removal, do not use for new work\n- \"eagle-audio\" (Eagle with Audio): 3.1 credits/s, min 4 · LEGACY - scheduled for removal, do not use for new work\nLegacy aliases: \"standard\" → blitz.\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"forge\"."Input schema / properties / requestBody / properties / model / enumPrevious value: -[
- "hydra",
- "blitz",
- "standard",
- "eagle",
- "eagle-audio",
- "forge",
- "forge-pixel"
-]New value: +[
+ "hydra",
+ "forge",
+ "forge-pixel",
+ "blitz",
+ "standard",
+ "eagle",
+ "eagle-audio"
+]createVideo1 field changedInput schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"griffin\" (Griffin): 1.5 credits/s\n- \"griffin-hd\" (Griffin HD): 2 credits/s\n- \"blitz\" (Blitz): 1 credits/s\n- \"eagle\" (Eagle): 1.3 credits/s\n- \"eagle-audio\" (Eagle with Audio): 1.8 credits/s\nLegacy aliases: \"standard\" → blitz. Default: \"eagle\"."New value: +"Model to use. Available models:\n- \"griffin\" (Griffin): 1.5 credits/s\n- \"griffin-hd\" (Griffin HD): 2 credits/s\n- \"blitz\" (Blitz): 1 credits/s · LEGACY - scheduled for removal, do not use for new work\n- \"eagle\" (Eagle): 1.3 credits/s · LEGACY - scheduled for removal, do not use for new work\n- \"eagle-audio\" (Eagle with Audio): 1.8 credits/s · LEGACY - scheduled for removal, do not use for new work\nLegacy aliases: \"standard\" → blitz.\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"eagle\"."createVideoFromReferences1 field changedInput schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"griffin\" (Griffin): 2.5 credits/s\n- \"griffin-hd\" (Griffin HD): 4 credits/s\n- \"eagle\" (Eagle): 1.5 credits/s\n- \"eagle-audio\" (Eagle with Audio): 2 credits/s Default: \"eagle\"."New value: +"Model to use. Available models:\n- \"griffin\" (Griffin): 2.5 credits/s\n- \"griffin-hd\" (Griffin HD): 4 credits/s\n- \"eagle\" (Eagle): 1.5 credits/s · LEGACY - scheduled for removal, do not use for new work\n- \"eagle-audio\" (Eagle with Audio): 2 credits/s · LEGACY - scheduled for removal, do not use for new work\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"eagle\"."editSpritesheet1 field changedInput schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, min 4\n- \"forge\" (Forge): 2 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4 Default: \"forge\"."New value: +"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s\n- \"forge\" (Forge): 2 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4 Default: \"forge\"."editVideo1 field changedInput schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"griffin-hd\" (Griffin HD): 2 credits/s\n- \"eagle\" (Eagle): 2 credits/s Default: \"eagle\"."New value: +"Model to use. Available models:\n- \"griffin-hd\" (Griffin HD): 2 credits/s\n- \"eagle\" (Eagle): 2 credits/s · LEGACY - scheduled for removal, do not use for new work\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"eagle\"."transferMotion1 field changedInput schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, min 4\n- \"forge\" (Forge): 2 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4\n- \"tango\" (Tango): 4 credits/s, min 4 Default: \"forge\"."New value: +"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s\n- \"forge\" (Forge): 2 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4\n- \"tango\" (Tango): 4 credits/s, min 4 · LEGACY - scheduled for removal, do not use for new work\nModels marked LEGACY still work for existing integrations but will be removed; pick a current model for anything new. Default: \"forge\"."animateSprite5 fields changedInput schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- blitz: 1.2, 1.5, 2, 2.5, 3, 3.5, 4\n- eagle: 1, 2, 3, 4\n- eagle-audio: 1, 2, 3, 4\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4 Default: 3."New value: +"Duration in seconds. Available values depend on the model:\n- hydra: 3, 3.5, 4, 4.5, 5\n- blitz: 1.2, 1.5, 2, 2.5, 3, 3.5, 4\n- eagle: 1, 2, 3, 4\n- eagle-audio: 1, 2, 3, 4\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5 Default: 3."Input schema / properties / requestBody / properties / frame_size / examplePrevious value: -32New value: +0Input schema / properties / requestBody / properties / frames / examplePrevious value: -4New value: +36Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"blitz\" (Blitz): Visual Quality: 4/10 · Motion Stability: 8/10 · 1.9 credits/s, min 4\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 2.6 credits/s, min 4\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 3.1 credits/s, min 4\n- \"forge\" (Forge): 1.5 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min 4\nLegacy aliases: \"standard\" → blitz. Default: \"blitz\"."New value: +"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, min 4\n- \"blitz\" (Blitz): 1.9 credits/s, min 4\n- \"eagle\" (Eagle): 2.6 credits/s, min 4\n- \"eagle-audio\" (Eagle with Audio): 3.1 credits/s, min 4\n- \"forge\" (Forge): 1.5 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min 4\nLegacy aliases: \"standard\" → blitz. Default: \"blitz\"."Input schema / properties / requestBody / properties / model / enumPrevious value: -[
- "blitz",
- "standard",
- "eagle",
- "eagle-audio",
- "forge",
- "forge-pixel"
-]New value: +[
+ "hydra",
+ "blitz",
+ "standard",
+ "eagle",
+ "eagle-audio",
+ "forge",
+ "forge-pixel"
+]animateSpriteKeyframes5 fields changedInput schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- blitz: 1.2, 1.5, 2, 2.5, 3, 3.5, 4\n- eagle: 1, 2, 3, 4\n- eagle-audio: 1, 2, 3, 4\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4 Default: 3."New value: +"Duration in seconds. Available values depend on the model:\n- hydra: 3, 3.5, 4, 4.5, 5\n- blitz: 1.2, 1.5, 2, 2.5, 3, 3.5, 4\n- eagle: 1, 2, 3, 4\n- eagle-audio: 1, 2, 3, 4\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5 Default: 3."Input schema / properties / requestBody / properties / frame_size / examplePrevious value: -32New value: +0Input schema / properties / requestBody / properties / frames / examplePrevious value: -4New value: +36Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"blitz\" (Blitz): Visual Quality: 4/10 · Motion Stability: 8/10 · 1.9 credits/s, min 4\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 2.6 credits/s, min 4\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 3.1 credits/s, min 4\n- \"forge\" (Forge): 1.5 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min 4\nLegacy aliases: \"standard\" → blitz. Default: \"forge\"."New value: +"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, min 4\n- \"blitz\" (Blitz): 1.9 credits/s, min 4\n- \"eagle\" (Eagle): 2.6 credits/s, min 4\n- \"eagle-audio\" (Eagle with Audio): 3.1 credits/s, min 4\n- \"forge\" (Forge): 1.5 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min 4\nLegacy aliases: \"standard\" → blitz. Default: \"forge\"."Input schema / properties / requestBody / properties / model / enumPrevious value: -[
- "blitz",
- "standard",
- "eagle",
- "eagle-audio",
- "forge",
- "forge-pixel"
-]New value: +[
+ "hydra",
+ "blitz",
+ "standard",
+ "eagle",
+ "eagle-audio",
+ "forge",
+ "forge-pixel"
+]create3DModel1 field changedInput schema / properties / requestBody / properties / texture_size / examplePrevious value: -1024New value: +2048createSpriteAudiocreateVideo3 fields changedInput schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- blitz: 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- eagle-audio: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 Default: 5."New value: +"Duration in seconds. Available values depend on the model:\n- griffin: 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- griffin-hd: 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- blitz: 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- eagle-audio: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 Default: 5."Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"blitz\" (Blitz): Visual Quality: 4/10 · Motion Stability: 8/10 · 1 credits/s\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.3 credits/s\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.8 credits/s\nLegacy aliases: \"standard\" → blitz. Default: \"eagle\"."New value: +"Model to use. Available models:\n- \"griffin\" (Griffin): 1.5 credits/s\n- \"griffin-hd\" (Griffin HD): 2 credits/s\n- \"blitz\" (Blitz): 1 credits/s\n- \"eagle\" (Eagle): 1.3 credits/s\n- \"eagle-audio\" (Eagle with Audio): 1.8 credits/s\nLegacy aliases: \"standard\" → blitz. Default: \"eagle\"."Input schema / properties / requestBody / properties / model / enumPrevious value: -[
- "blitz",
- "standard",
- "eagle",
- "eagle-audio"
-]New value: +[
+ "griffin",
+ "griffin-hd",
+ "blitz",
+ "standard",
+ "eagle",
+ "eagle-audio"
+]createVideoFromReferences3 fields changedInput schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- eagle-audio: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 Default: 5."New value: +"Duration in seconds. Available values depend on the model:\n- griffin: 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- griffin-hd: 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- eagle-audio: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 Default: 5."Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.5 credits/s\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 2 credits/s Default: \"eagle\"."New value: +"Model to use. Available models:\n- \"griffin\" (Griffin): 2.5 credits/s\n- \"griffin-hd\" (Griffin HD): 4 credits/s\n- \"eagle\" (Eagle): 1.5 credits/s\n- \"eagle-audio\" (Eagle with Audio): 2 credits/s Default: \"eagle\"."Input schema / properties / requestBody / properties / model / enumPrevious value: -[
- "eagle",
- "eagle-audio"
-]New value: +[
+ "griffin",
+ "griffin-hd",
+ "eagle",
+ "eagle-audio"
+]editSpritesheet3 fields changedInput schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4"New value: +"Duration in seconds. Available values depend on the model:\n- hydra: 3, 3.5, 4, 4.5, 5\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5"Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"forge\" (Forge): 2 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4 Default: \"forge\"."New value: +"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, min 4\n- \"forge\" (Forge): 2 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4 Default: \"forge\"."Input schema / properties / requestBody / properties / model / enumPrevious value: -[
- "forge",
- "forge-pixel"
-]New value: +[
+ "hydra",
+ "forge",
+ "forge-pixel"
+]editVideo3 fields changedInput schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15"New value: +"Duration in seconds. Available values depend on the model:\n- griffin-hd: 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15"Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 2 credits/s Default: \"eagle\"."New value: +"Model to use. Available models:\n- \"griffin-hd\" (Griffin HD): 2 credits/s\n- \"eagle\" (Eagle): 2 credits/s Default: \"eagle\"."Input schema / properties / requestBody / properties / model / enumPrevious value: -[
- "eagle"
-]New value: +[
+ "griffin-hd",
+ "eagle"
+]generateWithStyle1 field changedInput schema / properties / requestBody / properties / image_type / examplePrevious value: -"generic"New value: +"sprite"searchDocstransferMotion6 fields changedInput schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. If the reference video is longer, it will be compressed to this duration. Available values depend on the model:\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4\n- tango: 1, 1.5, 2, 2.5, 3, 3.5, 4 Default: 1.5."New value: +"Duration in seconds. If the reference video is longer, it will be compressed to this duration. Available values depend on the model:\n- hydra: 3, 3.5, 4, 4.5, 5\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5\n- tango: 1, 1.5, 2, 2.5, 3, 3.5, 4 Default: 1.5."Input schema / properties / requestBody / properties / frame_size / examplePrevious value: -32New value: +0Input schema / properties / requestBody / properties / frames / examplePrevious value: -4New value: +36Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"forge\" (Forge): 2 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4\n- \"tango\" (Tango): 4 credits/s, min 4 Default: \"forge\"."New value: +"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, min 4\n- \"forge\" (Forge): 2 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4\n- \"tango\" (Tango): 4 credits/s, min 4 Default: \"forge\"."Input schema / properties / requestBody / properties / model / enumPrevious value: -[
- "forge",
- "forge-pixel",
- "tango"
-]New value: +[
+ "hydra",
+ "forge",
+ "forge-pixel",
+ "tango"
+]Input schema / properties / requestBody / properties / promptAdded value: +{
+ "description": "Optional extra instructions for the motion transfer (e.g. \"keep the cape still\"), added to the model's own prompt.",
+ "type": "string"
+}createVideo3 fields changedInput schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- blitz: 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- eagle-audio: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4 Default: 5."New value: +"Duration in seconds. Available values depend on the model:\n- blitz: 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- eagle-audio: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 Default: 5."Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"blitz\" (Blitz): Visual Quality: 4/10 · Motion Stability: 8/10 · 1 credits/s\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.3 credits/s\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.8 credits/s\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4\nLegacy aliases: \"standard\" → blitz. Default: \"eagle\"."New value: +"Model to use. Available models:\n- \"blitz\" (Blitz): Visual Quality: 4/10 · Motion Stability: 8/10 · 1 credits/s\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.3 credits/s\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.8 credits/s\nLegacy aliases: \"standard\" → blitz. Default: \"eagle\"."Input schema / properties / requestBody / properties / model / enumPrevious value: -[
- "blitz",
- "standard",
- "eagle",
- "eagle-audio",
- "forge-pixel"
-]New value: +[
+ "blitz",
+ "standard",
+ "eagle",
+ "eagle-audio"
+]createVideoFromReferences3 fields changedInput schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- eagle-audio: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4 Default: 5."New value: +"Duration in seconds. Available values depend on the model:\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- eagle-audio: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 Default: 5."Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.5 credits/s\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 2 credits/s\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4 Default: \"eagle\"."New value: +"Model to use. Available models:\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.5 credits/s\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 2 credits/s Default: \"eagle\"."Input schema / properties / requestBody / properties / model / enumPrevious value: -[
- "eagle",
- "eagle-audio",
- "forge-pixel"
-]New value: +[
+ "eagle",
+ "eagle-audio"
+]editVideo3 fields changedInput schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4"New value: +"Duration in seconds. Available values depend on the model:\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15"Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 2 credits/s\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4 Default: \"eagle\"."New value: +"Model to use. Available models:\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 2 credits/s Default: \"eagle\"."Input schema / properties / requestBody / properties / model / enumPrevious value: -[
- "eagle",
- "forge-pixel"
-]New value: +[
+ "eagle"
+]getDocs1 field changedInput schema / properties / sections / descriptionPrevious value: -"Comma-separated section titles to return from `doc`, matched case-insensitively against that document's section titles. Only valid together with `doc`. Omit to return every section of the document."New value: +"Section titles to return from `doc`, copied from the table of contents (an array of titles; over plain REST, a comma-separated string, where a title that itself contains a comma is still matched whole). Matching ignores case, spacing and punctuation; titles that match nothing are reported back in `unmatched_sections` rather than guessed at. Only valid together with `doc`. Omit to return every section of the document."animateSprite1 field changedInput schema / properties / requestBody / properties / augment_prompt / descriptionPrevious value: -"Augment the prompt behind the scenes. Disable to have more control. Default: true."New value: +"Augment the prompt behind the scenes. Disable to have more control. Incompatible with automatic framing: false requires margin_ratio_mode \"manual\" (with margin_ratio_horizontal and/or margin_ratio_vertical) or \"none\". Because margin_ratio_mode defaults to \"auto\", sending augment_prompt false on its own fails with HTTP 400. Default: true."animateSpriteKeyframes1 field changedInput schema / properties / requestBody / properties / augment_prompt / descriptionPrevious value: -"Augment the prompt behind the scenes. Disable to have more control. Default: true."New value: +"Augment the prompt behind the scenes. Disable to have more control. Incompatible with automatic framing: false requires margin_ratio_mode \"manual\" (with margin_ratio_horizontal and/or margin_ratio_vertical) or \"none\". Because margin_ratio_mode defaults to \"auto\", sending augment_prompt false on its own fails with HTTP 400. Default: true."getDocsanimate3DModel8 fields changedInput schema / properties / requestBody / properties / augment_prompt / defaultRemoved value: -trueInput schema / properties / requestBody / properties / augment_prompt / descriptionPrevious value: -"Rewrite the prompt into a detailed motion caption with an LLM (recommended)."New value: +"Rewrite the prompt into a detailed motion caption with an LLM (recommended). Default: true."Input schema / properties / requestBody / properties / loop / defaultRemoved value: -trueInput schema / properties / requestBody / properties / loop / descriptionPrevious value: -"Return to the initial pose: each clip plays forward then mirrors back to the rest pose for a seamless loop. Best for one-way motions (crouch, punch, wave); reads oddly for cyclic gaits like walking."New value: +"Return to the initial pose: each clip plays forward then mirrors back to the rest pose for a seamless loop. Best for one-way motions (crouch, punch, wave); reads oddly for cyclic gaits like walking. Default: true."Input schema / properties / requestBody / properties / mode / defaultRemoved value: -"rot_trans"Input schema / properties / requestBody / properties / mode / descriptionPrevious value: -"Animation representation: rot_trans (per-bone rotation+translation, most faithful) or rot_only (rotation + root translation only, for retargeting)."New value: +"Animation representation: rot_trans (per-bone rotation+translation, most faithful) or rot_only (rotation + root translation only, for retargeting). Default: \"rot_trans\"."Input schema / properties / requestBody / properties / num_variants / defaultRemoved value: -4Input schema / properties / requestBody / properties / num_variants / descriptionPrevious value: -"Number of candidate animations to generate; each returned as a standalone animation-only GLB with an mp4 preview."New value: +"Number of candidate animations to generate; each returned as a standalone animation-only GLB with an mp4 preview. Default: 4."animateSprite28 fields changedInput schema / properties / requestBody / properties / augment_prompt / defaultRemoved value: -trueInput schema / properties / requestBody / properties / augment_prompt / descriptionPrevious value: -"Augment the prompt behind the scenes. Disable to have more control."New value: +"Augment the prompt behind the scenes. Disable to have more control. Default: true."Input schema / properties / requestBody / properties / crop / defaultRemoved value: -falseInput schema / properties / requestBody / properties / crop / descriptionPrevious value: -"Crop sprite frames to fit content. Results in smaller spritesheets but inconsistent frame sizes across different animations."New value: +"Crop sprite frames to fit content. Results in smaller spritesheets but inconsistent frame sizes across different animations. Default: false."Input schema / properties / requestBody / properties / duration / defaultRemoved value: -3Input schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- blitz: 1.2, 1.5, 2, 2.5, 3, 3.5, 4\n- eagle: 1, 2, 3, 4\n- eagle-audio: 1, 2, 3, 4\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4"New value: +"Duration in seconds. Available values depend on the model:\n- blitz: 1.2, 1.5, 2, 2.5, 3, 3.5, 4\n- eagle: 1, 2, 3, 4\n- eagle-audio: 1, 2, 3, 4\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4 Default: 3."Input schema / properties / requestBody / properties / frame_size / defaultRemoved value: -0Input schema / properties / requestBody / properties / frame_size / descriptionPrevious value: -"Size of each frame in pixels (width and height). 0 is for maximum resolution. -1 is for AI 1.5x upscaling. -9 is for matching the size and position of the input frame. Accepted values: 32, 64, 96, 128, 192, 256, 384, 0, -1, -9."New value: +"Size of each frame in pixels (width and height). 0 is for maximum resolution. -1 is for AI 1.5x upscaling. -9 is for matching the size and position of the input frame. Accepted values: 32, 64, 96, 128, 192, 256, 384, 0, -1, -9. Default: 0."Input schema / properties / requestBody / properties / frames / defaultRemoved value: -36Input schema / properties / requestBody / properties / frames / descriptionPrevious value: -"Number of frames in the output spritesheet. Accepted values: 4, 9, 16, 25, 36, 49, 64."New value: +"Number of frames in the output spritesheet. Accepted values: 4, 9, 16, 25, 36, 49, 64. Default: 36."Input schema / properties / requestBody / properties / gif / defaultRemoved value: -falseInput schema / properties / requestBody / properties / gif / descriptionPrevious value: -"When true, generates an animated GIF from the spritesheet and returns it in gif_url. Disabled by default to reduce response time."New value: +"When true, generates an animated GIF from the spritesheet and returns it in gif_url. Disabled by default to reduce response time. Default: false."Input schema / properties / requestBody / properties / image_type / defaultRemoved value: -"sprite"Input schema / properties / requestBody / properties / image_type / descriptionPrevious value: -"Type of sprite being animated. Affects generation parameters and styling."New value: +"Type of sprite being animated. Affects generation parameters and styling. Default: \"sprite\"."Input schema / properties / requestBody / properties / individual_frames / defaultRemoved value: -falseInput schema / properties / requestBody / properties / individual_frames / descriptionPrevious value: -"When true, extracts each frame from the spritesheet as an individual image and returns the URLs in individual_frame_urls."New value: +"When true, extracts each frame from the spritesheet as an individual image and returns the URLs in individual_frame_urls. Default: false."Input schema / properties / requestBody / properties / loop / defaultRemoved value: -trueInput schema / properties / requestBody / properties / loop / descriptionPrevious value: -"Trim the animation at the beginning or end to create a seamless loop. Not guaranteed to produce a perfect loop."New value: +"Trim the animation at the beginning or end to create a seamless loop. Not guaranteed to produce a perfect loop. Default: true."Input schema / properties / requestBody / properties / margin_ratio / deprecatedAdded value: +trueInput schema / properties / requestBody / properties / margin_ratio / descriptionPrevious value: -"Deprecated - prefer margin_ratio_horizontal / margin_ratio_vertical. Amount of padding around the sprite as a ratio (0.0 to 1.0), applied to both axes (equivalent to setting both per-axis params to this value). Only used when margin_ratio_mode is \"manual\". Cannot be combined with the per-axis params: providing both fails with HTTP 400."New value: +"Deprecated: prefer margin_ratio_horizontal / margin_ratio_vertical. Amount of padding around the sprite as a ratio (0.0 to 1.0). Sets both axes to this value. A per-axis value, when also given, overrides this for that axis. Supplying any margin value selects margin_ratio_mode \"manual\" unless margin_ratio_mode is set explicitly."Input schema / properties / requestBody / properties / margin_ratio_horizontal / descriptionPrevious value: -"Horizontal padding around the sprite as a ratio (0.0 to 1.0). Only used when margin_ratio_mode is \"manual\". Useful for animations that extend sideways (e.g., sword slashes, punches). Cannot be combined with the legacy margin_ratio param."New value: +"Horizontal padding around the sprite as a ratio (0.0 to 1.0). Useful for animations that extend sideways (e.g., sword slashes, punches). Supplying a value selects margin_ratio_mode \"manual\" unless margin_ratio_mode is set explicitly; overrides the legacy margin_ratio on this axis."Input schema / properties / requestBody / properties / margin_ratio_mode / defaultRemoved value: -"auto"Input schema / properties / requestBody / properties / margin_ratio_mode / descriptionPrevious value: -"Controls how margins are applied around the sprite. \"manual\" requires margin_ratio_horizontal and/or margin_ratio_vertical (or the legacy margin_ratio); sending \"manual\" with no margin value fails with HTTP 400."New value: +"Controls how margins are applied around the sprite. Omit it and send margin_ratio_horizontal / margin_ratio_vertical to get \"manual\" automatically. \"manual\" requires margin_ratio_horizontal and/or margin_ratio_vertical (or the legacy margin_ratio); sending \"manual\" with no margin value fails with HTTP 400. Sending \"auto\" or \"none\" explicitly together with a margin value fails with HTTP 400 (the value would be ignored). Default: \"auto\"."Input schema / properties / requestBody / properties / margin_ratio_vertical / descriptionPrevious value: -"Vertical padding around the sprite as a ratio (0.0 to 1.0). Only used when margin_ratio_mode is \"manual\". Useful for animations that extend up or down (e.g., jumps). Cannot be combined with the legacy margin_ratio param."New value: +"Vertical padding around the sprite as a ratio (0.0 to 1.0). Useful for animations that extend up or down (e.g., jumps). Supplying a value selects margin_ratio_mode \"manual\" unless margin_ratio_mode is set explicitly; overrides the legacy margin_ratio on this axis."Input schema / properties / requestBody / properties / model / defaultRemoved value: -"blitz"Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"blitz\" (Blitz): Visual Quality: 4/10 · Motion Stability: 8/10 · 1.9 credits/s, min 4\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 2.6 credits/s, min 4\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 3.1 credits/s, min 4\n- \"forge\" (Forge): 1.5 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min 4\nLegacy aliases: \"standard\" → blitz."New value: +"Model to use. Available models:\n- \"blitz\" (Blitz): Visual Quality: 4/10 · Motion Stability: 8/10 · 1.9 credits/s, min 4\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 2.6 credits/s, min 4\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 3.1 credits/s, min 4\n- \"forge\" (Forge): 1.5 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min 4\nLegacy aliases: \"standard\" → blitz. Default: \"blitz\"."Input schema / properties / requestBody / properties / spritesheet_with_background / defaultRemoved value: -falseInput schema / properties / requestBody / properties / spritesheet_with_background / descriptionPrevious value: -"When true, also returns the spritesheet with background intact (before background removal). Useful for manually fixing background removal issues. The with-background spritesheet URL will be in spritesheet_with_background_url."New value: +"When true, also returns the spritesheet with background intact (before background removal). Useful for manually fixing background removal issues. The with-background spritesheet URL will be in spritesheet_with_background_url. Default: false."animateSpriteKeyframes28 fields changedInput schema / properties / requestBody / properties / augment_prompt / defaultRemoved value: -trueInput schema / properties / requestBody / properties / augment_prompt / descriptionPrevious value: -"Augment the prompt behind the scenes. Disable to have more control."New value: +"Augment the prompt behind the scenes. Disable to have more control. Default: true."Input schema / properties / requestBody / properties / crop / defaultRemoved value: -falseInput schema / properties / requestBody / properties / crop / descriptionPrevious value: -"Crop sprite frames to fit content. Results in smaller spritesheets but inconsistent frame sizes across different animations."New value: +"Crop sprite frames to fit content. Results in smaller spritesheets but inconsistent frame sizes across different animations. Default: false."Input schema / properties / requestBody / properties / duration / defaultRemoved value: -3Input schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- blitz: 1.2, 1.5, 2, 2.5, 3, 3.5, 4\n- eagle: 1, 2, 3, 4\n- eagle-audio: 1, 2, 3, 4\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4"New value: +"Duration in seconds. Available values depend on the model:\n- blitz: 1.2, 1.5, 2, 2.5, 3, 3.5, 4\n- eagle: 1, 2, 3, 4\n- eagle-audio: 1, 2, 3, 4\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4 Default: 3."Input schema / properties / requestBody / properties / frame_size / defaultRemoved value: -0Input schema / properties / requestBody / properties / frame_size / descriptionPrevious value: -"Size of each frame in pixels (width and height). 0 is for maximum resolution. -1 is for AI 1.5x upscaling. -9 is for matching the size and position of the input frame. Accepted values: 32, 64, 96, 128, 192, 256, 384, 0, -1, -9."New value: +"Size of each frame in pixels (width and height). 0 is for maximum resolution. -1 is for AI 1.5x upscaling. -9 is for matching the size and position of the input frame. Accepted values: 32, 64, 96, 128, 192, 256, 384, 0, -1, -9. Default: 0."Input schema / properties / requestBody / properties / frames / defaultRemoved value: -36Input schema / properties / requestBody / properties / frames / descriptionPrevious value: -"Number of frames in the output spritesheet. Accepted values: 4, 9, 16, 25, 36, 49, 64."New value: +"Number of frames in the output spritesheet. Accepted values: 4, 9, 16, 25, 36, 49, 64. Default: 36."Input schema / properties / requestBody / properties / gif / defaultRemoved value: -falseInput schema / properties / requestBody / properties / gif / descriptionPrevious value: -"When true, generates an animated GIF from the spritesheet and returns it in gif_url. Disabled by default to reduce response time."New value: +"When true, generates an animated GIF from the spritesheet and returns it in gif_url. Disabled by default to reduce response time. Default: false."Input schema / properties / requestBody / properties / image_type / defaultRemoved value: -"sprite"Input schema / properties / requestBody / properties / image_type / descriptionPrevious value: -"Type of sprite being animated. Affects generation parameters and styling."New value: +"Type of sprite being animated. Affects generation parameters and styling. Default: \"sprite\"."Input schema / properties / requestBody / properties / individual_frames / defaultRemoved value: -falseInput schema / properties / requestBody / properties / individual_frames / descriptionPrevious value: -"When true, extracts each frame from the spritesheet as an individual image and returns the URLs in individual_frame_urls."New value: +"When true, extracts each frame from the spritesheet as an individual image and returns the URLs in individual_frame_urls. Default: false."Input schema / properties / requestBody / properties / loop / defaultRemoved value: -trueInput schema / properties / requestBody / properties / loop / descriptionPrevious value: -"Trim the animation at the beginning or end to create a seamless loop. Not guaranteed to produce a perfect loop."New value: +"Trim the animation at the beginning or end to create a seamless loop. Not guaranteed to produce a perfect loop. Default: true."Input schema / properties / requestBody / properties / margin_ratio / deprecatedAdded value: +trueInput schema / properties / requestBody / properties / margin_ratio / descriptionPrevious value: -"Deprecated - prefer margin_ratio_horizontal / margin_ratio_vertical. Amount of padding around the sprite as a ratio (0.0 to 1.0), applied to both axes (equivalent to setting both per-axis params to this value). Only used when margin_ratio_mode is \"manual\". Cannot be combined with the per-axis params: providing both fails with HTTP 400."New value: +"Deprecated: prefer margin_ratio_horizontal / margin_ratio_vertical. Amount of padding around the sprite as a ratio (0.0 to 1.0). Sets both axes to this value. A per-axis value, when also given, overrides this for that axis. Supplying any margin value selects margin_ratio_mode \"manual\" unless margin_ratio_mode is set explicitly."Input schema / properties / requestBody / properties / margin_ratio_horizontal / descriptionPrevious value: -"Horizontal padding around the sprite as a ratio (0.0 to 1.0). Only used when margin_ratio_mode is \"manual\". Useful for animations that extend sideways (e.g., sword slashes, punches). Cannot be combined with the legacy margin_ratio param."New value: +"Horizontal padding around the sprite as a ratio (0.0 to 1.0). Useful for animations that extend sideways (e.g., sword slashes, punches). Supplying a value selects margin_ratio_mode \"manual\" unless margin_ratio_mode is set explicitly; overrides the legacy margin_ratio on this axis."Input schema / properties / requestBody / properties / margin_ratio_mode / defaultRemoved value: -"auto"Input schema / properties / requestBody / properties / margin_ratio_mode / descriptionPrevious value: -"Controls how margins are applied around the sprite. \"manual\" requires margin_ratio_horizontal and/or margin_ratio_vertical (or the legacy margin_ratio); sending \"manual\" with no margin value fails with HTTP 400."New value: +"Controls how margins are applied around the sprite. Omit it and send margin_ratio_horizontal / margin_ratio_vertical to get \"manual\" automatically. \"manual\" requires margin_ratio_horizontal and/or margin_ratio_vertical (or the legacy margin_ratio); sending \"manual\" with no margin value fails with HTTP 400. Sending \"auto\" or \"none\" explicitly together with a margin value fails with HTTP 400 (the value would be ignored). Default: \"auto\"."Input schema / properties / requestBody / properties / margin_ratio_vertical / descriptionPrevious value: -"Vertical padding around the sprite as a ratio (0.0 to 1.0). Only used when margin_ratio_mode is \"manual\". Useful for animations that extend up or down (e.g., jumps). Cannot be combined with the legacy margin_ratio param."New value: +"Vertical padding around the sprite as a ratio (0.0 to 1.0). Useful for animations that extend up or down (e.g., jumps). Supplying a value selects margin_ratio_mode \"manual\" unless margin_ratio_mode is set explicitly; overrides the legacy margin_ratio on this axis."Input schema / properties / requestBody / properties / model / defaultRemoved value: -"forge"Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"blitz\" (Blitz): Visual Quality: 4/10 · Motion Stability: 8/10 · 1.9 credits/s, min 4\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 2.6 credits/s, min 4\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 3.1 credits/s, min 4\n- \"forge\" (Forge): 1.5 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min 4\nLegacy aliases: \"standard\" → blitz."New value: +"Model to use. Available models:\n- \"blitz\" (Blitz): Visual Quality: 4/10 · Motion Stability: 8/10 · 1.9 credits/s, min 4\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 2.6 credits/s, min 4\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 3.1 credits/s, min 4\n- \"forge\" (Forge): 1.5 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min 4\nLegacy aliases: \"standard\" → blitz. Default: \"forge\"."Input schema / properties / requestBody / properties / spritesheet_with_background / defaultRemoved value: -falseInput schema / properties / requestBody / properties / spritesheet_with_background / descriptionPrevious value: -"When true, also returns the spritesheet with background intact (before background removal). Useful for manually fixing background removal issues. The with-background spritesheet URL will be in spritesheet_with_background_url."New value: +"When true, also returns the spritesheet with background intact (before background removal). Useful for manually fixing background removal issues. The with-background spritesheet URL will be in spritesheet_with_background_url. Default: false."create3DModel6 fields changedInput schema / properties / requestBody / properties / target_num_faces / defaultRemoved value: -50000Input schema / properties / requestBody / properties / target_num_faces / descriptionPrevious value: -"Maximum triangle count for the mesh (1000-200000)"New value: +"Maximum triangle count for the mesh (1000-200000) Default: 50000."Input schema / properties / requestBody / properties / texture_size / defaultRemoved value: -2048Input schema / properties / requestBody / properties / texture_size / descriptionPrevious value: -"Texture resolution in pixels Accepted values: 1024, 2048."New value: +"Texture resolution in pixels Accepted values: 1024, 2048. Default: 2048."Input schema / properties / requestBody / properties / texture_type / defaultRemoved value: -"pbr"Input schema / properties / requestBody / properties / texture_type / descriptionPrevious value: -"Texture type"New value: +"Texture type Default: \"pbr\"."createAmbiance6 fields changedInput schema / properties / requestBody / properties / augment_prompt / defaultRemoved value: -trueInput schema / properties / requestBody / properties / augment_prompt / descriptionPrevious value: -"Augment the prompt behind the scenes. Disable to have more control."New value: +"Augment the prompt behind the scenes. Disable to have more control. Default: true."Input schema / properties / requestBody / properties / duration / defaultRemoved value: -0Input schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Use 0 for automatic duration based on the description."New value: +"Duration in seconds. Use 0 for automatic duration based on the description. Default: 0."Input schema / properties / requestBody / properties / loop / defaultRemoved value: -trueInput schema / properties / requestBody / properties / loop / descriptionPrevious value: -"Generate an ambiance that loops seamlessly."New value: +"Generate an ambiance that loops seamlessly. Default: true."createAudioTransform6 fields changedInput schema / properties / requestBody / properties / augment_prompt / defaultRemoved value: -trueInput schema / properties / requestBody / properties / augment_prompt / descriptionPrevious value: -"Augment the prompt behind the scenes. Disable to have more control."New value: +"Augment the prompt behind the scenes. Disable to have more control. Default: true."Input schema / properties / requestBody / properties / duration / defaultRemoved value: -0Input schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Use 0 for automatic duration matching the source sample. Accepted values: 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170, 180."New value: +"Duration in seconds. Use 0 for automatic duration matching the source sample. Accepted values: 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170, 180. Default: 0."Input schema / properties / requestBody / properties / modification_strength / defaultRemoved value: -0.6Input schema / properties / requestBody / properties / modification_strength / descriptionPrevious value: -"Controls how strongly the source sample is modified. 0 keeps it close to the original, 1 transforms it fully."New value: +"Controls how strongly the source sample is modified. 0 keeps it close to the original, 1 transforms it fully. Default: 0.6."createImage4 fields changedInput schema / properties / requestBody / properties / augment_prompt / defaultRemoved value: -trueInput schema / properties / requestBody / properties / augment_prompt / descriptionPrevious value: -"Augment the prompt behind the scenes. Disable to have more control."New value: +"Augment the prompt behind the scenes. Disable to have more control. Default: true."Input schema / properties / requestBody / properties / n / defaultRemoved value: -1Input schema / properties / requestBody / properties / n / descriptionPrevious value: -"Number of image variations to generate"New value: +"Number of image variations to generate Default: 1."createMusic4 fields changedInput schema / properties / requestBody / properties / augment_prompt / defaultRemoved value: -trueInput schema / properties / requestBody / properties / augment_prompt / descriptionPrevious value: -"Augment the prompt behind the scenes. Disable to have more control."New value: +"Augment the prompt behind the scenes. Disable to have more control. Default: true."Input schema / properties / requestBody / properties / duration / defaultRemoved value: -0Input schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Use 0 for automatic duration based on the description. Accepted values: 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170, 180."New value: +"Duration in seconds. Use 0 for automatic duration based on the description. Accepted values: 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170, 180. Default: 0."createSoundEffect6 fields changedInput schema / properties / requestBody / properties / augment_prompt / defaultRemoved value: -trueInput schema / properties / requestBody / properties / augment_prompt / descriptionPrevious value: -"Augment the prompt behind the scenes. Disable to have more control."New value: +"Augment the prompt behind the scenes. Disable to have more control. Default: true."Input schema / properties / requestBody / properties / duration / defaultRemoved value: -0Input schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Use 0 for automatic duration based on the description."New value: +"Duration in seconds. Use 0 for automatic duration based on the description. Default: 0."Input schema / properties / requestBody / properties / loop / defaultRemoved value: -falseInput schema / properties / requestBody / properties / loop / descriptionPrevious value: -"Generate a sound effect that loops seamlessly."New value: +"Generate a sound effect that loops seamlessly. Default: false."createVideo6 fields changedInput schema / properties / requestBody / properties / augment_prompt / defaultRemoved value: -trueInput schema / properties / requestBody / properties / augment_prompt / descriptionPrevious value: -"Augment the prompt behind the scenes. Disable to have more control."New value: +"Augment the prompt behind the scenes. Disable to have more control. Default: true."Input schema / properties / requestBody / properties / duration / defaultRemoved value: -5Input schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- blitz: 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- eagle-audio: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4"New value: +"Duration in seconds. Available values depend on the model:\n- blitz: 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- eagle-audio: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4 Default: 5."Input schema / properties / requestBody / properties / model / defaultRemoved value: -"eagle"Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"blitz\" (Blitz): Visual Quality: 4/10 · Motion Stability: 8/10 · 1 credits/s\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.3 credits/s\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.8 credits/s\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4\nLegacy aliases: \"standard\" → blitz."New value: +"Model to use. Available models:\n- \"blitz\" (Blitz): Visual Quality: 4/10 · Motion Stability: 8/10 · 1 credits/s\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.3 credits/s\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.8 credits/s\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4\nLegacy aliases: \"standard\" → blitz. Default: \"eagle\"."createVideoFromReferences6 fields changedInput schema / properties / requestBody / properties / aspect_ratio / defaultRemoved value: -"default"Input schema / properties / requestBody / properties / aspect_ratio / descriptionPrevious value: -"Output aspect ratio. \"default\" lets the model choose."New value: +"Output aspect ratio. \"default\" lets the model choose. Default: \"default\"."Input schema / properties / requestBody / properties / duration / defaultRemoved value: -5Input schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- eagle-audio: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4"New value: +"Duration in seconds. Available values depend on the model:\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- eagle-audio: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4 Default: 5."Input schema / properties / requestBody / properties / model / defaultRemoved value: -"eagle"Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.5 credits/s\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 2 credits/s\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4"New value: +"Model to use. Available models:\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.5 credits/s\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 2 credits/s\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4 Default: \"eagle\"."createVoice4 fields changedInput schema / properties / requestBody / properties / augment_prompt / defaultRemoved value: -trueInput schema / properties / requestBody / properties / augment_prompt / descriptionPrevious value: -"Augment the prompt behind the scenes. Disable to have more control."New value: +"Augment the prompt behind the scenes. Disable to have more control. Default: true."Input schema / properties / requestBody / properties / type / defaultRemoved value: -"human"Input schema / properties / requestBody / properties / type / descriptionPrevious value: -"Type of voice to generate."New value: +"Type of voice to generate. Default: \"human\"."editImage4 fields changedInput schema / properties / requestBody / properties / augment_prompt / defaultRemoved value: -trueInput schema / properties / requestBody / properties / augment_prompt / descriptionPrevious value: -"Augment the prompt behind the scenes. Disable to have more control."New value: +"Augment the prompt behind the scenes. Disable to have more control. Default: true."Input schema / properties / requestBody / properties / n / defaultRemoved value: -1Input schema / properties / requestBody / properties / n / descriptionPrevious value: -"Number of edited variations to generate (1-4)."New value: +"Number of edited variations to generate (1-4). Default: 1."editSpritesheet12 fields changedInput schema / properties / requestBody / properties / edit_mode / defaultRemoved value: -"prompt"Input schema / properties / requestBody / properties / edit_mode / descriptionPrevious value: -"Edit operation to perform."New value: +"Edit operation to perform. Default: \"prompt\"."Input schema / properties / requestBody / properties / gif / defaultRemoved value: -falseInput schema / properties / requestBody / properties / gif / descriptionPrevious value: -"When true, generates an animated GIF from the spritesheet and returns it in gif_url. Disabled by default to reduce response time."New value: +"When true, generates an animated GIF from the spritesheet and returns it in gif_url. Disabled by default to reduce response time. Default: false."Input schema / properties / requestBody / properties / individual_frames / defaultRemoved value: -falseInput schema / properties / requestBody / properties / individual_frames / descriptionPrevious value: -"When true, extracts each frame from the spritesheet as an individual image and returns the URLs in individual_frame_urls."New value: +"When true, extracts each frame from the spritesheet as an individual image and returns the URLs in individual_frame_urls. Default: false."Input schema / properties / requestBody / properties / loop / defaultRemoved value: -trueInput schema / properties / requestBody / properties / loop / descriptionPrevious value: -"Trim the animation at the beginning or end to create a seamless loop."New value: +"Trim the animation at the beginning or end to create a seamless loop. Default: true."Input schema / properties / requestBody / properties / model / defaultRemoved value: -"forge"Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"forge\" (Forge): 2 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4"New value: +"Model to use. Available models:\n- \"forge\" (Forge): 2 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4 Default: \"forge\"."Input schema / properties / requestBody / properties / spritesheet_with_background / defaultRemoved value: -falseInput schema / properties / requestBody / properties / spritesheet_with_background / descriptionPrevious value: -"When true, also returns the spritesheet with background intact (before background removal). The with-background spritesheet URL will be in spritesheet_with_background_url."New value: +"When true, also returns the spritesheet with background intact (before background removal). The with-background spritesheet URL will be in spritesheet_with_background_url. Default: false."editVideo2 fields changedInput schema / properties / requestBody / properties / model / defaultRemoved value: -"eagle"Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 2 credits/s\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4"New value: +"Model to use. Available models:\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 2 credits/s\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4 Default: \"eagle\"."generatePose4 fields changedInput schema / properties / requestBody / properties / augment_prompt / defaultRemoved value: -trueInput schema / properties / requestBody / properties / augment_prompt / descriptionPrevious value: -"Augment the prompt behind the scenes. Disable to have more control."New value: +"Augment the prompt behind the scenes. Disable to have more control. Default: true."Input schema / properties / requestBody / properties / n / defaultRemoved value: -1Input schema / properties / requestBody / properties / n / descriptionPrevious value: -"Number of pose variations to generate (1-4)."New value: +"Number of pose variations to generate (1-4). Default: 1."generateWithStyle6 fields changedInput schema / properties / requestBody / properties / augment_prompt / defaultRemoved value: -trueInput schema / properties / requestBody / properties / augment_prompt / descriptionPrevious value: -"Augment the prompt behind the scenes. Disable to have more control."New value: +"Augment the prompt behind the scenes. Disable to have more control. Default: true."Input schema / properties / requestBody / properties / image_type / defaultRemoved value: -"sprite"Input schema / properties / requestBody / properties / image_type / descriptionPrevious value: -"What kind of image to generate."New value: +"What kind of image to generate. Default: \"sprite\"."Input schema / properties / requestBody / properties / n / defaultRemoved value: -1Input schema / properties / requestBody / properties / n / descriptionPrevious value: -"Number of variations to generate (1-4)."New value: +"Number of variations to generate (1-4). Default: 1."listGenerations6 fields changedInput schema / properties / page_number / defaultRemoved value: -1Input schema / properties / page_number / descriptionPrevious value: -"1-based page number"New value: +"1-based page number Default: 1."Input schema / properties / page_size / defaultRemoved value: -20Input schema / properties / page_size / descriptionPrevious value: -"Items per page (1-100)"New value: +"Items per page (1-100) Default: 20."Input schema / properties / source / defaultRemoved value: -"all"Input schema / properties / source / descriptionPrevious value: -"Which surface the items were generated from: api (your API/MCP generations, last 7 days only), web (your Ludo web studio generations, no time limit), or all (default, both)"New value: +"Which surface the items were generated from: api (your API/MCP generations, last 7 days only), web (your Ludo web studio generations, no time limit), or all (default, both) Default: \"all\"."removeBackground4 fields changedInput schema / properties / requestBody / properties / creative_edit / defaultRemoved value: -trueInput schema / properties / requestBody / properties / creative_edit / descriptionPrevious value: -"Higher quality results but the image will not be exactly the same as the input."New value: +"Higher quality results but the image will not be exactly the same as the input. Default: true."Input schema / properties / requestBody / properties / crop / defaultRemoved value: -falseInput schema / properties / requestBody / properties / crop / descriptionPrevious value: -"Whether to crop/trim the result to fit the content."New value: +"Whether to crop/trim the result to fit the content. Default: false."rigModel4 fields changedInput schema / properties / requestBody / properties / joint_naming / defaultRemoved value: -"smpl"Input schema / properties / requestBody / properties / joint_naming / descriptionPrevious value: -"Bone naming convention for the identified joints: smpl (default), mixamo (Unity's humanoid auto-mapper), humanik (same names unprefixed - Maya/MotionBuilder/FBX), unreal (UE mannequin), godot (SkeletonProfileHumanoid), rigify (Blender) or vroid (VRM). Purely a relabel - the skeleton is identical."New value: +"Bone naming convention for the identified joints: smpl (default), mixamo (Unity's humanoid auto-mapper), humanik (same names unprefixed - Maya/MotionBuilder/FBX), unreal (UE mannequin), godot (SkeletonProfileHumanoid), rigify (Blender) or vroid (VRM). Purely a relabel - the skeleton is identical. Default: \"smpl\"."Input schema / properties / requestBody / properties / rig_type / defaultRemoved value: -"general"Input schema / properties / requestBody / properties / rig_type / descriptionPrevious value: -"Which skeleton to build: general (any asset), humanoid (anime-style characters), game (classic game-character rigs), or the pinned humanoid templates with named joints required for the animation preset library - humanoid_template (22 joints) / humanoid_template_hands (52, five fingers per hand). Templates only suit two-armed, two-legged characters."New value: +"Which skeleton to build: general (any asset), humanoid (anime-style characters), game (classic game-character rigs), or the pinned humanoid templates with named joints required for the animation preset library - humanoid_template (22 joints) / humanoid_template_hands (52, five fingers per hand). Templates only suit two-armed, two-legged characters. Default: \"general\"."rotateSprite4 fields changedInput schema / properties / requestBody / properties / augment_prompt / defaultRemoved value: -trueInput schema / properties / requestBody / properties / augment_prompt / descriptionPrevious value: -"Augment the prompt behind the scenes. Disable to have more control."New value: +"Augment the prompt behind the scenes. Disable to have more control. Default: true."Input schema / properties / requestBody / properties / n / defaultRemoved value: -1Input schema / properties / requestBody / properties / n / descriptionPrevious value: -"Number of variations to generate (1-4)."New value: +"Number of variations to generate (1-4). Default: 1."transferMotion26 fields changedInput schema / properties / requestBody / properties / crop / defaultRemoved value: -falseInput schema / properties / requestBody / properties / crop / descriptionPrevious value: -"Crop sprite frames to fit content. Results in smaller spritesheets but inconsistent frame sizes across different animations."New value: +"Crop sprite frames to fit content. Results in smaller spritesheets but inconsistent frame sizes across different animations. Default: false."Input schema / properties / requestBody / properties / duration / defaultRemoved value: -1.5Input schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. If the reference video is longer, it will be compressed to this duration. Available values depend on the model:\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4\n- tango: 1, 1.5, 2, 2.5, 3, 3.5, 4"New value: +"Duration in seconds. If the reference video is longer, it will be compressed to this duration. Available values depend on the model:\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4\n- tango: 1, 1.5, 2, 2.5, 3, 3.5, 4 Default: 1.5."Input schema / properties / requestBody / properties / frame_size / defaultRemoved value: -0Input schema / properties / requestBody / properties / frame_size / descriptionPrevious value: -"Size of each frame in pixels (width and height). 0 is for maximum resolution. Accepted values: 32, 64, 96, 128, 192, 256, 384, 0."New value: +"Size of each frame in pixels (width and height). 0 is for maximum resolution. Accepted values: 32, 64, 96, 128, 192, 256, 384, 0. Default: 0."Input schema / properties / requestBody / properties / frames / defaultRemoved value: -36Input schema / properties / requestBody / properties / frames / descriptionPrevious value: -"Number of frames in the output spritesheet. Accepted values: 4, 9, 16, 25, 36, 49, 64."New value: +"Number of frames in the output spritesheet. Accepted values: 4, 9, 16, 25, 36, 49, 64. Default: 36."Input schema / properties / requestBody / properties / gif / defaultRemoved value: -falseInput schema / properties / requestBody / properties / gif / descriptionPrevious value: -"When true, generates an animated GIF from the spritesheet and returns it in gif_url. Disabled by default to reduce response time."New value: +"When true, generates an animated GIF from the spritesheet and returns it in gif_url. Disabled by default to reduce response time. Default: false."Input schema / properties / requestBody / properties / individual_frames / defaultRemoved value: -falseInput schema / properties / requestBody / properties / individual_frames / descriptionPrevious value: -"When true, extracts each frame from the spritesheet as an individual image and returns the URLs in individual_frame_urls."New value: +"When true, extracts each frame from the spritesheet as an individual image and returns the URLs in individual_frame_urls. Default: false."Input schema / properties / requestBody / properties / loop / defaultRemoved value: -trueInput schema / properties / requestBody / properties / loop / descriptionPrevious value: -"Trim the animation at the beginning or end to create a seamless loop."New value: +"Trim the animation at the beginning or end to create a seamless loop. Default: true."Input schema / properties / requestBody / properties / margin_ratio / defaultRemoved value: -0.15Input schema / properties / requestBody / properties / margin_ratio / deprecatedAdded value: +trueInput schema / properties / requestBody / properties / margin_ratio / descriptionPrevious value: -"Deprecated - prefer margin_ratio_horizontal / margin_ratio_vertical. Amount of padding around the sprite as a ratio (0.0 to 1.0), applied to both axes (equivalent to setting both per-axis params to this value). Only used when margin_ratio_mode is \"manual\". Cannot be combined with the per-axis params: providing both fails with HTTP 400. Defaults to 0.15 when no margin param is provided."New value: +"Deprecated: prefer margin_ratio_horizontal / margin_ratio_vertical. Amount of padding around the sprite as a ratio (0.0 to 1.0). Sets both axes to this value. A per-axis value, when also given, overrides this for that axis. Defaults to 0.15 when no margin value is given at all."Input schema / properties / requestBody / properties / margin_ratio / exampleRemoved value: -0.15Input schema / properties / requestBody / properties / margin_ratio_horizontal / descriptionPrevious value: -"Horizontal padding around the sprite as a ratio (0.0 to 1.0). Only used when margin_ratio_mode is \"manual\". Useful for animations that extend sideways (e.g., sword slashes, punches). Cannot be combined with the legacy margin_ratio param."New value: +"Horizontal padding around the sprite as a ratio (0.0 to 1.0). Useful for animations that extend sideways (e.g., sword slashes, punches). Overrides the legacy margin_ratio on this axis."Input schema / properties / requestBody / properties / margin_ratio_mode / defaultRemoved value: -"manual"Input schema / properties / requestBody / properties / margin_ratio_mode / descriptionPrevious value: -"Controls how margins are applied around the sprite."New value: +"Controls how margins are applied around the sprite. Defaults to \"manual\". Sending \"none\" explicitly together with a margin value fails with HTTP 400 (the value would be ignored). Default: \"manual\"."Input schema / properties / requestBody / properties / margin_ratio_vertical / descriptionPrevious value: -"Vertical padding around the sprite as a ratio (0.0 to 1.0). Only used when margin_ratio_mode is \"manual\". Useful for animations that extend up or down (e.g., jumps). Cannot be combined with the legacy margin_ratio param."New value: +"Vertical padding around the sprite as a ratio (0.0 to 1.0). Useful for animations that extend up or down (e.g., jumps). Overrides the legacy margin_ratio on this axis."Input schema / properties / requestBody / properties / model / defaultRemoved value: -"forge"Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"forge\" (Forge): 2 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4\n- \"tango\" (Tango): 4 credits/s, min 4"New value: +"Model to use. Available models:\n- \"forge\" (Forge): 2 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4\n- \"tango\" (Tango): 4 credits/s, min 4 Default: \"forge\"."Input schema / properties / requestBody / properties / spritesheet_with_background / defaultRemoved value: -falseInput schema / properties / requestBody / properties / spritesheet_with_background / descriptionPrevious value: -"When true, also returns the spritesheet with background intact (before background removal). Useful for manually fixing background removal issues. The with-background spritesheet URL will be in spritesheet_with_background_url."New value: +"When true, also returns the spritesheet with background intact (before background removal). Useful for manually fixing background removal issues. The with-background spritesheet URL will be in spritesheet_with_background_url. Default: false."animateSprite1 field changedInput schema / properties / requestBody / properties / margin_ratio_mode / descriptionPrevious value: -"Controls how margins are applied around the sprite."New value: +"Controls how margins are applied around the sprite. \"manual\" requires margin_ratio_horizontal and/or margin_ratio_vertical (or the legacy margin_ratio); sending \"manual\" with no margin value fails with HTTP 400."animateSpriteKeyframes1 field changedInput schema / properties / requestBody / properties / margin_ratio_mode / descriptionPrevious value: -"Controls how margins are applied around the sprite."New value: +"Controls how margins are applied around the sprite. \"manual\" requires margin_ratio_horizontal and/or margin_ratio_vertical (or the legacy margin_ratio); sending \"manual\" with no margin value fails with HTTP 400."animateSprite5 fields changedInput schema / properties / requestBody / properties / crop / defaultAdded value: +falseInput schema / properties / requestBody / properties / crop / exampleAdded value: +falseInput schema / properties / requestBody / properties / duration / defaultAdded value: +3Input schema / properties / requestBody / properties / duration / exampleAdded value: +3Input schema / properties / requestBody / properties / image_type / defaultAdded value: +"sprite"animateSpriteKeyframes5 fields changedInput schema / properties / requestBody / properties / crop / defaultAdded value: +falseInput schema / properties / requestBody / properties / crop / exampleAdded value: +falseInput schema / properties / requestBody / properties / duration / defaultAdded value: +3Input schema / properties / requestBody / properties / duration / exampleAdded value: +3Input schema / properties / requestBody / properties / image_type / defaultAdded value: +"sprite"createAmbiance1 field changedInput schema / properties / requestBody / properties / loopAdded value: +{
+ "default": true,
+ "description": "Generate an ambiance that loops seamlessly.",
+ "example": true,
+ "type": "boolean"
+}createAudioTransform2 fields changedInput schema / properties / requestBody / properties / modification_strength / defaultPrevious value: -0.5New value: +0.6Input schema / properties / requestBody / properties / modification_strength / examplePrevious value: -0.5New value: +0.6createVideo3 fields changedInput schema / properties / requestBody / properties / duration / defaultAdded value: +5Input schema / properties / requestBody / properties / model / defaultPrevious value: -"blitz"New value: +"eagle"Input schema / properties / requestBody / properties / model / examplePrevious value: -"blitz"New value: +"eagle"transferMotion5 fields changedInput schema / properties / requestBody / properties / crop / defaultAdded value: +falseInput schema / properties / requestBody / properties / crop / exampleAdded value: +falseInput schema / properties / requestBody / properties / loop / defaultAdded value: +trueInput schema / properties / requestBody / properties / loop / exampleAdded value: +trueInput schema / properties / requestBody / properties / model / defaultPrevious value: -"tango"New value: +"forge"animateSprite1 field changedInput schema / properties / requestBody / properties / margin_ratio / descriptionPrevious value: -"Deprecated — prefer margin_ratio_horizontal / margin_ratio_vertical. Amount of padding around the sprite as a ratio (0.0 to 1.0), applied to both axes (equivalent to setting both per-axis params to this value). Only used when margin_ratio_mode is \"manual\". Cannot be combined with the per-axis params: providing both fails with HTTP 400."New value: +"Deprecated - prefer margin_ratio_horizontal / margin_ratio_vertical. Amount of padding around the sprite as a ratio (0.0 to 1.0), applied to both axes (equivalent to setting both per-axis params to this value). Only used when margin_ratio_mode is \"manual\". Cannot be combined with the per-axis params: providing both fails with HTTP 400."animateSpriteKeyframes2 fields changedInput schema / properties / requestBody / descriptionPrevious value: -"Payload for generating an animated spritesheet that interpolates through up to three fixed keyframes (initial / middle / final). Runs on the Forge family — the only models supporting a middle keyframe. Input images can be provided in base64 or URL. At least one of initial_image or middle_image must be provided."New value: +"Payload for generating an animated spritesheet that interpolates through up to three fixed keyframes (initial / middle / final). Runs on the Forge family - the only models supporting a middle keyframe. Input images can be provided in base64 or URL. At least one of initial_image or middle_image must be provided."Input schema / properties / requestBody / properties / margin_ratio / descriptionPrevious value: -"Deprecated — prefer margin_ratio_horizontal / margin_ratio_vertical. Amount of padding around the sprite as a ratio (0.0 to 1.0), applied to both axes (equivalent to setting both per-axis params to this value). Only used when margin_ratio_mode is \"manual\". Cannot be combined with the per-axis params: providing both fails with HTTP 400."New value: +"Deprecated - prefer margin_ratio_horizontal / margin_ratio_vertical. Amount of padding around the sprite as a ratio (0.0 to 1.0), applied to both axes (equivalent to setting both per-axis params to this value). Only used when margin_ratio_mode is \"manual\". Cannot be combined with the per-axis params: providing both fails with HTTP 400."editSpritesheet1 field changedInput schema / properties / requestBody / descriptionPrevious value: -"Payload for editing a previously generated spritesheet. edit_mode selects the operation — prompt-driven edit (default), outpaint, or loop fixing."New value: +"Payload for editing a previously generated spritesheet. edit_mode selects the operation - prompt-driven edit (default), outpaint, or loop fixing."rigModel2 fields changedInput schema / properties / requestBody / properties / joint_naming / descriptionPrevious value: -"Bone naming convention for the identified joints: smpl (default), mixamo (Unity's humanoid auto-mapper), humanik (same names unprefixed — Maya/MotionBuilder/FBX), unreal (UE mannequin), godot (SkeletonProfileHumanoid), rigify (Blender) or vroid (VRM). Purely a relabel — the skeleton is identical."New value: +"Bone naming convention for the identified joints: smpl (default), mixamo (Unity's humanoid auto-mapper), humanik (same names unprefixed - Maya/MotionBuilder/FBX), unreal (UE mannequin), godot (SkeletonProfileHumanoid), rigify (Blender) or vroid (VRM). Purely a relabel - the skeleton is identical."Input schema / properties / requestBody / properties / rig_type / descriptionPrevious value: -"Which skeleton to build: general (any asset), humanoid (anime-style characters), game (classic game-character rigs), or the pinned humanoid templates with named joints required for the animation preset library — humanoid_template (22 joints) / humanoid_template_hands (52, five fingers per hand). Templates only suit two-armed, two-legged characters."New value: +"Which skeleton to build: general (any asset), humanoid (anime-style characters), game (classic game-character rigs), or the pinned humanoid templates with named joints required for the animation preset library - humanoid_template (22 joints) / humanoid_template_hands (52, five fingers per hand). Templates only suit two-armed, two-legged characters."transferMotion1 field changedInput schema / properties / requestBody / properties / margin_ratio / descriptionPrevious value: -"Deprecated — prefer margin_ratio_horizontal / margin_ratio_vertical. Amount of padding around the sprite as a ratio (0.0 to 1.0), applied to both axes (equivalent to setting both per-axis params to this value). Only used when margin_ratio_mode is \"manual\". Cannot be combined with the per-axis params: providing both fails with HTTP 400. Defaults to 0.15 when no margin param is provided."New value: +"Deprecated - prefer margin_ratio_horizontal / margin_ratio_vertical. Amount of padding around the sprite as a ratio (0.0 to 1.0), applied to both axes (equivalent to setting both per-axis params to this value). Only used when margin_ratio_mode is \"manual\". Cannot be combined with the per-axis params: providing both fails with HTTP 400. Defaults to 0.15 when no margin param is provided."animate3DModel1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided id to retrieve the result later."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."animate3DModelPreset1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided id to retrieve the result later."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."animateSprite1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."animateSpriteKeyframes1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."cancelApiJobcreate3DModel1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."createAmbiance1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."createAudioTransform1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."createImage1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."createMusic1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."createSoundEffect1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."createSpeech1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."createSpeechPreset1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."createVideo1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."createVideoFromReferences1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."createVoice1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."editImage1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."editSpritesheet1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."editVideo1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."generatePose1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."generateWithStyle1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."get3DModelResultsgetApiJobgetAudioResultsgetImageResultsgetSpriteResultsgetVideoResultslistApiJobslistGenerationsremoveBackground1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."rigModel1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided id to retrieve the result later."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."rotateSprite1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."transferMotion1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."upscaleVideo1 field changedInput schema / properties / requestBody / properties / request_id / descriptionPrevious value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."get3DModelResults1 field changedInput schema / properties / sourceAdded value: +{
+ "default": "api",
+ "description": "Which surface the results were generated from: api (default, your API/MCP generations from the last 7 days), web (your Ludo web studio generations, no time limit), or all",
+ "enum": [
+ "api",
+ "web",
+ "all"
+ ],
+ "type": "string"
+}getAudioResults1 field changedInput schema / properties / sourceAdded value: +{
+ "default": "api",
+ "description": "Which surface the results were generated from: api (default, your API/MCP generations from the last 7 days), web (your Ludo web studio generations, no time limit), or all",
+ "enum": [
+ "api",
+ "web",
+ "all"
+ ],
+ "type": "string"
+}getImageResults1 field changedInput schema / properties / sourceAdded value: +{
+ "default": "api",
+ "description": "Which surface the results were generated from: api (default, your API/MCP generations from the last 7 days), web (your Ludo web studio generations, no time limit), or all",
+ "enum": [
+ "api",
+ "web",
+ "all"
+ ],
+ "type": "string"
+}getSpriteResults1 field changedInput schema / properties / sourceAdded value: +{
+ "default": "api",
+ "description": "Which surface the results were generated from: api (default, your API/MCP generations from the last 7 days), web (your Ludo web studio generations, no time limit), or all",
+ "enum": [
+ "api",
+ "web",
+ "all"
+ ],
+ "type": "string"
+}getVideoResults1 field changedInput schema / properties / sourceAdded value: +{
+ "default": "api",
+ "description": "Which surface the results were generated from: api (default, your API/MCP generations from the last 7 days), web (your Ludo web studio generations, no time limit), or all",
+ "enum": [
+ "api",
+ "web",
+ "all"
+ ],
+ "type": "string"
+}animateSprite4 fields changedInput schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- blitz: 1.2, 1.5, 2, 2.5, 3, 3.5, 4\n- eagle: 1, 2, 3, 4\n- eagle-audio: 1, 2, 3, 4\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4"New value: +"Duration in seconds. Available values depend on the model:\n- blitz: 1.2, 1.5, 2, 2.5, 3, 3.5, 4\n- eagle: 1, 2, 3, 4\n- eagle-audio: 1, 2, 3, 4\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4"Input schema / properties / requestBody / properties / image_type / enumPrevious value: -[
- "sprite",
- "sprite-vfx",
- "ui_asset"
-]New value: +[
+ "sprite",
+ "sprite-vfx",
+ "item-icon",
+ "ui_asset",
+ "logo",
+ "sprite-tiling-horizontal",
+ "sprite-tiling-vertical",
+ "parallax_layer",
+ "tile",
+ "texture",
+ "portrait",
+ "card-art"
+]Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"blitz\" (Blitz): Visual Quality: 4/10 · Motion Stability: 8/10 · 1.9 credits/s, min 4\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 2.6 credits/s, min 4\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 3.1 credits/s, min 4\n- \"forge\" (Forge): 1.5 credits/s, min 4\nLegacy aliases: \"standard\" → blitz."New value: +"Model to use. Available models:\n- \"blitz\" (Blitz): Visual Quality: 4/10 · Motion Stability: 8/10 · 1.9 credits/s, min 4\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 2.6 credits/s, min 4\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 3.1 credits/s, min 4\n- \"forge\" (Forge): 1.5 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min 4\nLegacy aliases: \"standard\" → blitz."Input schema / properties / requestBody / properties / model / enumPrevious value: -[
- "blitz",
- "standard",
- "eagle",
- "eagle-audio",
- "forge"
-]New value: +[
+ "blitz",
+ "standard",
+ "eagle",
+ "eagle-audio",
+ "forge",
+ "forge-pixel"
+]animateSpriteKeyframes4 fields changedInput schema / properties / requestBody / descriptionPrevious value: -"Payload for generating an animated spritesheet that interpolates through up to three fixed keyframes (initial / middle / final). Runs exclusively on the Forge model. Input images can be provided in base64 or URL. At least one of initial_image or middle_image must be provided."New value: +"Payload for generating an animated spritesheet that interpolates through up to three fixed keyframes (initial / middle / final). Runs on the Forge family — the only models supporting a middle keyframe. Input images can be provided in base64 or URL. At least one of initial_image or middle_image must be provided."Input schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Animation length in seconds. This endpoint always runs on the Forge model, so only Forge's durations apply — the source of truth is MODEL_PRICING (credits.js), surfaced via /credits/costs."New value: +"Duration in seconds. Available values depend on the model:\n- blitz: 1.2, 1.5, 2, 2.5, 3, 3.5, 4\n- eagle: 1, 2, 3, 4\n- eagle-audio: 1, 2, 3, 4\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4"Input schema / properties / requestBody / properties / image_type / enumPrevious value: -[
- "sprite",
- "sprite-vfx",
- "ui_asset"
-]New value: +[
+ "sprite",
+ "sprite-vfx",
+ "item-icon",
+ "ui_asset",
+ "logo",
+ "sprite-tiling-horizontal",
+ "sprite-tiling-vertical",
+ "parallax_layer",
+ "tile",
+ "texture",
+ "portrait",
+ "card-art"
+]Input schema / properties / requestBody / properties / modelAdded value: +{
+ "default": "forge",
+ "description": "Model to use. Available models:\n- \"blitz\" (Blitz): Visual Quality: 4/10 · Motion Stability: 8/10 · 1.9 credits/s, min 4\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 2.6 credits/s, min 4\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 3.1 credits/s, min 4\n- \"forge\" (Forge): 1.5 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 1.5 credits/s, min 4\nLegacy aliases: \"standard\" → blitz.",
+ "enum": [
+ "blitz",
+ "standard",
+ "eagle",
+ "eagle-audio",
+ "forge",
+ "forge-pixel"
+ ],
+ "example": "forge",
+ "type": "string"
+}createImage1 field changedInput schema / properties / requestBody / properties / image_type / enumPrevious value: -[
- "generic",
- "screenshot",
- "art",
- "asset",
- "sprite",
- "sprite-vfx",
- "sprite-tiling-horizontal",
- "sprite-tiling-vertical",
- "icon",
- "logo",
- "ui_asset",
- "fixed_background",
- "side_scrolling_background",
- "vertical_scrolling_background",
- "parallax_layer",
- "texture",
- "horizontal_tile",
- "tile",
- "item-icon",
- "portrait",
- "card-art",
- "splash",
- "3d"
-]New value: +[
+ "generic",
+ "screenshot",
+ "art",
+ "asset",
+ "sprite",
+ "sprite-vfx",
+ "sprite-tiling-horizontal",
+ "sprite-tiling-vertical",
+ "icon",
+ "logo",
+ "ui_asset",
+ "fixed_background",
+ "side_scrolling_background",
+ "vertical_scrolling_background",
+ "parallax_layer",
+ "texture",
+ "tile",
+ "item-icon",
+ "portrait",
+ "card-art",
+ "splash",
+ "3d"
+]createVideo3 fields changedInput schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- blitz: 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- eagle-audio: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15"New value: +"Duration in seconds. Available values depend on the model:\n- blitz: 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- eagle-audio: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4"Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"blitz\" (Blitz): Visual Quality: 4/10 · Motion Stability: 8/10 · 1 credits/s\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.3 credits/s\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.8 credits/s\nLegacy aliases: \"standard\" → blitz."New value: +"Model to use. Available models:\n- \"blitz\" (Blitz): Visual Quality: 4/10 · Motion Stability: 8/10 · 1 credits/s\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.3 credits/s\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.8 credits/s\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4\nLegacy aliases: \"standard\" → blitz."Input schema / properties / requestBody / properties / model / enumPrevious value: -[
- "blitz",
- "standard",
- "eagle",
- "eagle-audio"
-]New value: +[
+ "blitz",
+ "standard",
+ "eagle",
+ "eagle-audio",
+ "forge-pixel"
+]createVideoFromReferences3 fields changedInput schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- eagle-audio: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15"New value: +"Duration in seconds. Available values depend on the model:\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- eagle-audio: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4"Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.5 credits/s\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 2 credits/s"New value: +"Model to use. Available models:\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 1.5 credits/s\n- \"eagle-audio\" (Eagle with Audio): Visual Quality: 8/10 · Motion Stability: 5/10 · 2 credits/s\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4"Input schema / properties / requestBody / properties / model / enumPrevious value: -[
- "eagle",
- "eagle-audio"
-]New value: +[
+ "eagle",
+ "eagle-audio",
+ "forge-pixel"
+]editSpritesheet3 fields changedInput schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4"New value: +"Duration in seconds. Available values depend on the model:\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4"Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"forge\" (Forge): 2 credits/s, min 4"New value: +"Model to use. Available models:\n- \"forge\" (Forge): 2 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4"Input schema / properties / requestBody / properties / model / enumPrevious value: -[
- "forge"
-]New value: +[
+ "forge",
+ "forge-pixel"
+]editVideo3 fields changedInput schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. Available values depend on the model:\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15"New value: +"Duration in seconds. Available values depend on the model:\n- eagle: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4"Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 2 credits/s"New value: +"Model to use. Available models:\n- \"eagle\" (Eagle): Visual Quality: 8/10 · Motion Stability: 5/10 · 2 credits/s\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4"Input schema / properties / requestBody / properties / model / enumPrevious value: -[
- "eagle"
-]New value: +[
+ "eagle",
+ "forge-pixel"
+]generateWithStyle1 field changedInput schema / properties / requestBody / properties / image_type / enumPrevious value: -[
- "generic",
- "screenshot",
- "art",
- "asset",
- "sprite",
- "sprite-vfx",
- "sprite-tiling-horizontal",
- "sprite-tiling-vertical",
- "icon",
- "logo",
- "ui_asset",
- "fixed_background",
- "side_scrolling_background",
- "vertical_scrolling_background",
- "parallax_layer",
- "texture",
- "horizontal_tile",
- "tile",
- "item-icon",
- "portrait",
- "card-art",
- "splash",
- "3d"
-]New value: +[
+ "generic",
+ "screenshot",
+ "art",
+ "asset",
+ "sprite",
+ "sprite-vfx",
+ "sprite-tiling-horizontal",
+ "sprite-tiling-vertical",
+ "icon",
+ "logo",
+ "ui_asset",
+ "fixed_background",
+ "side_scrolling_background",
+ "vertical_scrolling_background",
+ "parallax_layer",
+ "texture",
+ "tile",
+ "item-icon",
+ "portrait",
+ "card-art",
+ "splash",
+ "3d"
+]transferMotion3 fields changedInput schema / properties / requestBody / properties / duration / descriptionPrevious value: -"Duration in seconds. If the reference video is longer, it will be compressed to this duration. Available values depend on the model:\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4\n- tango: 1, 1.5, 2, 2.5, 3, 3.5, 4"New value: +"Duration in seconds. If the reference video is longer, it will be compressed to this duration. Available values depend on the model:\n- forge: 1, 1.5, 2, 2.5, 3, 3.5, 4\n- forge-pixel: 1, 1.5, 2, 2.5, 3, 3.5, 4\n- tango: 1, 1.5, 2, 2.5, 3, 3.5, 4"Input schema / properties / requestBody / properties / model / descriptionPrevious value: -"Model to use. Available models:\n- \"forge\" (Forge): 2 credits/s, min 4\n- \"tango\" (Tango): 4 credits/s, min 4"New value: +"Model to use. Available models:\n- \"forge\" (Forge): 2 credits/s, min 4\n- \"forge-pixel\" (Forge Pixel): 2 credits/s, min 4\n- \"tango\" (Tango): 4 credits/s, min 4"Input schema / properties / requestBody / properties / model / enumPrevious value: -[
- "forge",
- "tango"
-]New value: +[
+ "forge",
+ "forge-pixel",
+ "tango"
+]Generate game assets with AI for 2D games, including sprites, tilesets, and animations.
AI game assets for agents: consistent sprites, 2D animations, tiles, maps, music and engine exports.
Turn prompts into production-ready game assets: animated characters, textures, terrain, VFX, HUD.
Discover AI tools for game development — 100+ tools indexed by engine, task, and pricing.
Add one secure layer between your agents and this server.
