Skip to main content
Glama

symbol_sweep

Find every instance of a repeated plan symbol from a single seed; sweep the whole sheet or set and get match centers with scores, or commit matches as takeoff count markers.

Instructions

Find EVERY instance of a repeated plan symbol from ONE example — drains, thresholds, fixtures, transition markers: marquee a tight seed_rect around a single instance and the vector linework is searched for every other placement of that same segment cluster. Deterministic geometry, not vision: each placement scores as the length-weighted fraction of the seed's segments reproduced within tolerance_px, under translation plus 0/90/180/270 rotation and mirroring (symbols rotate on plans — both ON by default; turn them off to pin orientation). Score ≥ 0.92 is a match; the 0.75–0.92 band comes back in withheld with a reason — a near-match is a question you answer by LOOKING (view_sheet at its at), never a silent commit and never a silent drop. The seed's own location is reported in seed and never double-committed. Work is capped and the cap is disclosed: a reply with candidates.dropped > 0 says exactly that some placements were never scored — tighten the seed rect around more distinctive geometry rather than trusting a truncated count. Marquee discipline: the rect must hug ONE instance — only segments FULLY inside it define the symbol, so a loose rect that swallows wall linework fingerprints the wall, not the symbol. scope "set" sweeps the WHOLE working set, counting on PLAN-role sheets only (the sheet graph decides): a symbol drawn in a detail, legend, or schedule is a reference drawing and never counts itself — which is also how you seed from one: marquee the assembly on the detail sheet and its plan-sheet occurrences are counted while the detail stays excluded (the exclusion disclosed in skipped, per-sheet results with per-sheet caps and wall-clock in sheets). Scale across sheets: the fingerprint is size-true and is never scale-SEARCHED, so a detail drawn at 1-1/2" = 1'-0" is 12× the size of the same mark on a 1/8" plan — when BOTH sheets have a scale set, the exact ratio is computed from them and the seed is resized before matching (reported per sheet as scaled); when a scale is missing, the sweep runs at 1:1 and SAYS so (scale_assumed), because an unknown ratio plus a zero count is not evidence of absence. Seeding from a detail/legend/schedule sheet REFUSES outright until both scales are set — that is the case where an unstated ratio silently finds nothing. commit: true (requires condition) commits every match center as an EA count marker through the same path as place_count — the whole sweep (set-wide included) is ONE undo step, each marker carries origin.method "symbol_sweep" with its score, transform, and seed source, and withheld placements are NEVER committed. The COUNT is scale-free (EA), but matching across sheets of different scales is not — set_scale on the sheets involved is what turns the ratio from an assumption into arithmetic. After any batch commit, LOOK at what landed — view_sheet {overlay: true} over the swept area — and audit the markers against the drawing before trusting the EA total. Coordinates are image px at render scale 2.0: PDF pt × 2, origin top-left, y down (the browser canvas's native space). Sheet payloads carry dims in both px and pt.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNo"sheet" = this sheet only; "set" = every PLAN-role sheet in the working set (needs a text layer for the sheet graph; non-plan sheets are excluded and disclosed)sheet
sheetYesThe sheet the seed rect sits on — in scope 'set' it may be ANY sheet (a detail/legend seed sheet is fingerprint source only, never counted)
commitNoCommit every MATCH center as one EA count marker (withheld placements never commit)
mirrorNoAlso match mirrored placements
conditionNoFinish tag to commit match markers under (minted on first use), e.g. 'FD-1'. Required when commit is true
rotationsNoAlso match 90/180/270-rotated placements
seed_rectYesMarquee around ONE example instance, [[x0,y0],[x1,y1]] in image px — tight: segments fully inside define the symbol
tolerance_pxNoEndpoint match tolerance in image px (default 2 — CAD jitter, not drift)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
seedYes
foundYesPlacements that cleared the commit bar — across every swept sheet in set scope
scopeYes"sheet" = the swept sheet alone (matches/withheld/candidates at top level); "set" = every PLAN-role sheet in the working set (per-sheet results in sheets[], exclusions in skipped[])
sheetsNoSet scope only: one entry per swept PLAN-role sheet, load order
matchesNoSheet scope only. Deterministic reading order (y, then x). The seed's own location is never listed here
skippedNoSet scope only: every sheet excluded from counting, with role and reason — including the seed's own sheet when it is not a plan
warningNoPresent when the work cap dropped candidates — what a tighter seed rect would recover
ea_totalNocommit mode: the condition's total EA after this call
withheldNoSheet scope only. Near-matches in the [0.75, 0.92) band — reported with a reason, NEVER committed. A withheld placement is a question you can answer with view_sheet; a hidden one is a miscount
committedNocommit mode: count shapes committed — one per match
conditionNocommit mode: the finish tag the markers counted under
shape_idsNo
candidatesNoSheet scope only — set scope accounts per sheet in sheets[]
Behavior5/5

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

With no annotations provided, the description carries full burden and excels. It discloses deterministic geometry, the scoring and threshold mechanics (0.92 match, 0.75–0.92 withheld), the cap behavior with dropped > 0, scale assumption and refusal cases, commit semantics (one undo step, origin.method), and the coordinate system. It even explicitly states it never silently commits or drops placements.

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 long but exceptionally information-dense, with no filler. It is front-loaded with the core purpose and then systematically covers usage, edge cases, and operational details. Every sentence contributes crucial guidance for a complex tool with 8 parameters and many behavioral nuances.

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?

The description covers all necessary context: input selection (seed_rect, sheet), output behavior (withheld, dropped, skipped, scaled), prerequisites (text layer, set_scale), commit behavior, coordinate system, and even the rationale behind design decisions. Given the tool's complexity, this is a complete operational manual that complements the output schema.

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?

Although the schema provides 100% parameter coverage, the description adds significant semantic value beyond field names. It explains the meaning and purpose of tolerance_px (CAD jitter), the effect of rotations/mirror toggles, the importance of a tight seed_rect, how scope 'set' interacts with plan-role sheets, and the conditional requirement for commit with condition. This goes far beyond the schema's brief descriptions.

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 opens with a specific verb phrase: "Find EVERY instance of a repeated plan symbol from ONE example," immediately establishing the tool's function and its distinguishing approach (deterministic geometry, not vision). It clearly separates this from siblings like detect_rooms or place_count by emphasizing a search over vector linework for repeated segment clusters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance: it explains the difference between scope 'sheet' and 'set', when to use set_scale for cross-sheet scaling, and cautions against using a loose seed_rect that swallows wall linework. It also directs the agent to use view_sheet for near-matches and references place_count as the commit path, giving clear alternatives and exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Kentucky-ai/opentakeoff'

If you have feedback or need assistance with the MCP directory API, please join our Discord server