Skip to main content
Glama

Polyfork low-poly 3D assets

get_variant

Turn a plain-words request ("oak cask", "taller", "five sails") into a ready call. want is matched against this asset's KNOB NAMES and OPTION VALUES, not against colour vocabulary: use the words from its -params.json into a ready createAsset() call for a remixable asset, plus a GLB URL of that exact variant. Check the returned confidence: on anything below high, tell the user what was actually applied instead of presenting it as exact.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
lookNoRestyle the mesh, independently of any knob. Deliverable families: palette = reduced|gameboy|pico8|cga|mono; smooth = soft|round|full; shading = toon|unlit. Example {"palette":"gameboy","shading":"toon"}. Underwater, Dither, Wobble, Outline, Wireframe and Pixelate exist in the store too but are SHADERS: no glTF can carry one, so they are not offered here. If the user wants those, send them to the asset page.
wantYesthe change in the user's own words

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / look / description
      Previous value: -"Restyle the mesh, independently of any knob. Deliverable families: palette = reduced|gameboy|pico8|cga|mono; shading = toon|unlit. Example {\"palette\":\"gameboy\",\"shading\":\"toon\"}. Underwater, Dither, Wobble, Outline, Wireframe and Pixelate exist in the store too but are SHADERS: no glTF can carry one, so they are not offered here. If the user wants those, send them to the asset page."New value: +"Restyle the mesh, independently of any knob. Deliverable families: palette = reduced|gameboy|pico8|cga|mono; smooth = soft|round|full; shading = toon|unlit. Example {\"palette\":\"gameboy\",\"shading\":\"toon\"}. Underwater, Dither, Wobble, Outline, Wireframe and Pixelate exist in the store too but are SHADERS: no glTF can carry one, so they are not offered here. If the user wants those, send them to the asset page."
    • addedInput schema / properties / look / properties / smooth
      Added value: +{
      +  "enum": [
      +    "soft",
      +    "round",
      +    "full"
      +  ],
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / look / description
      Previous value: -"Restyle the mesh, independently of any knob. Deliverable families: palette = reduced|gameboy|pico8|cga|mono; shading = toon|unlit. Example {\"palette\":\"gameboy\",\"shading\":\"toon\"}. Underwater, Dither, Wobble, Outline and Pixelate exist in the store too but are SHADERS: no glTF can carry one, so they are not offered here. If the user wants those, send them to the asset page."New value: +"Restyle the mesh, independently of any knob. Deliverable families: palette = reduced|gameboy|pico8|cga|mono; shading = toon|unlit. Example {\"palette\":\"gameboy\",\"shading\":\"toon\"}. Underwater, Dither, Wobble, Outline, Wireframe and Pixelate exist in the store too but are SHADERS: no glTF can carry one, so they are not offered here. If the user wants those, send them to the asset page."
  3. Changed1 schema field changed
    • changedInput schema / properties / look / description
      Previous value: -"Restyle the mesh, independently of any knob. Deliverable families: palette = reduced|gameboy|pico8|cga|mono; shading = toon|unlit. Example {\"palette\":\"gameboy\",\"shading\":\"toon\"}. Dither, Wobble, Outline and Pixelate exist in the store too but are SHADERS: no glTF can carry one, so they are not offered here. If the user wants those, send them to the asset page."New value: +"Restyle the mesh, independently of any knob. Deliverable families: palette = reduced|gameboy|pico8|cga|mono; shading = toon|unlit. Example {\"palette\":\"gameboy\",\"shading\":\"toon\"}. Underwater, Dither, Wobble, Outline and Pixelate exist in the store too but are SHADERS: no glTF can carry one, so they are not offered here. If the user wants those, send them to the asset page."
  4. First observed

TDQS

B3.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does meaningfully disclose behaviour: `want` is matched against KNOB NAMES and OPTION VALUES rather than colour vocabulary, the result includes a createAsset() call and a GLB URL for that exact variant, and a confidence value is returned whose low end should change how the agent reports back. Missing pieces are error/failure behaviour and what `id` must refer to, but the matching semantics and output shape are real, non-trivial disclosures.

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

Conciseness2/5

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

The text is short and purpose-first, but the second sentence appears spliced from two sources and dangles mid-clause, forcing the reader to reconstruct the intended instruction. That structural defect costs more than the brevity gains.

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

Completeness3/5

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

No output schema exists, so the description does correctly sketch the return payload (createAsset() call, GLB URL, confidence) plus a confidence-gating rule. But for a tool with a nested `look` object and an unexplained required `id`, it omits how `id` is obtained and what happens when matching fails, leaving a real gap for an agent to trip over.

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 coverage is 67%, and the description adds value for `want` by explaining it is matched against knob names and option values using the vocabulary from the asset's -params.json. `look` is already thoroughly documented in the schema itself. The required `id` parameter gets no explanation at all in either place, so the description only partially compensates for the coverage gap.

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

Purpose3/5

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

The opening states a recognisable transformation – plain-words request in, "a ready call" for a remixable asset plus a GLB URL out – which is a concrete verb+resource pairing. However, the description never distinguishes this from siblings like get_asset, find_matching, or preview_scene, and the middle sentence dissolves into a dangling clause ("not against colour vocabulary: use the words from its -params.json into a ready createAsset() call"), leaving the actual mechanism fuzzy.

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

Usage Guidelines3/5

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

There is actionable post-call guidance: "Check the returned confidence: on anything below high, tell the user what was actually applied instead of presenting it as exact." That is a genuine usage rule. But there is no when-to-use versus alternatives (when to reach for this instead of find_matching or get_asset), and no statement of prerequisites such as needing a valid asset id.

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.

Resources