Skip to main content
Glama

three.ws 3D Studio (free)

by io.github.nirholas
OverviewDiscussionsAdmin

Refine a 3D model by describing a change

refine_model

Iterate on a model you already generated: just describe the change in words ("make it metallic", "bigger helmet", "add wings"). The studio re-generates a new version anchored to the previous one, carrying its form and materials forward. Pass the previous model's glb_url and, when you have it, the prompt that made it (parent_prompt) so the change builds on it. Each refinement is recorded as a new version in a lineage you can revert to or branch from, and the returned lineage drives a version strip in the viewer. Renders the new version inline in the interactive 3D viewer. Use this when the user wants to change a model you already generated instead of starting over.

Input Schema

NameRequiredDescriptionDefault
glb_urlYeshttp(s) URL of the model to refine (e.g. the glbUrl a previous generation returned).
instructionYesThe change to make, in plain language: "make it metallic", "bigger helmet", "add a cape".
parent_indexNoOptional: branch off an earlier version in parent_lineage (its index) instead of the latest.
parent_promptNoOptional: the prompt that produced the model being refined, so the change builds on it instead of starting over.
parent_lineageNoOptional: the lineage array from a previous refine_model result, to extend the same version history.
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.
reference_image_urlNoOptional http(s) image of the current model to anchor the re-generation (image→3D). Omit for text-guided refinement.

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. Changed1 schema field changed
    • addedInput schema / properties / idempotency_key
      Added value: +{
+  "description": "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.",
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}
  3. Changed3 schema fields changed
    • changedInput schema / properties / parent_index / description
      Previous value: -"Optional — branch off an earlier version in parent_lineage (its index) instead of the latest."New value: +"Optional: branch off an earlier version in parent_lineage (its index) instead of the latest."
    • changedInput schema / properties / parent_lineage / description
      Previous value: -"Optional — the lineage array from a previous refine_model result, to extend the same version history."New value: +"Optional: the lineage array from a previous refine_model result, to extend the same version history."
    • changedInput schema / properties / parent_prompt / description
      Previous value: -"Optional — the prompt that produced the model being refined, so the change builds on it instead of starting over."New value: +"Optional: the prompt that produced the model being refined, so the change builds on it instead of starting over."
  4. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare the mutation/side-effect profile (readOnly=false, openWorld=true, destructive=false). The description adds real context beyond that: re-generation is anchored to the previous version, carries form and materials forward, produces a new lineage version that can be reverted or branched, and renders inline in the viewer. No contradiction with annotations.

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 example instructions, then prerequisites, then versioning behavior. Each sentence is useful, though it runs slightly long with overlapping points about lineage/version strip that could be tightened.

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 usefully describes the return: a new version plus a lineage that drives a version strip and renders inline. For a 7-param mutation tool this gives an agent everything needed to invoke it 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. The description adds meaningful guidance beyond the schema by explaining why parent_prompt matters ('so the change builds on it') and that the lineage ties into version history, giving semantic weight to those optional params.

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 and resource (refine/iterate an already-generated 3D model) and immediately distinguishes the scope: 'change a model you already generated instead of starting over.' An agent can tell this apart from generation siblings like forge_free or mesh_forge without opening the schema.

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?

Explicit when-to-use: 'Use this when the user wants to change a model you already generated instead of starting over.' It also explains the pruning condition (pass glb_url and, when available, parent_prompt). It doesn't name a specific alternative tool (e.g. mesh_forge) for the starting-over case, so it falls short of the top score.

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

All three.ws 3D Studio (free) 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