Skip to main content
Glama

Check the layout

check_layout
Read-only

Detect layout issues in floor plans: blocked access, overlaps, misplaced doors/windows, turned items, unrated lights. Check one storey or all, with acceptance tracking and room areas.

Instructions

Layout problems: above_ceiling, overlap, blocked, in_wall, blocks_door, blocks_window, no_door, unrated_light, turned, unclear_front, loose_opening, outgrew_niche, outside_rooms, loose (a fixed point with nothing to be fixed to: loose in a room, on glass, in a door or window span, hanging under the ceiling, with why); {} means none. Each one carries name, bounds and z of both elements. Overlaps are classified kind collision (a real clash, listed first), nesting (built in, resting on, tucked under), served (a project point inside a piece on purpose: the water point in the basin, the outlet behind the fridge or set into a cabinet) or cross_level, with extent [x,y,z] cm of the shared space; overlap_kinds counts them. blocks_window reports nearby tall/elevated solids masking the window, with extent [width,height] cm; compact countertop objects are exempt, so this does not certify sash operation or ventilation. blocks_door includes a 60 cm approach on either face, even for sliding doors and passages. blocked is a cabinet, fridge or wardrobe whose opening face is against a solid — it cannot be used, and angle alone does not show it. backwards is a piece whose back belongs on a wall (sofa, bed, toilet, TV, desk — the catalog tool marks them wall) with its front against a wall instead: it is turned half around; fix.angle turns it the right way, and the piece's back then touches that wall only if it was flush — placing again with wall= seats it. turned is a group whose built fronts (doors, drawer fronts, kick) face one way and whose angle says another: the piece opens where the panels are, so fix the angle, not the clearance it seems to lack. unrated_light is a light fixture with neither lumens nor watts — only the relative power an import carries — so the lighting tool's lux for its room are a guess: set its output with update(light={lm or w}). no_door is a bedroom or bathroom (by name) with no door — only open passages, listed, or no way in at all — said once the storey has doors somewhere; a living room, kitchen or balcony left open is not. unclear_front is a group whose parts name fronts on more than one face with no clear winner (candidates, strongest first; placed is the angle's guess every "in front of" falls back to) — rename the misleading part or set the angle. Handles weigh most. loose_opening is a door or window in no wall — a passage drawn as a panel — which reads as an opening in every schedule and opens nothing. outgrew_niche is an appliance its host stopped holding after the joinery was resized around it, with how far it sticks out: built-in pieces are left out of the overlap check by design, which is why nothing else notices. above_ceiling compares the full luminaire footprint with the same room ceiling surface used in 3D, with ceiling/top/over in cm: declared storey height, sloping wall profiles and lower roof panels. Hidden ceilings and unknown uncovered slopes are not inferred. Every row is an object with the key it is accepted by (in_wall {key, piece, wall}, blocks_door {key, door, by}). The accept tool marks one looked at and right as drawn — an imported model whose box is bigger than the piece it draws: it leaves the sections, the variant count and every dry run, and is listed here under accepted {key, kind, why, extent} with its reason, kept in the project; orphaned [[key, reason]] lists acceptances whose finding is gone on every storey, and accept(prune=true) drops them. level: a storey id or all, default the one shown. areas {name|id: m²} compares room areas with the reference drawing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
areasNoExpected room areas in m² by room name or id, e.g. {"Sala": 10.91}; adds rows [room, expected, actual, diff %]
levelNoStorey to check: an id like `lv3`, or `all` for every storey that is not a reference layer. Default: the storey being shown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
areasNoWith areas: [name, expected m², actual m², difference %]
looseNoPieces floating or unsupported: {key, piece, why}
turnedNoPieces placed turned from how they were built: {key, piece, built, placed}
blockedNoPieces whose use is blocked: {key, piece, against, cm}
in_wallNoPieces inside a wall: {key, piece, wall}
no_doorNoRooms nobody can walk into: {key, name, room, passages}
overlapNoPieces that overlap: {key, a, b, kind, extent}
acceptedNoIssues accepted as they are: {key, kind, why}
orphanedNoAcceptances whose issue is gone: [key, reason]
warningsNoStoreys stacked at the same elevation
backwardsNoPieces turned to face a wall: {key, piece, wall, cm, fix}
blocks_doorNoDoors blocked: {key, door, by}
above_ceilingNoPieces through the ceiling: {key, piece, room, ceiling, top, over}
blocks_windowNoWindows blocked: {key, window, by, extent}
loose_openingNoDoors or windows in no wall
outgrew_nicheNoPieces bigger than their niche: {key, piece, host, over}
outside_roomsNoPieces in no room
overlap_kindsNoOverlaps by kind: {collision, nesting, served, cross_level}
unclear_frontNoPieces whose front is a guess: {key, piece, candidates, placed}
unrated_lightNoLights without a rating

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses classification semantics, exemptions (e.g., compact countertop objects), limitations ('does not certify sash operation or ventilation', 'Hidden ceilings and unknown uncovered slopes are not inferred'), and special cases such as accepted/orphaned findings. It also clarifies behaviors like no_door only being reported once the storey has doors somewhere. This is far richer than the annotation alone.

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

Conciseness2/5

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

The description is a single dense, unstructured paragraph mixing output taxonomy, edge cases, related-tool behavior, and parameter notes. It would be far more usable with bullets, sections, or a clear 'returns' framing. Despite being information-rich, it is not appropriately sized or structured for quick agent consumption.

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?

Given the tool's complexity and the many distinct problem categories, the description is exceptionally complete: it defines every reported kind, explains field semantics, gives examples, states conditions and exemptions, documents parameter behavior, and even covers interactions with the accept tool. The presence of an output schema lowers the burden for return-value details, and the description still covers them thoroughly.

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 100% and both parameters already have descriptions, so the baseline is 3. The description adds marginal meaning by noting that `areas` compares room areas against the reference drawing and that `level` defaults to the displayed storey. That extra context lifts it slightly above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title supplies the verb+resource ('Check the layout') and the description enumerates the specific layout problems the tool reports, so an agent can tell this is a layout diagnostic. However, the description opens with a bare list ('Layout problems: ...') rather than an explicit declarative sentence, and it never contrasts itself with related diagnostics like measure or checkpoints.

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

Usage Guidelines2/5

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

The description provides no explicit guidance about when to call this tool instead of alternatives such as measure, ergonomics, or checkpoints. It implies usage through its exhaustive problem list and boundary conditions, but it never states 'use this when ...' or names a preferred alternative.

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