3D New Era AI

Overview Schema Source Related Servers Discussions Admin

Fill a wall with cabinets

cabinet_run

Destructive

Fill a wall with cabinets sized to fit around corners, doors, windows, fridge, stove, and appliances: measure free stretches, split into even modules, and add sink or cooktop cutouts.

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	Default
`row`	Yes
`wall`	Yes
`notes`	Yes
`modules`	Yes
`removed`	Yes
`adjusted`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv3.0.0Sep 30, 2026
- removedInput schema / properties / dry / default
```
Removed value: -false
```
- removedOutput schema / properties / adjusted / description
```
Removed value: -"Neighbouring runs replanned, same shape"
```
- removedOutput schema / properties / modules / description
```
Removed value: -"[id, role, from cm, w cm]"
```
- removedOutput schema / properties / notes / description
```
Removed value: -"What the rules say about it"
```
- removedOutput schema / properties / removed / description
```
Removed value: -"Cabinets it replaced"
```
- removedOutput schema / properties / row / description
```
Removed value: -"base, wall or tall"
```
- removedOutput schema / properties / wall / description
```
Removed value: -"The wall the run is on"
```
First observedv0.1.0Sep 24, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations mark destructiveHint=true and readOnlyHint=false, and the description corroborates by disclosing 'Replaces the cabinets already there (keep ids stay)' — the exact destructive scope — plus the dry-run escape hatch. It further sketches the return shape ({modules, removed, notes}), which is real behavioral context, though some of it overlaps the output schema.

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 purpose is front-loaded, but the bulk is a single sprawling sentence with nested parentheticals and semicolons that is hard to parse rather than efficiently scannable. Information density is high and most clauses earn their place, but the structure underserves it.

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 high-complexity 8-parameter tool with a nested `p` object and an output schema, the description covers the destructive lifecycle, defaults, appliance/wardrobe placement, and the keep-vs-replace contract. Return values need not be re-explained since an output schema exists; remaining gaps are minor edge-case semantics.

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% (baseline 3), but the description genuinely adds meaning: the EN 1116 rationale for target=60/max=90/sink_w=80/cooktop_w=60, the 15–30 cm pull-out and sub-15 filler fallbacks, and the placement rules for p.sink/p.cooktop (cabinet under it plus countertop cutout). These are semantic rules the schema cannot express, though they only partially disambiguate the addProperties-true `p` bag.

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?

The opening states a specific verb + resource + scope: 'Fill a wall with cabinets sized for it,' and the body expands into exactly what it generates (modules, drawer unit, countertop, wardrobe rows, appliance cutouts). It also names the sibling it is not for the post-edit step ('Change one module afterwards with joinery id'), so an agent can distinguish it from joinery/place/arrange without opening schemas.

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?

It gives context for when to reach for it (fill a whole wall/row, including appliances and wardrobes) and explicitly routes follow-up edits to the joinery sibling, plus the dry-run mode ('dry plans only'). It stops short of stating when NOT to use it versus place/arrange/layout, so it is clear but not exclusion-complete.

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