Skip to main content
Glama

rigModel

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. 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 charged only on success. Rigging is non-destructive to geometry but replaces any prior skeleton, so animations made against an old rig no longer apply. Requires an API key (user scope). Returns 202 with a job id immediately; poll getApiJob (pass wait: 30) until status is succeeded, then read its result field, which is exactly the response documented for this operation. Each account may have up to 50 generations queued or running at once; beyond that submissions return 429 (PENDING_JOBS_LIMIT) - wait for jobs to finish.

Credits: This endpoint consumes 1 credits per call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestBodyYes

TDQS

A4.8/5.0
Behavior5/5

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 transparently discloses async behavior (202 + job id), the exact polling path via getApiJob, credit charging on success only, non-destructive geometry while replacing any prior skeleton, the usere-scope API key requirement, and the 50-job/429 rate limit.

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

Conciseness5/5

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

The description is long but unusually dense: every sentence carries operational information and no filler. The main purpose is front-loaded, and the remaining content follows a logical order: input, options, behavior, polling, limits, and cost.

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?

Given that there are no annotations and no output schema, this definition is remarkably complete. An agent knows how to invoke it, what job lifecycle to expect, how to retrieve the result, what failure modes exist, and what happens to prior rigs. Almost no critical detail is missing.

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

Parameters5/5

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

The description adds substantial meaning beyond the nested schema: it explains model as URL or base64, details every rig_type variant with joint counts and suitability, and clarifies joint_naming as a pure relabel that does not change the skeleton. This fully compensates for the nominal 0% schema description 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?

The opening sentence names the verb (Rig), resource (an existing GLB), and outcome (skeleton and skin weights so it can be animated). This makes the tool's purpose unmistakable and distinguishes it from siblings like animate3DModel and create3DModel.

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?

It gives concrete selection guidance for rig_type, including the two-armed, two-legged restriction for the humanoid templates and the note that humanoid_template is required for the preset animation library. It also covers auth, polling, and rate-limit preconditions, but it does not explicitly contrast this tool with sibling alternatives.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation4/5

Most tools pair a clear action and asset type (create3DModel, editVideo, removeBackground), and overlapping pairs such as animateSprite vs transferMotion vs animateSpriteKeyframes are carefully differentiated by input mode. The main friction is listApiJobs vs listGenerations, which both return generation history from slightly different scopes.

Naming Consistency4/5

The set is overwhelmingly consistent camelCase verb+noun (create*, edit*, list*, animate*, cancel*), with only minor deviations like generatePose/generateWithStyle alongside createImage and the slightly awkward validateApiKeyEndpoint. There is no chaotic mixing of conventions.

Tool Count2/5

At 31 tools this exceeds the 25+ threshold for 'too many', even though the multimodal game-asset scope explains much of the breadth. Agents face a large selection surface with many generation variants across 3D, sprites, images, audio, and video.

Completeness4/5

Core workflows are covered: image-to-3D plus rigging and animation, sprite pose/rotation/animation/editing, image create/edit/style/background-removal, video create/edit/upscale, and audio SFX/ambiance/music/voice. Minor gaps remain, such as no image upscaler and no individual asset retrieval or deletion.