Calculiva Cut Planner

Plan a plank flooring order

plan_flooring_order

Read-onlyIdempotent

Plans laminate, vinyl plank (LVP) or engineered plank flooring for 1 to 12 rooms, rectangles or L shapes, with the plank size and planks per carton from the carton: cartons to buy, every cut piece traced to its source plank, offcuts carried from one room to the next, the 8 scenarios (direction x offset 1/3 or 1/2 x reuse, plus aligned joints in the chosen direction when offset 0 is chosen) and the best one when no other ties it (fewest cartons, then least offcut, then fewest planks), and how many planks a flat waste allowance would miss. Up to 3,000 planks per call. Lengths accept feet and inches. Returns a link per room to the full plan on calculiva.com.

Input Schema

Name	Required	Description
`kerf`	No	Saw kerf, charged on each cut. Default 1/8 in. Length with its unit, e.g. "12 ft 6 in", "12'6\"", "150 in", "3m80"; a bare number is read as inches.
`order`	No	Laying order by room name; offcuts only flow forward. Default: the order of rooms.
`reuse`	No	Cut a row end from the offcut of a row start in the same room (default true).
`rooms`	Yes	Rooms to floor with the same plank, 1 to 12, in laying order unless order is given.
`offset`	No	End-joint stagger between rows, as a fraction of the plank: 1/3 (default), 1/2 or 0 (aligned).
`minReuse`	No	Shortest offcut worth carrying to another room. Default 0 (any offcut long enough). Length with its unit, e.g. "12 ft 6 in", "12'6\"", "150 in", "3m80"; a bare number is read as inches.
`clearance`	No	Expansion gap on every wall, from the product instructions. Default 0. Length with its unit, e.g. "12 ft 6 in", "12'6\"", "150 in", "3m80"; a bare number is read as inches.
`direction`	No	horizontal = planks run along the room width (default); vertical = along the room length.
`minStarter`	No	Minimum row starter length; 0 disables the check. Default 0. Length with its unit, e.g. "12 ft 6 in", "12'6\"", "150 in", "3m80"; a bare number is read as inches.
`plankWidth`	Yes	Installed plank width (face), from the carton. Length with its unit, e.g. "12 ft 6 in", "12'6\"", "150 in", "3m80"; a bare number is read as inches.
`minRowWidth`	No	Minimum edge-row width; 0 disables the check. Default 0. Length with its unit, e.g. "12 ft 6 in", "12'6\"", "150 in", "3m80"; a bare number is read as inches.
`plankLength`	Yes	Installed plank length (face), from the carton. Length with its unit, e.g. "12 ft 6 in", "12'6\"", "150 in", "3m80"; a bare number is read as inches.
`balancedRows`	No	Split the partial row width between the first and last rows (default true).
`firstStarter`	No	Length of the first row starter; 0 = full plank. Default 0. Length with its unit, e.g. "12 ft 6 in", "12'6\"", "150 in", "3m80"; a bare number is read as inches.
`planksPerBox`	Yes	Planks per carton, from the carton label.
`minJointSpacing`	No	Minimum distance between end joints of adjacent rows; 0 disables the check. Default 0. Length with its unit, e.g. "12 ft 6 in", "12'6\"", "150 in", "3m80"; a bare number is read as inches.
`allowancePercent`	No	Flat waste allowance you would otherwise buy (e.g. 10): the answer says how many planks it misses.
`carryBetweenRooms`	No	Offcuts of a room feed the next rooms (default true).

Output Schema

Name	Required	Description
`rooms`	Yes
`method`	Yes
`scenario`	Yes
`shareUrl`	Yes
`warnings`	Yes
`allowance`	Yes
`scenarios`	Yes
`transfers`	Yes
`boxesToBuy`	Yes
`offcutsLeft`	Yes
`planksToBuy`	Yes
`sparePlanks`	Yes
`bestScenario`	Yes	The single best of the scenarios (8, or 10 when offset 0 is chosen) by comparisonRule; null when several tie.
`planksPerBox`	Yes
`sourcePlanks`	Yes
`wastePercent`	Yes
`bestDecidedBy`	Yes	The first criterion of comparisonRule on which the two options differ.
`floorAreaSqFt`	Yes
`comparisonRule`	Yes	The ranking used for every "better" statement in this result; a tie recommends nothing.
`roomsAlonePlanks`	Yes
`shareUrlComplete`	Yes
`scenariosTiedAtBest`	Yes
`planksSavedBetweenRooms`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 12, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavioral context: offcuts flow forward room to room, 8 scenarios are evaluated, the tie-break chain (fewest cartons → least offcut → fewest planks), and the 3,000-plank call limit. This is meaningful disclosure of computation and limits beyond the safety profile.

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?

Purpose is front-loaded, but the body is a single sprawling run-on sentence with a long clause chain (scenarios, tie-breaks, waste allowance) that is hard to parse. Every clause is informative, yet the structure sacrifices readability for density.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't explain return values, yet it still notes a per-room link, which is helpful. Combined with the constraint disclosures and computation logic, it is largely complete for an 18-parameter planner, though it could say more about prerequisites or failure modes.

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 the baseline is 3. The description adds unit-handling ('lengths accept feet and inches') and explains the offset x reuse scenario space, but does not clarify individual parameters like minStarter, minJointSpacing, or clearance beyond what the schema already documents.

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 ('Plans') and resource (laminate, LVP, engineered plank flooring) with scope (1-12 rooms, rectangles or L shapes) and outputs (cartons to buy, per-cut tracing, best scenario). An agent can distinguish this from plan_trim_order or plan_wallpaper_order purely by the flooring/plank framing.

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 scope details (needs plank size and planks per carton, up to 3,000 planks per call), but the description never states when to choose this over the sibling planners or states exclusions. The only hard boundary given is the 3,000-plank cap, which is more of a constraint than guidance.

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

All Calculiva Cut Planner 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?