Skip to main content
Glama

prepare_reference

Clean and crop a real-world reference image, remove its background, and keep the largest object to produce an RGBA PNG silhouette for use with other reference tools.

Instructions

Clean a real-world reference for the other reference tools: crop it, remove the background and keep only the biggest object (a photo with two donuts and a caption becomes one donut with a transparent background). crop is [x0, y0, x1, y1] as fractions of the image from the top left (one panel of a sheet of views). keep=all keeps every blob. threshold is the colour distance from the background; leave it out and it is set just above the noise of the picture border (the answer shows the value). The background must be plain. fill_holes closes holes inside the object that are smaller than this share of the object area (glare on steel that looks like background); bigger openings such as a trigger guard stay. 0 closes nothing, 1 closes all. flip 'x' mirrors left-right, 'y' top-bottom; rotate turns clockwise by degrees (flip first). Use them to bring a panel to the picture a view expects (see compare_view). The result is an RGBA PNG cropped to the silhouette with pad margin; use its path as the reference of compare_view, fit_to_reference, visual_hull, measure_profile. The answer has the hole count and hole area share before and after filling, the blobs dropped, a warning (many open holes, the object touches the crop border, a big part dropped) and a preview picture: the cut-out over magenta and the mask (white object, green filled holes, red open holes). Look at the preview: alpha is not visible in the PNG itself.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
outNo
padNo
cropNo
flipNo
keepNolargest
imageYes
rotateNo
thresholdNo
fill_holesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden and does well: it states the background must be plain, threshold is auto-set above border noise, fill_holes semantics, flip-before-rotate ordering, output format (RGBA PNG cropped to silhouette with pad margin), warning conditions, and preview contents. It does not clarify whether the original image is modified or whether writing to `out` overwrites files, leaving some side-effect detail unstated.

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 description is front-loaded with purpose and then systematically covers parameters, usage, and output. It is dense but most sentences carry useful detail for a complex image-processing tool; a few clauses could be tightened, but the length is largely justified.

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?

There is no output schema and no annotations, so the description must explain return values and behavior. It describes the answer fields (hole count/area before and after, dropped blobs, warning, preview) and preview colors, which is strong, but it omits the `out` parameter and some error/format conditions, so it is not fully complete.

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%, so the description must compensate, and it does for most parameters: crop fractions, keep=largest/all, threshold auto behavior, fill_holes closing semantics, flip axes, rotate direction and order, and pad margin. It does not explain the `out` parameter or the required `image` parameter, leaving two of nine parameters without added meaning.

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 description states a specific verb and resource: clean a reference image by cropping, removing background, and keeping the biggest object. It explicitly distinguishes this preparation step from sibling tools by naming compare_view, fit_to_reference, visual_hull, and measure_profile as downstream consumers.

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 clearly explains when to use the tool: to bring a panel to the picture a view expects, and that its output path should be used as the reference for compare_view, fit_to_reference, visual_hull, and measure_profile. It does not state when not to use it or name alternative preparation tools, so it falls short of full routing guidance.

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