Skip to main content
Glama

Check the layout

layout
Read-only

Detect collisions, blocked doors and windows, and other floor plan issues on a storey; compare room areas to a reference drawing.

Instructions

Layout problems on a storey — pieces colliding or clashing, blocked doors and windows: overlap, blocked, in_wall, blocks_door, blocks_window, no_door, backwards, turned, unrated_light, unclear_front, loose_opening, outgrew_niche, outside_rooms, loose and above_ceiling, as {kind: [rows]}; {} means none. Every row is an object with the key it is accepted by and the elements involved (name, bounds, z). Overlaps are classified collision (a real clash, first), nesting, served or cross_level, with extent [x,y,z] cm, counted in overlap_kinds. accepted {key, kind, why, extent} lists findings accept marked right as drawn; orphaned [[key, reason]] acceptances whose finding is gone. What each problem means and how to fix it: rules topic=layout. level: a storey id or all (default the one shown); areas {name|id: m²} compares room areas with a 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
areasNo
looseNo
turnedNo
blockedNo
in_wallNo
no_doorNo
overlapNo
acceptedNo
orphanedNo
warningsNo
backwardsNo
blocks_doorNo
above_ceilingNo
blocks_windowNo
loose_openingNo
outgrew_nicheNo
outside_roomsNo
overlap_kindsNo
unclear_frontNo
unrated_lightNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.0.0

TDQS

A3.9/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the substantive burden and delivers: it explains the return shape ({kind: [rows]}, {} for none), the fields per row (key, elements, name/bounds/z), the overlap classification scheme (collision/nesting/served/cross_level with extent and overlap_kinds), and how `accepted` and orphaned acceptances behave. That is rich behavioral disclosure well beyond the structured fields.

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

Conciseness3/5

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

The three long sentences are packed with necessary detail but read as a dense wall of jargon, with the first sentence dominated by a 16-item enumeration. It is adequately sized for a complex tool but not cleanly front-loaded or scannable.

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 complex inspection tool with an output schema and nested return structures, the description is unusually complete: it covers the returned categories, per-row fields, overlap classification, and acceptance bookkeeping. An agent has what it needs to interpret and act on results.

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?

Schema description coverage is 100%, so both `level` and `areas` are already fully documented in the schema. The description reinforces them (level defaults to the shown storey, areas compares against a reference drawing) but adds no format or syntax detail beyond what the schema provides. Baseline 3 applies.

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 opening clause 'Layout problems on a storey' states a specific check verb and scope, and the enumeration of problem kinds (overlap, blocked, in_wall, blocks_door, etc.) makes it unmistakable what the tool reports. It differentiates itself from siblings like `rules` by routing the agent there for explanations rather than duplicating them.

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

Usage Guidelines3/5

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

Usage is implied by the purpose (audit a storey for layout issues) and the description points to `rules` topic=layout for fixes and to `accept` for accepted findings. However, it never states explicitly when to run this versus alternatives, nor any exclusions or prerequisites.

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