Skip to main content
Glama

Replace a model file

edit_model
Destructive

Change imported models of placed pieces: replace files, edit materials and parts, set LODs, references, or measurements while keeping each piece's ID and placement.

Instructions

Change the imported model of placed pieces (ids), one undo step each; rev refuses a change if the plan moved on. replace swaps the file (library:@ too; every=true: on every piece using it), keeping id, place, size (size=natural takes the file's), finish, overrides and links; the new file is read first, and the reply gives the version loaded, overrides left matching nothing and what the file leaves out. material changes one material by the name model lists: color, mat (an image), repeat (texture scale: 2 halves it), clear. part hides, moves (offset cm: x across, y to the front, z up) or resizes one part by name — the back cushion alone. lod adds a lighter file drawn beyond a camera distance (beyond cm, default 400); detail=always holds the full one. reference keeps a product photo (file, view, part, source) that render_3d ref= shows beside the model; measure keeps a product size (dimension: width|depth|height|.height, cm, source, confirmed) that model compares with the drawing. model inspects; place imports.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cmNomeasure: the product's value, cm
idsYesPieces whose model changes, e.g. `["f12"]`
matNomaterial: an image over it, `img:trama.png`, or `none` for the file's own
revNoRevision the change was prepared on; refused if the plan has moved on since
fileNoreplace/lod/reference: the new .obj/.gltf/.glb file (lod: the lighter one; reference: the photo)
hideNopart: hide it (true) or show it again (false)
noteNoreference: what it shows
partNopart: which one, by the name `model` lists (`almofada_encosto`)
sizeNoreplace: `keep` each piece's w/d/h (default) or take the new file's `natural` size
unitNoreplace: unit of the new file's numbers, `m`, `cm`, `mm` or `in` (default: guessed)
viewNoreference: the side the photo shows
clearNomaterial/part: back to the file's own
colorNomaterial: its color `[r,g,b]`
everyNoreplace: also every other piece using the same file as `ids` (default: only `ids`)
scaleNopart: resize it about its center, `[x, y, z]` factors
actionYes`replace` puts another file in the pieces, keeping each one's id and all the rest; `material` changes one of their materials, `part` one of their parts, by name; `lod` gives them a lighter file drawn from afar; `reference` keeps a photo of the product with them, `measure` a measurement of it
beyondNolod: farther than this from the camera, cm, the lighter file is drawn (default 400)
detailNolod: `always` draws the detailed file however far (a close review); `auto` switches again
offsetNopart: move it by `[x across, y to the front, z up]` cm from where the file has it
removeNoreference: take out the one at this index (`model id=` lists them)
repeatNomaterial: times its image repeats against the file's mapping (2 draws it at half size)
sourceNoreference/measure: where it came from (a product page)
materialNomaterial: which one, by the name `model` lists (`tecido`)
confirmedNomeasure: measured or stated by the maker, not estimated
dimensionNomeasure: `width`, `depth`, `height` or `<part>.height` (its top above the floor)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
vNo
okYes
idsNo
revNo
textYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.0.0

TDQS

A4.3/5.0
Behavior5/5

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

With annotations marking this as destructive and non-read-only, the description adds strong behavioral details: 'one undo step each,' revision refusal ('rev refuses a change if the plan moved on'), replacement preservation semantics ('keeping id, place, size..., finish, overrides and links'), and reply contents. These go well beyond the structured annotations.

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

Conciseness3/5

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

The description is information-dense but written as a long run-on sequence of clauses with semicolons, making it difficult to scan. It front-loads the core purpose, but the remaining action details are not structured for quick reference. It is adequate for a complex multi-action tool but not concise or well formatted.

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 25 parameters, six actions, destructive annotations, and an output schema, the description is complete enough for an agent to understand the tool's scope and side effects. It covers every action, preservation behavior, and revision handling, while the output schema can carry return-value details.

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 all 25 parameters are already documented in the input schema. The description restates much of that same information in prose and groups parameters by action, but it adds little semantic meaning beyond the schema itself. Baseline 3 is appropriate.

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 description opens with a specific verb and resource: 'Change the imported model of placed pieces (ids).' It distinguishes this tool from siblings by naming alternatives: 'model inspects; place imports.' An agent can tell this is the edit/mutation counterpart to inspection and import.

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?

The description gives context for each action: replace swaps a file, material changes a material, part changes a part, lod adds a lighter file, reference keeps a photo, and measure keeps a measurement. It also names sibling alternatives at the end, though it does not state explicit when-not conditions. Clear usage context is present without formal exclusions.

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