Skip to main content
Glama
asedias

bl-mcp

by asedias
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

compare_view

Compare a 3D model against a reference image to verify size and outline alignment, catching scale or shape mismatches.

Instructions

Compare the model with a reference image in one flat view: the main metric of a build from references. The reference is placed in the world: its bottom on the model bottom, horizontal centres equal. Scale: height_m is the real size of the subject along the VERTICAL of the (turned) picture, width_m along its horizontal; give one, and a model that is too big or too small is caught. With none the reference is fitted to the model height and only the outline shape is compared. iou_outline is always that shape-only match. Views (the model front faces -Y, Z up) and the picture each expects. front: +X to the right. back: -X to the right. right (side is the same): camera on +X, the front points LEFT. left: the front points right. top: +X to the right, the front at the BOTTOM. bottom: the front at the top. flip ('x' left-right, 'y' top-bottom) and rotate (degrees clockwise; flip first) turn the reference for this call. names is the model (empty: everything visible but a huge floor or backdrop, listed in excluded). Returns iou_registered, both sizes, a table per band along the vertical (widths, delta, shift, verdict; worst first) and inner_detail: edge_agreement 0..1 between the reference inner edges and the creases and depth steps of the model (the IoU does not see slots and holes inside the outline). Under IoU 0.3 a hint says if a mirrored or turned reference fits far better. The image: reference, model, overlay (red reference outline, green model outline, yellow and blue inner edges), difference; out also saves it. colors=N adds the match of N colour classes of the reference. For a perspective photo use match_camera and overlay_reference.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
outNo
flipNo
sizeNo
viewNofront
bandsNo
namesNo
colorsNo
rotateNo
width_mNo
height_mNo
referenceYes
thresholdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.4/5.0
Behavior5/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 so: it discloses the return payload (iou_registered, sizes, per-band table, inner_detail, hint), what happens with empty names ('everything visible but a huge floor or backdrop, listed in excluded'), flip/rotate ordering ('flip first'), and the IoU<0.3 hint behavior. This is unusually rich behavioral disclosure for an un-annotated 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-loaded with the core purpose, which is good, but the body is dense shorthand with heavy parenthetical asides and a long view-orientation block that is hard to parse. Much of the length is justified by 12 undocumented params, but the phrasing is not economical.

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?

Given a 12-param tool with no output schema and no annotations, the description supplies return values, scale semantics, and view conventions, which is close to sufficient. Gaps remain for size/bands/threshold meaning, but an agent could invoke it correctly.

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% with 12 params, so the description must compensate, and it explains height_m, width_m, names, flip, rotate, colors, out, and view semantics (including per-view camera orientation). It leaves size, bands, threshold, and reference unexplained, so coverage is strong but incomplete.

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 ('Compare the model with a reference image in one flat view') and immediately frames it as 'the main metric of a build from references'. It also names the sibling tools (match_camera, overlay_reference) that handle the perspective-photo case, so an agent can route correctly without opening schemas.

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 explicit when-not guidance: 'For a perspective photo use match_camera and overlay_reference.' It also explains the selection logic for height_m/width_m ('give one, and a model that is too big or too small is caught') and when the reference is auto-fitted. Clear context, though it doesn't enumerate all sibling comparisons.

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