AutoCAD MCP Pro

Overview Schema Source Related Servers Discussions Admin

Architecture: Plan From Spec

arch_plan_from_spec

Draw a complete architectural plan from a specification with walls, openings, stairs, rooms, dimensions, and schedules, validating everything before committing.

Instructions

A whole plan drawn inside one transaction: walls with their hosted doors and windows, stairs, room labels whose areas are measured off the walls just drawn, the exterior dimension chains and the door / window / room schedules.

Every item is validated before the transaction opens, so a refusal leaves the drawing untouched and names its path (walls[1].thickness: ..., rooms[0].area: ...). What only the drawing can refuse - a room point in no closed face - rolls the transaction back, and so does a cancelled request (the rollback runs under an anyio shield). The result carries each step's own result, the wall engine's omitted list and the three arch_* critique focuses run over the committed plan.

Refused by name: an unknown key, no walls, an unknown language or material, a non-finite or non-positive number, an arc segment in a wall axis, an opening that overlaps another or runs past its wall segment (both ids named), a typed room area (areas are measured, never typed), an unknown chain side or schedule kind, and a transaction that cannot be opened. Catalogue furniture, the grid and symbols are separate tools (arch_catalogue_insert, arch_grid, arch_symbol).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`spec`	Yes	{sheet: {intent, sheet_size, scale (denominator, 50 = 1:50)}, lang: 'en'\|'tr', poche: bool, walls: [{id, axis: [[x,y],...], thickness, justification, material, closed}], openings: [{id, wall, kind: 'door'\|'window', offset, width, swing, hand, sill, height, tag}], stairs: [{id, start, direction_deg, width, risers, riser_height, going, kind, turn}], rooms: [{id, name, number, at}], chains: {sides: ['bottom','left']}, schedules: [{kind: 'doors'\|'windows'\|'rooms', at: [x,y]}]}

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?

Annotations only carry destructiveHint=false, so the description carries the real burden and does so richly: validation happens before the transaction opens, a refusal names the offending path, drawing-level refusals and cancelled requests roll back (under an anyio shield), and the result includes each step's own result, the wall engine's omitted list, and three arch_* critique focuses. This is far beyond what the annotation discloses.

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?

The purpose is front-loaded in the first sentence and each subsequent paragraph adds distinct information (validation/rollback semantics, then refusals, then sibling exclusion). The long refusal enumeration is dense rather than padded, though it could be tightened into a more scannable list.

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?

For a complex, destructive-adjacent compound creation tool with sparse annotations, the description covers the transaction lifecycle, validation timing, rollback behavior, cancellation handling, result contents and sibling boundaries. An output schema exists and the description still notes what the result carries, so nothing an agent needs to invoke it correctly is missing.

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?

With a single parameter at 100% schema description coverage the baseline is 3, but the description genuinely enriches the spec beyond the schema text: it explains that room areas are measured off the walls just drawn and never typed, and enumerates refusal conditions tied to specific spec fields (arc segment in a wall axis, overlapping openings with both ids named, unknown chain side or schedule kind).

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?

Opens with a specific verb and resource: a whole plan drawn inside one transaction, then enumerates exactly what is produced (walls, hosted doors/windows, stairs, room labels with measured areas, dimension chains, schedules). It also explicitly separates itself from siblings by naming arch_catalogue_insert, arch_grid and arch_symbol as distinct tools, so an agent can route correctly 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?

The description makes clear this is the one-call path for an entire plan and names the adjacent tools that handle catalogue furniture, grid and symbols separately, which is genuine routing guidance. It stops short of an explicit when-to-use-this-vs-incremental-arch_wall/arch_opening statement, so an agent must infer the bulk-vs-piecemeal tradeoff.

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

Deploy Server