Skip to main content
Glama
Sign In

Ludo AI Game Assets

by ai.ludo
OverviewDiscussionsAdmin

Attach accessories to a 3D model

attachDirectionalAccessories

Put accessories on a rigged 3D model for Directional Sprites: up to 8 items, each at the placement fitDirectionalAccessory returned (or, without one, at the automatic fit plus the same size/move/turn adjustments). Returns model_url, one GLB of the model holding them all (kept 7 days): pass it as model to createDirectionalSprites, createDirectionalStills or previewDirectionalSprites. When model is the URL of one of your 3D models (as listGenerations or create3DModel returned it), the items are also saved on that model (saved: true; save_on_model: false skips it), so the Ludo web app's Directional Sprites shows them on it. Items the model already had saved stay on it and in the GLB (kept), except those held by a bone a new item takes; keep_saved: false replaces them all. Free (no credits) and synchronous.

Input Schema

NameRequiredDescriptionDefault
requestBodyYesPayload for putting accessories on a rigged 3D model

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / requestBody / properties / items / description
      Previous value: -"Every item the model holds, at most one closing each hand (the first one in it)."New value: +"The items to put on the model, at most one closing each hand (the first one in it). Items the model already has saved stay on it (see keep_saved)."
    • addedInput schema / properties / requestBody / properties / keep_saved
      Added value: +{
+  "description": "When the model is one of your 3D models, keep the items it already has saved, except those held by a bone one of these items takes, and put them in the GLB too (listed in `kept`). False replaces them all with these items. Default: true.",
+  "example": true,
+  "type": "boolean"
+}
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing cost ('Free (no credits)'), execution mode ('synchronous'), retention ('kept 7 days'), and the conditional side effect of persisting items onto a saved 3D model. It also explains conflict resolution (items on a bone a new item takes are dropped) and how keep_saved/save_on_model change the outcome, including the `saved` and `kept` result flags.

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

Conciseness4/5

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

The core action and item limit are front-loaded, and the return-value and persistence rules follow in a logical order. It is a dense single paragraph with parenthetical asides that require a second read, 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?

With no output schema, the description carries the return contract itself and does so fully: `model_url` as a single GLB, `saved`, and `kept`, plus the 7-day retention window. Combined with the cost, sync behavior, and persistence semantics, an agent has everything needed to call this correctly.

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, but the description adds real meaning: it ties `items` placement to fitDirectionalAccessory output, explains the bone-conflict rule for existing saved items, and clarifies the default behavior of `keep_saved` and `save_on_model` in terms of observable results. It does not cover the model size limit or base64 input form, which remain schema-only.

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 concrete verb+resource ('Put accessories on a rigged 3D model for Directional Sprites') and immediately bounds scope (up to 8 items, placement from fitDirectionalAccessory). It is clearly distinguishable from rigModel, fitDirectionalAccessory, and createDirectionalSprites, which it explicitly names.

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

Usage Guidelines4/5

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

Gives strong workflow routing: use the `placement` returned by fitDirectionalAccessory, and feed the resulting `model_url` into createDirectionalSprites, createDirectionalStills, or previewDirectionalSprites. It does not state any when-not-to-use case or what to do if no fit has been computed, so it stops just short of full alternative guidance.

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