Skip to main content
Glama
Sign In

Ludo AI Game Assets

by ai.ludo
OverviewDiscussionsAdmin

Create directional sprites

createDirectionalSprites

Directional Sprites: render a 3D model into one spritesheet per direction, in a style. Pass the GLB in model (URL or base64; rigged, to animate it - see create3DModel with rig, or rigModel) and at most one animation: animation_url (the glb_url of an animation from animate3DModel or animate3DModelPreset, made for this model), preset_id (a preset from listAnimationPresets, retargeted onto the model; any rig type can take one, though retargeting does not succeed on every model, and when it does not the call returns an error) or model_animation (the name of an animation the GLB itself carries). With no animation each sheet is a single frame. directions are where the camera stands around a character facing S (up to 8); every direction is rendered together, on the same frame size, scale and floor, so the sheets line up. Pick the style with listDirectionalSpriteStyles (style_id, and style_params for its settings) and check it with previewDirectionalSprites first. The job result is one sheet per direction, in the order asked, each with its spritesheet_url, grid fields, fps and render_3d. Credits are held for every direction when the job is accepted and charged for the sheets that come back; a failed or cancelled job is refunded. Pass an optional request_id to tag the sheets for later retrieval via listGenerations (type spritesheet). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).

Credits: This endpoint consumes 1 credit per direction (one sheet each).

Input Schema

NameRequiredDescriptionDefault
requestBodyYesPayload for rendering a 3D model as directional sprite sheets

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / requestBody / properties / animation_url / description
      Previous value: -"An animation for the model, as a URL or base64-encoded GLB file - the glb_url of an animation from animate3DModel or animate3DModelPreset, made for this model's skeleton. At most one of animation_url, preset_id and model_animation."New value: +"An animation for the model, as a URL or base64-encoded GLB file - the glb_url of an animation from animate3DModel or animate3DModelPreset, made for this model's skeleton. At most one of animation_url, preset_id and model_animation. Up to 30MB; a larger file is rejected with HTTP 400."
    • changedInput schema / properties / requestBody / properties / model / description
      Previous value: -"The 3D model, as a URL or base64-encoded GLB file (not an AI model name). Rigged, to animate it."New value: +"The 3D model, as a URL or base64-encoded GLB file (not an AI model name). Rigged, to animate it. Up to 30MB; a larger file is rejected with HTTP 400."
  2. Changed1 schema field changed
    • addedInput schema / properties / requestBody / description
      Added value: +"Payload for rendering a 3D model as directional sprite sheets"
  3. Changed1 schema field changed
    • changedInput schema / properties / requestBody / properties / preset_id / description
      Previous value: -"An animation preset id from listAnimationPresets, retargeted onto the model. The model needs a humanoid_template or humanoid_template_hands rig. At most one of animation_url, preset_id and model_animation."New value: +"An animation preset id from listAnimationPresets, retargeted onto the model. Any rig type can take one; when the preset cannot be retargeted onto the model, the call returns an error. At most one of animation_url, preset_id and model_animation."
  4. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only cover the read/write/destructive profile, so the description carries the rest, and it does: async job contract returning {id, status} with polling via getApiJob, credits held per direction on acceptance and refunded on failure or cancellation, and an explicit error case when a preset cannot be retargeted. It does not describe the sheet's grid/fps fields in prose, but those are structured in the result contract already.

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

Conciseness4/5

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

Front-loaded with the outcome and the style check, then the animation sourcing rules, then the job and credit model — a sensible ordering. It is dense to the point of being run-on, with several nested parentheticals chained into one long sentence block, which costs it a point, but no sentence is filler.

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 an async, credit-consuming generation tool with a nested payload and no output schema, the description supplies everything an agent needs: where each referenced id comes from, the animation exclusivity rule, the one-sheet-per-direction result with spritesheet_url, the {id, status} handle, and the poll target. The only omission, return field details, is covered by the existing job/result conventions it points to.

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

Parameters3/5

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 field well; the baseline is 3. The description does add relational meaning the schema only partly captures, notably the mutual exclusivity of the three animation sources and the fact that all directions share frame size, scale and floor so sheets line up, which is the key semantic for why 'directions' is not just a render count.

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?

Opens with a specific verb and resource: 'render a 3D model into one spritesheet per direction, in a style.' That is immediately distinguishable from siblings like createDirectionalStills (stills, not sheets), previewDirectionalSprites (preview), and adjustSpritesheet (post-processing an existing sheet).

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?

Names the exact prerequisite chain and the sibling tools that serve each role: listDirectionalSpriteStyles for style_id, previewDirectionalSprites to check before committing, and listAnimationPresets / animate3DModel / rigModel for the animation source. It also encodes a hard constraint (at most one of animation_url, preset_id, model_animation) and the fallback (no animation = single frame).

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