Skip to main content
Glama

three.ws for Grok

by io.github.nirholas
OverviewDiscussionsAdmin

Generate a rigged, animation-ready avatar

forge_avatar

Generate a rigged, animation-ready 3D avatar (GLB) from a single text prompt or a reference image, in one step. Generates the mesh, then auto-rigs it with a humanoid skeleton so it is ready to pose and animate. Best for characters; objects are steered to the mesh generator. Renders inline in an interactive 3D viewer. Use this when the user wants a posable, animation-ready character in one step instead of generating then rigging.

Input Schema

NameRequiredDescriptionDefault
promptNoDescription of the character/avatar to generate.
image_urlNoOptional http(s) URL to a reference image to reconstruct in 3D.
idempotency_keyNoOptional: any string you choose (up to 200 characters) that names this one generation, such as a task id. Calling again with the same key within 24 hours returns the original job instead of starting a new one, so a retry after a timeout never generates twice. Use a new key for a new model.
allow_non_humanoidNoSet true to rig a non-humanoid subject anyway (rigging assumes a humanoid figure).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Optional retry key. Send the same key again (same caller, same arguments, within 24 hours) and you get the original job back instead of a second generation, so a retry after a timeout cannot burn quota twice. Use a fresh key for each distinct request. A failed attempt is not remembered, so its key can be reused."New value: +"Optional: any string you choose (up to 200 characters) that names this one generation, such as a task id. Calling again with the same key within 24 hours returns the original job instead of starting a new one, so a retry after a timeout never generates twice. Use a new key for a new model."
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds useful behavior: the mesh-then-rig pipeline, GLB output, inline 3D viewer rendering. It does not clarify job/async semantics despite the presence of check_job/get_job siblings, and the idempotency_key parameter's interaction with idempotentHint=false is left to 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.

Conciseness4/5

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

Front-loaded with the core action and the one-step benefit, with no wasted preamble. It is somewhat repetitive, restating 'rigged, animation-ready' and 'in one step' across three sentences, which costs it the top score.

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

Completeness4/5

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

No output schema exists, and the description compensates by naming the return artifact (GLB) and the presentation (inline interactive viewer). For a 4-param generation tool it is nearly complete; only the async/job lifecycle is unaddressed.

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 baseline is 3. The description adds modest value by stating it accepts 'a single text prompt or a reference image,' implying the two input modes, but it says nothing about allow_non_humanoid or idempotency_key beyond what the schema already documents.

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 (generate), a concrete resource (rigged, animation-ready 3D avatar in GLB), and the exact pipeline (mesh generation then auto-rigging with a humanoid skeleton). It also distinguishes itself from the sibling mesh_forge + rig_mesh path by emphasizing it does both 'in one step.'

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 names the selection condition ('when the user wants a posable, animation-ready character in one step instead of generating then rigging') and routes non-character subjects away ('objects are steered to the mesh generator'). Both the when-to-use and the alternative are given.

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

All three.ws for Grok 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