3D New Era AI

Overview Schema Source Related Servers Discussions Admin

Fill a wall with cabinets

cabinet_run

Destructive

Plan a wall run of kitchen cabinets: measure free stretches, split into even modules, place sink, cooktop, drawer units, and countertops, and report the layout.

Instructions

Fill a wall with cabinets sized for it: measures the free stretches between corners, doors, windows, fridge and stove, splits each into even modules (30-90 cm, no useless leftovers; 15-30 cm pull-outs, fillers under 15; the defaults target=60 max=90 sink_w=80 cooktop_w=60 are the nominal widths of EN 1116, which is what appliances and hardware are made for — bespoke widths in between are fine for a run that receives none), drawer unit beside the stove, countertop on base rows, cabinet over the fridge and hood gap on wall rows, wardrobes (hanging rails, shelves, drawers) on tall rows facing bedrooms; p.sink/p.cooktop place those cabinets and cutouts. Replaces the cabinets already there (keep ids stay). Reply {modules:[[id,role,from,w]],removed,notes}; dry plans only. Change one module afterwards with joinery id.

Input Schema

TableJSON Schema

Name	Required	Description
`p`	No	Flat choices, all optional: row base\|wall\|tall, h, d, elev, t (mm), front, color [r,g,b], handle bar\|profile\|knob\|cava\|none (bar), `handle_color` [r,g,b] or "#hex", drawers (drawer units), max (widest module, 90), target (60), top (base countertop, true), `top_material`, sink / cooktop (center cm along the wall: cabinet under it and the countertop cutout), `sink_w` (80), `cooktop_w` (60), interior shelves\|hanging\|wardrobe (tall rows; wardrobe by default facing a bedroom)
`to`	No	Where the run ends, cm from the wall start (default: the wall's end)
`dry`	No	Plan and report only
`from`	No	Stretch to fill, cm from the wall start (default: all of it)
`keep`	No	Cabinets on that wall that stay as they are
`near`	No	Or a piece against the wall (`f12`, the fridge): its nearest wall, on its side
`room`	No	Room the fronts face (default: the side toward the middle of the house)
`wall`	No	Wall whose face gets the cabinets

Output Schema

TableJSON Schema

Name	Required	Description
`row`	Yes	base, wall or tall
`wall`	Yes	The wall the run is on
`notes`	Yes	What the rules say about it
`modules`	Yes	[id, role, from cm, w cm]
`removed`	Yes	Cabinets it replaced
`adjusted`	No	Neighbouring runs replanned, same shape

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 24, 2026

TDQS

A3.7/5.0

Behavior4/5

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

The description openly discloses that the tool 'Replaces the cabinets already there (keep ids stay)', which aligns with the destructiveHint annotation. It also goes beyond annotations by describing the placement algorithm, output shape, and dry-run behavior, giving the agent a realistic picture of side effects.

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 core purpose is front-loaded, but the rest is a dense, run-on sentence with a long parenthetical and many clauses. It contains valuable details, but the lack of sentence breaks and the overloaded structure make it harder to parse than it should be.

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?

For a complex, destructive tool with 8 parameters and an output schema, the description covers the key behavioral rules, default dimensions, output format, and the joinery follow-up path. It is not perfectly clear on the dry-run semantics, but overall it gives enough context for an agent to invoke it correctly.

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%, so the baseline is 3, but the description adds meaningful semantics: default module widths (target=60, max=90), sink/cooktop widths, the role of p.sink/p.cooktop in placing cabinets and cutouts, and the meaning of 'keep' for preserving existing cabinets. This goes beyond simply restating parameter names.

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 phrase 'Fill a wall with cabinets sized for it' states a specific verb, resource, and intent, and the description immediately elaborates with measurable behavior (measuring free stretches, splitting modules, adding countertops, etc.). It is distinguishable from generic tools like 'place' or 'arrange', though it does not explicitly name a sibling alternative.

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?

The description implies its use case clearly, and it does mention 'Change one module afterwards with joinery id' as a follow-up alternative. However, it does not explicitly state when to prefer this tool over siblings like 'arrange', 'place', 'update', or 'joinery', and the 'dry plans only' phrase is ambiguous.

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