Zovo Floor Plan

Make floor plan

make_floor_plan

Read-onlyIdempotent

Use this when the user wants a floor plan, room layout or apartment plan drawn to scale from room sizes, for example "draw a floor plan: living 5x4 m, kitchen 3x4 m next to it" or "plan of my house in feet". Takes rooms as rectangles (width east-west, length north-south) in metres or feet and inches, placed by x/y or right_of/below/left_of/above another room, plus optional doors and windows by wall and offset, a scale (auto, 1:50, 1:100, 1/4in=1ft) and a page size. Returns each room area, the total area, an interactive plan, and SVG, PDF and CSV downloads. Refuses overlapping rooms and openings past a wall end, naming them. Does not draw curved walls, stairs, furniture or wall thickness, and does not read images or files.

Input Schema

Name	Required	Description
`doors`	No	Doors, up to 60, e.g. [{"room":"Living","wall":"south","offset":1,"width":0.9}]. Drawn as a gap with a swing arc.
`rooms`	Yes	Rooms 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"}].
`scale`	No	auto (default: the largest standard scale that fits one page), a ratio like "1:50" or "1:100", or an architect scale like "1/4in=1ft" or "1/8in=1ft".
`title`	No	Plan title, e.g. "Ground floor". Up to 80 characters.
`units`	No	Unit 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.
`windows`	No	Windows, up to 60, e.g. [{"room":"Kitchen","wall":"east","offset":1,"width":1.2}].
`page_size`	No	PDF and SVG paper: auto (default: A4 for metres, Letter for feet), a4, a3, letter or tabloid. Orientation is chosen to fit.
`north_arrow`	No	Draw a north arrow pointing up (default true).

Output Schema

Name	Required	Description	Default
`page`	Yes
`doors`	Yes
`rooms`	Yes
`scale`	Yes
`title`	Yes
`units`	Yes
`checks`	Yes
`windows`	Yes
`warnings`	Yes
`area_unit`	Yes
`downloads`	Yes
`plan_size`	Yes
`room_count`	Yes
`total_area`	Yes
`label_check`	Yes
`scale_check`	Yes
`preview_count`	No
`total_area_text`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already establish a read-only, idempotent, closed-world operation, and the description adds substantial context on top: it discloses the outputs produced (areas, interactive plan, SVG/PDF/CSV), error behavior (refuses overlapping rooms and openings past a wall end, naming them), and explicit capability limits (no curved walls, stairs, furniture, wall thickness, no image/file input).

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?

A single dense paragraph that is front-loaded with the trigger and examples, then capabilities, then return values, then refusals and limitations. Each sentence carries distinct information with no filler.

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 8-parameter generation tool, the description covers inputs at a high level, the outputs (even though an output schema exists), failure modes, and scope boundaries. An agent has everything needed to decide to call it and to construct a plausible argument set.

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 every parameter is already documented in detail, and the description largely restates that (width east-west, length north-south, x/y vs right_of/below/left_of/above, doors/windows by wall and offset, scale forms). It confirms the intended mental model but adds little syntax or constraint detail beyond the schema, so baseline 3 applies.

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 artifact ("draw a floor plan to scale from room sizes") with two concrete example utterances, and the surrounding text makes clear this is a generation tool rather than a validator, distinguishing it from check_floor_plan without naming it.

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?

Opening clause "Use this when the user wants a floor plan, room layout or apartment plan" plus sample phrasings gives a clear trigger condition. It never names the sibling check_floor_plan or states when-not to use this, so the routing guidance stops short of explicit alternatives.

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

All Zovo Floor Plan tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?