Skip to main content
Glama

measure_profile

Read-only

Measure silhouette width, edge positions, and filled runs per horizontal band in metres from a reference image to build loft sections, check specs, or find model differences.

Instructions

Measure a silhouette in a reference image in metres (use measure for an object of the scene). The image height is mapped to height_m. Returns, for each horizontal band from the bottom: width, left and right edge from the centre, the separate runs (arms and legs are separate runs) and the filled width. Use the numbers for loft sections, assert_spec checks or to find where the model differs. The outline comes from alpha or from the corner colour (see prepare_reference). grid=true also returns the reference with a metric grid (labels in millimetres, the same coordinates as the bands: x from the centre of the silhouette box, z from its bottom), to read where parts and details are. region [x0, z0, x1, z1] in metres zooms the grid picture into a part; grid_size is its long side in pixels; out saves it to a file.

Input Schema

NameRequiredDescriptionDefault
outNo
gridNo
bandsNo
regionNo
height_mYes
grid_sizeNo
referenceYes
thresholdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare a safe read-only, non-destructive profile, yet the description goes well beyond them: it discloses the exact return structure per band (width, left/right edge from centre, separate runs for arms/legs, filled width), the coordinate frames for the grid (x from silhouette box centre, z from its bottom, labels in millimetres), and where the outline comes from ('alpha or from the corner colour'). This is unusually rich context for a measurement 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?

Purpose and the measure/measure_profile distinction are front-loaded, and the following sentences each add a distinct piece of information (return shape, outline source, grid/region/out behavior). It is dense rather than padded, though the return-shape enumeration makes it longer than strictly necessary.

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 8-parameter tool with no output schema and zero schema descriptions, the description supplies the return format, coordinate conventions, image-source dependency and file output, so an agent can call it correctly. The two unexplained parameters (bands, threshold) are the only meaningful omission.

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 description coverage is 0% across 8 parameters, so the description must carry the load, and it explains most of them: height_m ('image height is mapped to height_m'), grid, region ([x0, z0, x1, z1] in metres), grid_size (long side in pixels) and out (saves it to a file). It leaves 'bands' and 'threshold' undocumented, which is the main remaining gap.

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 ('Measure a silhouette in a reference image in metres') and immediately disambiguates from the nearest sibling: 'use measure for an object of the scene.' An agent can choose between measure_profile and measure without opening either 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?

Gives clear routing ('use measure for an object of the scene') plus concrete downstream uses for the numbers: 'loft sections, assert_spec checks or to find where the model differs.' It does not state prerequisites (e.g. that the reference must have alpha or a distinguishable corner colour) as an explicit when-not, so it stops short of a 5.

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