3D New Era AI

Overview Schema Source Related Servers Discussions Admin

Build joinery

joinery

Destructive

Generate parametric cabinets, slats, countertops, coves, shadow gaps, and sofas with computed parts, hardware, and notes. Validate or place builds in a room; rules advise but never refuse.

Instructions

Parametric joinery and interiors; the server computes every board, clearance and rule and replies {id,name,size,parts,hardware,notes}. What a workshop would say — a board nobody stocks, a shelf that will sag, a drawer front too short to grip, a niche shallower than the cooktop standard wants — comes back in notes and is built anyway: the rules advise, they never refuse. Only what has no geometry at all fails, and says why. kind + p: cabinet {w,h,d cm; t 15|18|25 mm; back mm; door hinged|sliding|drawers|none; doors; shelves; drawers; dividers; plinth; cooktop; top_cutout [x,y,w,d] cm from cabinet left-back; color; front finish} · slats {w,h cm; slat, thickness, gap mm; orientation vertical|horizontal; backing; finish} · countertop {length,depth,height,thickness cm; material; support none|legs|brackets; cutouts [{kind sink|cooktop|grommet, x, w?, d?}]} · cove {room or pts; type open|closed|inverted; ceiling, width, drop, slot cm; led} · shadow_gap {room or pts; ceiling, gap, depth cm; led} · sofa {length,depth,seat,back cm; arms straight|rounded|none; modules; color}. Place with at|wall(+along), angle, elev. Change a build: id + p with only new values (e.g. {"shelves":3}); a new size keeps its back where it was (anchor back|front|left|right|bottom|top|+x|-x|+y|-y|center). dry=true validates only.

Input Schema

TableJSON Schema

Name	Required	Description
`p`	No	Parameters (flat; everything has a default), see the tool description
`at`	No	Center on the plan (default: 0,0), or `wall` (+`along` cm) to back it onto a wall
`id`	No	Or an existing build's group id: `p` holds only what changes
`dry`	No	Only check and report, create nothing
`elev`	No	Bottom above the floor, cm (wall cabinets)
`kind`	No	New build: `cabinet`, `slats`, `countertop`, `cove`, `shadow_gap` or `sofa`
`room`	No	`cove`/`shadow_gap`: room id whose outline to follow
`wall`	No	Wall to back it onto, instead of `at`
`along`	No	With `wall`: center along it, cm from its start (default: the middle)
`angle`	No	Clockwise degrees
`anchor`	No	Changing a build's size: the face that stays where it is — `back` (default: joinery stands against a wall), `front`, `left`, `right`, `bottom`, `top` or a plan side `+x` `-x` `+y` `-y`; `center` grows around the middle

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	The build's group id (empty when dry)
`name`	Yes	Its name
`size`	Yes	[w, d, h] cm
`notes`	Yes	What a workshop would say about it
`parts`	Yes	Parts it is made of
`hardware`	Yes	Hardware it needs

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 24, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the destructiveHint annotation, the description discloses important behavioral traits: rules 'advise, they never refuse,' only geometry-less builds fail and say why, updates keep the back anchored by default, and dry=true validates only. This adds real context beyond the annotations and contains no contradiction.

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?

The description is dense but extremely efficient: the syntax section packs six build kinds with units and options into a compact notation, and the workshop-advice prose is a useful behavioral note, not padding. Output shape and behavior are front-loaded before the parameter grammar.

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?

All 11 top-level parameters are covered by schema or description, the p object is fully specified per kind, placement and update anchors are documented, dry mode is explained, and the return shape is explicitly stated. With an output schema present, nothing essential is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema description coverage is 100%, the description carries the entire meaning of the nested p object, enumerating per-kind fields, units (cm, mm), defaults, enums like t 15|18|25 and door hinged|sliding|drawers|none, plus update/anchor semantics. This goes far beyond the structural 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?

The description states a specific verb ('build') and resource ('joinery'), then enumerates six concrete build kinds: cabinet, slats, countertop, cove, shadow_gap, and sofa. It also specifies the returned shape ({id,name,size,parts,hardware,notes}), making it easy to distinguish from generic siblings like create or place.

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?

The description gives explicit usage patterns: new builds with kind + p, placement with at or wall(+along), angle, elev, updates with id + p, and validation with dry=true. It does not explicitly name alternatives or state when not to use it, so it does not reach a 5, but the context is clear.

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