Skip to main content
Glama

check_assembly_stands

Read-only

Determine if a 3D assembly stands or how it rests by checking geometry, gravity, materials, and user intent, with explicit assumptions.

Instructions

Judge how an object LIVES and whether it STANDS — from geometry and the words, with every assumption said out loud.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "part_paths": "<part_paths>"
    },
    "name": "check_assembly_stands"
  }
}

Input Schema

NameRequiredDescriptionDefault
poseNo``"auto"`` (default) decides how it lives and lists the other resting faces; ``"as_placed"`` judges only the authored orientation under ``gravity``. Default: "auto".
intentNoThe idea in the user's own words — the brief's text ("a wall hook for my coat"). Default: "".
gravityNoDirection gravity acts, as ``[x, y, z]`` (default straight down, ``[0, 0, -1]``) — tilt it to judge an object displayed on its side.
lives_asNoThe mode the user chose, when asked: sits on a surface / lies flat on a surface / mounts to a wall or another surface / hangs from a loop or hole / is held, worn or carried / fits into or onto something else. Default: "".
design_idNoThe design these parts belong to. A design a Kiln generator made carries its product in its id (``"keychain-…"``), so the generator's own answer to how it lives is read from there when ``product_type`` is not given. Default: "".
materialsNoThe parts' filaments — one name for the whole kit, or a list aligned with ``part_paths``. Named, every part gets grams at its catalogue density and the centre of mass is weighted by mass (a PETG body on TPU feet is judged as that); unnamed, density is uniform and the report says so.
part_namesNoNames aligned with ``part_paths`` when two files share a stem.
part_pathsYesOne mesh file per part, positioned as assembled.
pin_recipesNoOptional add_pin_joints recipes (each carrying a ``parts: [a, b]`` key naming its pair) — the pin's normal then replaces the inferred seam direction.
template_idNoThe design template it came from. Default: "".
product_typeNoThe Kiln generator that made it (``"pen_cup"``, ``"ornament"``). Default: "".
carried_at_mmNoWhere that load acts, ``[x, y, z]``; default the hook's tip / the pendant's lowest point / the top.
carried_mass_gNoWhat it will HOLD — the coat on the hook, the water in the vase, the charm on the pendant — in grams. Needs ``materials`` (the object's own mass must be in grams too). It moves the centre of mass, so the tip angle, the hang and the fastener loads all answer for the loaded object. Default: 0.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed13 schema fields changedv1.5.1
    • addedInput schema / properties / carried_at_mm / description
      Added value: +"Where that load acts, ``[x, y, z]``; default the hook's tip / the pendant's lowest point / the top."
    • changedInput schema / properties / carried_mass_g / description
      Previous value: -"Default: 0.0."New value: +"What it will HOLD — the coat on the hook, the water in the vase, the charm on the pendant — in grams. Needs ``materials`` (the object's own mass must be in grams too).  It moves the centre of mass, so the tip angle, the hang and the fastener loads all answer for the loaded object. Default: 0.0."
    • changedInput schema / properties / design_id / description
      Previous value: -"Default: \"\"."New value: +"The design these parts belong to.  A design a Kiln generator made carries its product in its id (``\"keychain-…\"``), so the generator's own answer to how it lives is read from there when ``product_type`` is not given. Default: \"\"."
    • addedInput schema / properties / gravity / description
      Added value: +"Direction gravity acts, as ``[x, y, z]`` (default straight down, ``[0, 0, -1]``) — tilt it to judge an object displayed on its side."
    • changedInput schema / properties / intent / description
      Previous value: -"Default: \"\"."New value: +"The idea in the user's own words — the brief's text (\"a wall hook for my coat\"). Default: \"\"."
    • changedInput schema / properties / lives_as / description
      Previous value: -"Default: \"\"."New value: +"The mode the user chose, when asked: sits on a surface / lies flat on a surface / mounts to a wall or another surface / hangs from a loop or hole / is held, worn or carried / fits into or onto something else. Default: \"\"."
    • addedInput schema / properties / materials / description
      Added value: +"The parts' filaments — one name for the whole kit, or a list aligned with ``part_paths``.  Named, every part gets grams at its catalogue density and the centre of mass is weighted by mass (a PETG body on TPU feet is judged as that); unnamed, density is uniform and the report says so."
    • addedInput schema / properties / part_names / description
      Added value: +"Names aligned with ``part_paths`` when two files share a stem."
    • addedInput schema / properties / part_paths / description
      Added value: +"One mesh file per part, positioned as assembled."
    • addedInput schema / properties / pin_recipes / description
      Added value: +"Optional add_pin_joints recipes (each carrying a ``parts: [a, b]`` key naming its pair) — the pin's normal then replaces the inferred seam direction."
    • changedInput schema / properties / pose / description
      Previous value: -"Default: \"auto\"."New value: +"``\"auto\"`` (default) decides how it lives and lists the other resting faces; ``\"as_placed\"`` judges only the authored orientation under ``gravity``. Default: \"auto\"."
    • changedInput schema / properties / product_type / description
      Previous value: -"Default: \"\"."New value: +"The Kiln generator that made it (``\"pen_cup\"``, ``\"ornament\"``). Default: \"\"."
    • changedInput schema / properties / template_id / description
      Previous value: -"Default: \"\"."New value: +"The design template it came from. Default: \"\"."
  2. Addedv1.5.0

TDQS

C2.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuine behavioral trait beyond that — the report states 'every assumption said out loud' — which tells the agent results are accompanied by disclosed assumptions. It does not describe the substance of the verdict (tip angle, hang, fastener loads) that the parameter descriptions hint at.

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?

It is a single short sentence, so nothing is bloated, but the emphatic capitals ('LIVES', 'STANDS') and metaphor consume the budget without buying precision. Brevity here comes at the cost of specification rather than from disciplined editing.

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

Completeness2/5

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

This is a 13-parameter analytical tool with no output schema, yet the description never says what a result looks like — a verdict, a stability report, listed resting faces, assumption notes? The rich schema carries the inputs, but the one thing an agent cannot get from structured fields, the shape of the returned judgment, is left entirely unstated.

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% and the individual parameter descriptions are unusually rich (materials affecting centre of mass, carried_mass_g moving the centre of mass, pose='auto' vs 'as_placed'). The description contributes essentially nothing beyond that — 'from geometry and the words' loosely gestures at `intent` and `part_paths` but adds no new meaning. Baseline 3 applies.

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

Purpose2/5

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

The description restates the tool name in metaphor — 'how an object LIVES and whether it STANDS' — rather than plainly saying it evaluates an assembled object's resting pose and stability under gravity. 'Lives' and 'stands' are undefined jargon that only become meaningful after reading the schema's `lives_as` and `pose` parameters. It offers no differentiation from nearby siblings like check_orientation, validate_assembly, assess_load_bearing, or analyze_structural_risks.

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

Usage Guidelines2/5

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

There is no statement of when to call this instead of the orientation, clearance, or load-bearing tools that populate the sibling list. Usage is only inferable from parameter names (pose, lives_as, gravity). No prerequisites, exclusions, or alternative routing are given.

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

Deploy Server

Other Tools