Skip to main content
Glama

overlay_reference

Read-only

Compare a 3D model with a reference photo by drawing both through a scene camera. Use blend, edges, difference, or split modes to check alignment and silhouette match.

Instructions

Draw the model and a reference picture on top of each other, seen through a scene camera: it shows how far the camera and the model are from the photo. The model is rendered from camera (the scene camera when empty; without one call set_camera or match_camera first) at the proportions of the reference; the long side is size pixels. names is the model (everything visible when empty). Modes: blend (the reference at alpha); edges (red reference outline, yellow reference inner edges, green model outline over the dimmed model: best for small shifts); difference (black is a match); split (reference left of a line at the split fraction of the width, model right: lines must continue across it). The answer has the path, the silhouette IoU and the picture. The reference outline comes from alpha or the corner colour; threshold is the colour distance. Give the original photo, not a crop. grid_height_m (the real height of the reference silhouette) draws a metric grid with millimetre labels; zero is the bottom centre of the silhouette box. It is true for a flat-on (orthographic) reference only. Before a model exists, read coordinates with measure_profile grid=true.

Input Schema

NameRequiredDescriptionDefault
outNo
modeNoblend
sizeNo
alphaNo
namesNo
splitNo
cameraNo
referenceYes
thresholdNo
grid_height_mNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly/not destructive), yet the description adds substantial behavior: the four modes and what each renders, where the reference outline comes from (alpha or corner colour), what 'the answer' contains (path, silhouette IoU, picture), and the flat-on-only constraint on grid_height_m. This is rich disclosure beyond structured fields.

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?

The purpose is front-loaded and nearly every clause carries load, but the dense run-on prose around modes and grid semantics is hard to scan compared to a short bulleted list. Information density is high, so little is wasted.

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?

With 10 parameters, 0% schema coverage and no output schema, the description still tells the agent what the returned answer contains and covers prerequisites and mode selection. An agent could invoke this correctly without reading further documentation.

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 0%, so the description carries the full burden and largely succeeds: it defines camera, names, size (long side in pixels), alpha, split (fraction of width), threshold (colour distance), and grid_height_m (real millimetre height with zero at bottom-centre). Only `out` is left unexplained.

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 first sentence states a concrete verb and resource: draw the model and reference picture overlaid through a scene camera. It distinguishes itself from siblings like compare_view and measure_profile by describing the overlay/IoU output and by explicitly naming measure_profile grid=true for the pre-model case.

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?

It gives concrete prerequisites ('without one call set_camera or match_camera first'), the situation each mode suits ('edges ... best for small shifts'), and a gotcha ('Give the original photo, not a crop'). It stops short of saying when NOT to use the tool versus compare_view or fit_to_reference.

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