Skip to main content
Glama
Sign In

Ludo AI Game Assets

by ai.ludo
OverviewDiscussionsAdmin

Rotate spritesheet to a new view

rotateSpritesheet

Re-render a previously generated sprite animation from a new view: the same motion and timing, seen from a different angle (e.g. a front-facing walk cycle turned into the same walk seen from the back). Pass the spritesheet_url you received from animateSprite, animateSpriteKeyframes, transferMotion, editSpritesheet or an earlier call - it must be a spritesheet you generated within the last 7 days; arbitrary external images are not accepted - and, as image (URL or base64), the character exactly as it must appear in the new view: it becomes the first frame of the animation. To produce that image, call rotateSprite on the animation's first frame (or any image of the character) and pick the view you want. An optional final_image fixes the last frame (it defaults to the first frame, for cyclic or returning animations), and an optional prompt steers the result: the character's facing in the new view ("its back to the camera"), where the action goes ("the kick goes to the left of the frame"), or anything else about the motion. Runs on hydra (default) or hydra-plus (finer detail). The job result is the same sprite result as animateSprite (spritesheet_url, video_url, grid fields, optional GIF and frame URLs). The animation covers the source's own length (up to 5 seconds; a longer source is sped up to fit), so omit duration unless you need to change that. Credits are held for that length when the job is accepted, or for 3 seconds when it is shorter (a new view is a new generation, and hydra generates at least 3 seconds); the final charge is the model's rate × seconds of video generated, never more than was held, and the difference (or everything, if the job fails or is cancelled) is refunded. 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: Cost varies by model and duration (credits/second × duration).

Input Schema

NameRequiredDescriptionDefault
requestBodyYesPayload for re-rendering a previously generated sprite animation from a new view.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / requestBody / properties / model / description
      Previous 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- \"hydra-plus\" (Hydra+): 4 credits/s, shortest duration 3s, so 12 credits minimum · Hydra but with better fine details. Slower generations Default: \"hydra\"."New value: +"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, shortest duration 3s, so 9 credits minimum · Most reliable all-around model, generates audio\n- \"hydra-plus\" (Hydra+): 4 credits/s, shortest duration 3s, so 12 credits minimum · 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\"."
  2. Changed1 schema field changed
    • addedInput schema / properties / requestBody / properties / use_pixel_grid
      Added value: +{
+  "description": "Use the animation's pixel grid if one is detected. true: when Ludo detects a pixel grid with confidence, the sheet is packed on it (logical pixels, scaled up by whole blocks); when none is detected, this has no effect. false: always pack as ordinary art, for when the detected grid is wrong for your asset (for example a smooth sprite coming back as coarse blocks). Ignored for forge-pixel animations, which are always packed on their grid. Unset keeps the source spritesheet's setting (true unless it was made with false).",
+  "type": "boolean"
+}
  3. Changed3 schema fields changed
    • changedInput schema / properties / requestBody / properties / duration / description
      Previous value: -"Duration in seconds. Available values depend on the model:\n- hydra: 3, 3.5, 4, 4.5, 5"New value: +"Duration in seconds. Available values depend on the model:\n- hydra: 3, 3.5, 4, 4.5, 5\n- hydra-plus: 3, 3.5, 4, 4.5, 5"
    • changedInput schema / properties / requestBody / properties / model / description
      Previous 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 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- \"hydra-plus\" (Hydra+): 4 credits/s, shortest duration 3s, so 12 credits minimum · Hydra but with better fine details. Slower generations Default: \"hydra\"."
    • changedInput schema / properties / requestBody / properties / model / enum
      Previous value: -[
-  "hydra"
-]New value: +[
+  "hydra",
+  "hydra-plus"
+]
  4. Changed1 schema field changed
    • changedInput schema / properties / requestBody / properties / model / description
      Previous value: -"Model to use. Available models:\n- \"hydra\" (Hydra): 3 credits/s, min charge 9 credits · Most capable all-around model, generates audio 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 Default: \"hydra\"."
  5. Changed1 schema field changed
    • changedInput schema / properties / requestBody / properties / frame_size / description
      Previous 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."New value: +"Size of the sprite in pixels, not of the frame - it sets how big the character is drawn, and each frame also holds the space around it, so frames come out larger than this value. 0 is for maximum resolution. Omit to keep the source spritesheet's setting. Accepted values: 32, 64, 96, 128, 192, 256, 384, 0."
  6. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover the safety profile (not read-only, not destructive, not open-world), so the description carries the operational burden and does: credit holding at accept time, minimum 3-second hold floor, final charge = rate × seconds generated, refunds on failure or cancellation, async job returning {id, status} with polling via getApiJob, and the 7-day source restriction. That is exactly the kind of cost and side-effect context an agent needs before committing credits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the source-spritesheet constraint are front-loaded, and the prose is dense with no filler sentences. It is a single long block, though, and the trailing 'Credits: Cost varies by model and duration' line restates cost information already given in detail earlier, which is a small redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nested-payload, credit-consuming async generation tool with no output schema, the description supplies the full contract: required inputs and their provenance, optional steering parameters, model choice and cost behavior, the 5-second cap, the async job/polling pattern, and even the shape of the result (spritesheet_url, video_url, grid fields, optional GIF/frame URLs). Nothing an agent needs before calling it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description goes beyond by explaining that the image becomes the first frame, that final_image defaults to the first frame for cyclic animations, that prompt controls facing/action placement, and that duration should normally be omitted because the output inherits the source length (capped at 5s, longer sources sped up). It leaves the packaging flags (gif, crop, frames, frame_size, use_pixel_grid) entirely to the schema, which is acceptable given full coverage.

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

Purpose5/5

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

States a specific verb and resource — re-render a previously generated sprite animation from a new view — and pins it down with a concrete example (front-facing walk cycle turned into the same walk from the back). It also distinguishes itself from nearby siblings by naming rotateSprite as the way to produce the input image and by listing the source tools (animateSprite, transferMotion, editSpritesheet) whose spritesheet_url it consumes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when this applies (the same motion and timing seen from a different angle), what input is accepted (a spritesheet you generated in the last 7 days; external images rejected), how to build the required image (call rotateSprite on the first frame), and when to omit duration. It even routes between model options and explains that prompt can steer facing or action direction, leaving little to inference.

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

All Ludo AI Game Assets toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources