AutoCAD MCP Pro

Overview Schema Source Related Servers Discussions Admin

Architecture: Door / Window

arch_opening

Creates a door or window opening in a drawn wall by id, redraws the wall cut, adds jambs, leaf or glazing, and records the opening for schedules.

Instructions

A door or a window in a wall already drawn, found by its id; the wall is redrawn cut.

The opening removes its width from both wall faces and each edge is closed by a jamb. A door is drawn open at 90° - its leaf as long as the opening is wide, hinged on hand, with a quarter-arc swing on the swing side; a window is a frame line on each face and two glazing lines between them. The opening's ACADMCP_ARCH record sits on the leaf or the frame, so a schedule reads it back.

Refused before anything is drawn or erased: a wall id not on the drawing (the drawn ids are named), an opening id already drawn, an opening that runs past its wall segment or straddles an axis vertex, one overlapping another opening on the same wall (both ids named), one that runs into a junction (the solid stretch it must fit in is named), an unknown kind, swing, hand or language.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`tag`	No	Schedule tag; default the next D1/W1 (en) or K1/P1 (tr)
`hand`	No	Doors: the hinge jamb, seen from the swing side facing the wall: left \| right	left
`kind`	No	door \| window	door
`lang`	No	Tag language: en \| tr	en
`sill`	No	Windows: sill height (schedule only, mm)
`wall`	Yes	Id of the drawn wall that hosts the opening
`poche`	No	Hatch the redrawn wall's cut faces
`swing`	No	Doors: in = to the left of the axis (inside a CCW perimeter) \| out	in
`width`	Yes	Clear width of the opening (mm)
`height`	No	Opening height (schedule only, mm)
`offset`	Yes	Distance along the wall's axis from its first point to the near jamb (mm)
`opening_id`	No	Opening id; default its tag

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.6.0Sep 28, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Far exceeds the minimal annotation (destructiveHint=false). It discloses the geometric effect (opening removes its width from both wall faces, jambs close each edge), door vs window rendering (90° leaf, quarter-arc swing; frame + two glazing lines), that the ACADMCP_ARCH record sits on the leaf/frame for schedule read-back, and a detailed set of refusal conditions. This is unusually rich behavioral disclosure for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the action ('A door or a window in a wall already drawn...'), then the geometry, then the refusal conditions. Dense but every clause carries information; the refusal enumeration is long yet each entry is a distinct failure mode.

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?

An output schema exists so return values need not be explained. For a complex 12-parameter mutation tool, the description covers geometry, validation, and persistence (xdata for schedules), leaving no material gap for an agent to call 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 baseline is 3, but the description adds genuine conceptual meaning: it explains that the door leaf length equals the opening width and that the hinge is on `hand` with the arc on the `swing` side, tying these params to drawn geometry beyond the schema text.

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+resource: it creates a door or window opening in an already-drawn wall identified by id, and redraws the wall cut. This is unmistakably distinct from arch_wall (which draws the wall) and from other geometry siblings.

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 prerequisite is explicit ('a wall already drawn, found by its id'), and the refusal list effectively delineates when the call will fail (wall id not on drawing, id already drawn, opening exceeds segment, overlaps another opening, runs into a junction). It does not name a sibling alternative explicitly, but the usage context is clear.

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

Deploy Server