Skip to main content
Glama

Place furniture, doors and windows

place

Place furniture, doors, windows, and custom 3D models in a floor plan. Control position, orientation, wall snapping, ceiling mounting, and size.

Instructions

Place catalog items, or copy= of a piece already in the project (its model — even one embedded from an old import —, finish and parts, the id catalog(scope=project) gives): at=[x,y] center (doors/windows near a wall snap into it; into=[x,y] picks the swing side), or wall=id (+along cm) to put doors/windows in a wall or furniture against it, back to the wall and front to the room. Sizes w/d/h override defaults; pitch/roll tilt. Ceiling pieces (spots, LED panels, pendants, ceiling points) always hang from the ceiling the 3D draws — flat, sloping or under a roof — and follow it when they move or it changes: never compute their elev; for a pendant give elev = height of the shade's bottom (over a table ~150-160) or h = its drop, and the cord takes the rest. Which way it looks: facing=+x|-x|+y|-y, [x,y] or an element id to turn its front toward (armchair facing the TV) — prefer it to angle, clockwise degrees on a plan whose y grows down: 0 front to +y, 90 to -x, 180 to -y, 270 to +x (the catalog tool names each front: seat, doors, foot of the bed). A piece whose back belongs on a wall, put at=[x,y] within 30 cm of one with neither angle nor facing, is turned back to that wall on its own. The reply says where each front ended up: faces=f3:+y(seat), turned=f3:back to w2 — read it before building on the piece; mat finish (wood, marble, img:…; 'img:facade.png fit' stretches one image: a reference board to compare with render_3d view=front) and opacity (glass 0.3); defaults {…} fills every item; px=true reads coordinates as background pixels. cat=beam with a,b=[x,y,z] (z above the floor) and w×h section makes rafters, posts and braces; a beam reaching into a roof stops under it. Pools: pool or pool-oval. dry=true answers what it would do — what it would add, the clearances around it, the findings it would settle or create — without writing; dry="summary" answers short.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
vNoPlan version (tab) to write to; switches to it first
pxNoCoordinates (`at`, `into`, `a`, `b`, `along`) are pixels of the background image
dryNoTry it without applying; see `update`. `"summary"` answers short
itemsYesThe pieces to place, one object each: `id` from the catalog (or `copy`), and where (`at`, or `wall` + `along`)
defaultsNoFields every item takes unless it sets them (cat, w, d, h, color, mat…)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
vNoPlan version written to, when there are several
okNoAlways true
dryNoNothing was written
idsNoIds created or touched
revNoPlan revision
goneNoIds removed, or their count
textNoThe reply as written
addedNoIds added, or their count
facesNoWhere each front looks: <id>:<side>(<front>)
scoreNoScore [before, after]
turnedNoPieces turned back to a wall: <id>:back to <wall>
changedNo{id, from, to} per element changed; a count past 20
resolvedNoFindings settled
clearancesNoFree floor around touched pieces, by id
issues_newNoLayout issues created
propertiesNoProject properties changed
added_countNoRoots added
annotationsNoAnnotation switches {from, to}
score_scopeNoDisciplines scored
new_findingsNoFindings created
changed_countNoRoots changed
issues_changedNoLayout issues resized
issues_resolvedNoLayout issues settled
findings_changedNoFindings changed
acceptance_cleanupNoAcceptances orphaned, and the calls that clear them

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only provide basic read/write hints, so the description carries the behavioral burden. It richly discloses side effects and behaviors: doors/windows snap into walls, ceiling pieces hang and follow ceiling changes, pieces auto-turn toward walls, beams stop under roofs, and `dry=true` avoids writing. This goes well beyond the annotations.

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 long and dense, but the tool is genuinely complex with many placement modes and edge cases. It is front-loaded with the primary use and every sentence carries substantive guidance. The main weakness is the single-paragraph stream-of-consciousness structure, which could be better organized.

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 tool this complex, the description covers the placement modes, orientation conventions, wall/celing behaviors, materials, beams, pools, and dry-run behavior. The schema covers the remaining parameter details, and an output schema exists, so the agent has enough context to call and interpret the tool correctly.

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?

Even with 100% schema coverage, the description adds substantial meaning beyond the schema: `at` vs `wall`, `into` swing side, facing/angle coordinate conventions, ceiling pendant elevation guidance, beam endpoint semantics, pixel mode, and dry-run behavior. This significantly helps an agent invoke parameters correctly.

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 'Place catalog items' and covers placement, copying existing pieces, importing models, and placing beams/pools. It clearly distinguishes this tool from siblings like move or arrange by focusing on the act of placing new items into the plan.

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 gives clear context for when to use `place`: adding catalog items, copying an existing piece, importing models, or placing beams/pools. It does not explicitly contrast with siblings like `move` or `update`, but the placement-specific guidance is clear enough to route an agent correctly.

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