Skip to main content
Glama

fit_to_reference

Move, scale, and tilt 3D model parts to match reference silhouettes, fixing placement and proportions without changing shapes.

Instructions

Move, scale and tilt parts by itself to raise the match with reference silhouettes. Use it when the forms are roughly right: it fixes placement and proportions, not shapes. For each part in parts it keeps the changes that raise the world-registered IoU over all views (as compare_view measures it). references maps a view (as in compare_view) to an image; names is the whole model (everything visible but a huge floor or backdrop when empty). Scale per view, as in compare_view: height_m (vertical of the picture) or width_m (horizontal). Each is one number for all views or a dict per view, and every view needs one: height_m=0.152 with width_m={"top": 0.0325}. A size that names the view wins over a plain number. mirror_pairs [["arm_L","arm_R"]] keeps pairs symmetric (list both in parts). tune picks what may change. Guard: a move that raises the IoU but hides the part is refused: visible_share (the share of the part that the rest of the model does not cover) may drop by max_hide at most (1 turns the guard off). The answer lists rejected moves and visible_share [before, after]. It takes the checkpoint 'before_fit' first: rollback undoes it. Background job: after wait seconds the answer is a job id for job_status.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sizeNo
tuneNo
waitNo
namesNo
partsYes
step_mNo
width_mNo
height_mNo
max_hideNo
max_tiltNo
tilt_degNo
max_shiftNo
thresholdNo
iterationsNo
referencesYes
scale_stepNo
time_limitNo
mirror_pairsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.4/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 substantial work: it discloses the IoU optimization objective, the guard that refuses moves hiding parts, checkpoint creation ('before_fit') with rollback, background-job timeout behavior via wait, and rejection reporting. It doesn't state whether the operation is destructive to existing transforms or whether it fails atomically, leaving a small gap for a mutation tool.

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?

Front-loads the core purpose and 'when' well, but the body is dense, runs long, and mixes several concerns (scaling syntax, guard mechanics, rollback, jobs) in an undifferentiated block. Every sentence is substantive, but structure and segmentation would help readability.

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?

For an 18-param, no-annotation, no-output-schema tool, the description covers the dominant concepts an agent needs: purpose, metric, which views/refs, size specification, guard behavior, and async job handling. Missing detail on numerous tuning parameters and exact returned fields (only partially noted: rejected moves, visible_share before/after) keeps it short of complete.

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 0% across 18 params, so the description must compensate and does for several key ones: references, names, height_m/width_m (including the dict-per-view form and precedence rule), mirror_pairs, tune, max_hide/visible_share, and wait. However, many numeric tuning params (step_m, scale_step, threshold, iterations, max_tilt, tilt_deg, max_shift, time_limit, size) are undocumented, leaving a gap given the very low schema 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?

States a specific verb+resource ('Move, scale and tilt parts') and distinguishes from shape-editing siblings by explicitly saying it 'fixes placement and proportions, not shapes.' The optimization target (world-registered IoU over all views as measured by compare_view) is named precisely.

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?

Explicit when-to-use ('when the forms are roughly right') and states what it does not do (shapes). It anchors the metric to compare_view, giving the agent an alternative/companion tool for interpreting results. No important exclusions left implicit.

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