Skip to main content
Glama

Scene Measure

scene_measure
Read-onlyIdempotent

Measure the spatial relationship between two Maya objects via world-space bounding boxes to get distance, clearance, penetration, or overlap before moving or separating them.

Instructions

Measure the spatial relationship between two objects.

Call this in the COMPUTE step of the ICEV workflow, to turn a spatial question into a number before you execute a change: size a clearance before moving something, prove two objects interpenetrate before you separate them, or get the axis detail behind an overlap that scene_validate reported.

Read-only and idempotent: it queries world-space bounding boxes and never modifies the scene, so no undo checkpoint is created. Requires an active Maya session.

Every mode measures world-space AABBs, not the mesh surface and not the object origin. The modes differ in what the number means: center distance between the AABB midpoints. surface distance between the closest facing AABB corners — an axis-aligned approximation, so it over-reports clearance for rotated or concave geometry. clearance SIGNED, and 0 is NOT a "merely touching" signal. Per axis the gap is +separated / 0=touching / -penetrating: > 0 euclidean distance across the STRICTLY SEPARATED axes only. Penetrating axes contribute 0, so they are invisible in this number. = 0 no axis is strictly separated and at least one axis is exactly touching. The other axes may be deeply penetrating, so 0 does NOT mean the boxes just touch. < 0 all three axes penetrate; the value is the SHALLOWEST penetration depth, the minimum translation needed to pull them apart. bbox_overlap is true if and only if all three axes strictly penetrate. A single penetrating axis already makes it read false, so it can never be read as "no penetration". Read details.clearances_xyz for the signed per-axis truth before concluding anything from distance alone. bbox overlap test. On overlap, distance is 0 and overlap_dims holds the per-axis penetration extents; otherwise distance is euclidean and gaps_xyz holds the per-axis gaps.

Distances are in the scene's current linear unit (cm, m or mm), not always centimetres.

Boundary: Disambiguated from scene_inspect (per-object property deep-dive), scene_snapshot (whole-scene spatial overview) and scene_assert (checks the scene against expected values rather than measuring one pair).

Input Schema

NameRequiredDescriptionDefault
modeNoWhat the returned number means — see the list above.center
obj_aYesFirst object name.
obj_bYesSecond object name.
formatNoOutput format - "cos" or "json".cos
session_keyNoMaya session key.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.0
    • changedInput schema / properties / mode / description
      Previous value: -"Measurement type:\n- \"center\": Center-to-center distance (default)\n- \"surface\": Closest surface point distance\n- \"clearance\": Gap/clearance distance\n- \"bbox\": Bounding box overlap detection"New value: +"What the returned number means — see the list above."
  2. First observedv0.4.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover readOnly/idempotent/non-destructive, yet the description still adds real behavioral context: no undo checkpoint is created, an active Maya session is required, measurements are world-space AABBs (not mesh surface or origin), and units follow the scene's linear unit. The per-mode semantics of the signed clearance value and the bbox_overlap flag are unusually thorough for a mutation-free query tool.

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 purpose, then usage, then semantics, then boundary — a clean hierarchy. It is long and the clearance-mode block is dense, but nearly every line carries decision-relevant information, so the length is mostly earned rather than padding.

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 an output schema exists, the description needn't enumerate return fields, and it instead supplies what the schema cannot: mode semantics, units, session prerequisite, and sibling boundaries. Nothing an agent needs to invoke or interpret this tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the schema for 'mode' merely says 'see the list above' — the description is the authoritative source for what each mode's number means, including the counter-intuitive signed clearance semantics and the details.clearances_xyz escape hatch. It also adds the unit caveat that applies to all returned distances.

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 opening sentence states a specific verb and resource ('Measure the spatial relationship between two objects'), and the Boundary paragraph explicitly distinguishes it from scene_inspect, scene_snapshot and scene_assert. An agent can identify the tool's niche without opening any schema.

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?

It names the workflow stage (COMPUTE step of ICEV) and gives three concrete triggering situations (sizing a clearance before a move, proving interpenetration before a separation, getting axis detail behind a scene_validate overlap). The Boundary paragraph explicitly routes competing questions to other tools.

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