Skip to main content
Glama

Zovo Floor Plan

Check floor plan

check_floor_plan
Read-onlyIdempotent

Use this when the user wants to check a room layout before drawing it, or asks why a floor plan was refused, for example "do these rooms overlap?" or "what is the total area of these rooms?". Takes the same rooms, doors and windows as make_floor_plan. Returns the area table, the sum of room areas, the floor area actually covered, and a list of problems: overlapping rooms with the overlap area, doors or windows that run past a wall end, L-shaped parts that overlap or do not touch, and rooms that do not touch the rest. Does not draw the plan and does not check building codes.

Input Schema

NameRequiredDescriptionDefault
doorsNoDoors, up to 60, e.g. [{"room":"Living","wall":"south","offset":1,"width":0.9}]. Drawn as a gap with a swing arc.
roomsYesRooms as rectangles, up to 40. A room with no position goes to the right of the previous room. Example: [{"name":"Living","width":5,"length":4},{"name":"Kitchen","width":3,"length":4,"right_of":"Living"}].
titleNoPlan title, e.g. "Ground floor". Up to 80 characters.
unitsNoUnit for plain numbers. m (default), cm or mm: a metric plan, sizes like 3.5, "350 cm" or "3500 mm"; ft or in: a feet-and-inches plan, sizes like 12'6", "12 ft 6 in", "12.5 ft" or "150 in". With cm, a plain 90 is 90 cm; with in, a plain 30 is 30 inches.
windowsNoWindows, up to 60, e.g. [{"room":"Kitchen","wall":"east","offset":1,"width":1.2}].

Output Schema

NameRequiredDescriptionDefault
roomsYes
titleYes
unitsYes
problemsYes
warningsYes
area_unitYes
plan_sizeYes
checks_runYes
room_countYes
covered_areaYes
counted_twiceYes
preview_countNo
problem_countYes
sum_of_room_areasYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavior: exactly what the returned area table, covered area, and problem list contain, including overlap area and wall-run-past-end cases. It does not describe auth or rate limits, but those are not relevant here.

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?

Front-loads the use case, then the input relationship, then outputs and exclusions. Every sentence adds distinct value despite the dense single paragraph.

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?

Complete for a complex read-only validation tool. It covers inputs by reference to make_floor_plan, summarizes the output schema's key results, and clearly bounds what it does not check.

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 coverage is 100%, so the input schema already documents rooms, doors, windows, units, and title thoroughly. The description adds only the useful relationship that it takes the same rooms, doors, and windows as make_floor_plan, without adding parameter-specific syntax or semantics beyond the 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?

States a specific verb and resource: check a floor plan. It names the sibling make_floor_plan and clarifies this tool validates rather than draws, so an agent can distinguish it from drawing 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 Guidelines5/5

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

Explicitly says when to use it: before drawing a plan, or to diagnose a refusal, with concrete example questions. It also states when not to use it for drawing or code compliance, routing the agent to the sibling make_floor_plan.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources