Skip to main content
Glama

Find walls in a scan

trace_background
Read-only

Convert background image into wall segments: dark or gray bands become walls, ignoring colored areas; collinear pieces split by doors/windows join within a max gap. Returns coordinates in cm.

Instructions

Trace walls from the background image (set_background first): thick dark or gray bands across or down the image become walls (colored areas — lawn, plants, furniture — are ignored; collinear pieces split by doors/windows up to max_gap join; region limits the search). Returns rows [[x1,y1],[x2,y2],t] in plan cm; trace_walls adds them as walls. Check with render_plan bg=0.5.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hNoWall height cm when creating (default 250)
t_maxNoThickest wall kept, cm (default 45)
t_minNoThinnest wall kept, cm (default 5)
regionNoOnly this part of the plan `[x0, y0, x1, y1]` cm
max_gapNoDoors and windows up to this wide don't split a wall, cm (default 130)
min_lenNoShortest wall kept, cm (default 60)
thresholdNoLuminance 0..255 below which a gray pixel is ink (default 128; raise it for light gray walls)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsYesWalls found: [[x1,y1], [x2,y2], thickness]

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already mark this readOnlyHint=true, and the description is consistent: it returns rows rather than mutating the plan. It also adds valuable behavioral detail beyond annotations, such as ignoring colored areas, joining collinear pieces split by doors/windows, honoring a region limit, and returning coordinates in plan cm. This gives the agent a clear model of what the tool does internally.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three dense sentences with no filler. It front-loads the main purpose and precondition, then covers output format and a verification step. Every sentence earns its place.

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?

For a read-only tool with a detailed schema and output schema, the description is complete: it explains the prerequisite, the algorithm, what is ignored, how walls are joined, how region limits the search, the return format, and how to verify the result. An agent has everything needed to select and call this tool correctly.

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

Parameters3/5

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

The input schema already documents all 7 parameters with 100% coverage, so the description does not need to repeat parameter details. The description mentions max_gap and region in prose, but the schema already explains these concepts, so little new parameter-level meaning is added over the structured schema.

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 ('Trace walls from the background image') and explains the operational scope: dark/gray bands become walls while colored areas are ignored. It also distinguishes itself from trace_walls by noting that trace_walls is what adds the results as walls. This clearly separates it from sibling tools.

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?

The description explicitly gives the precondition 'set_background first' and explains how results feed into trace_walls, plus suggests verifying with render_plan bg=0.5. However, it does not explicitly list situations where another tool should be used instead, so it falls just short of full when-not guidance.

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