AutoCAD MCP Pro

Overview Schema Source Related Servers Discussions Admin

Drawing: Finalize (validate + save + screenshot)

drawing_finalize

Destructive

Validates and critiques the CAD drawing, saves it to disk, exports a screenshot, and returns the DWG path so you can confirm final quality before delivery.

Instructions

Premium completion gate: runs BOTH the 8-step validator AND the premium critique focuses (iso128, layer_color, dim_overlap, untrimmed_corner, duplicate_entities, construction_left, gdt, plus the P&ID focuses pid_dangling_line, pid_duplicate_tag, pid_incompatible_connection, pid_untagged_instrument, pid_illegal_tag, pid_unconnected_equipment — silent on a sheet with no P&ID symbols, plus the mechanical focuses mech_missing_centreline, mech_unhatched_section, mech_view_misaligned, mech_duplicate_dimension, mech_thread_unrepresented, mech_bom_balloon_mismatch — silent on a sheet with no mechanical part, plus the architectural focuses arch_room_unlabelled, arch_wall_gap, arch_opening_clash — silent on a sheet with no ACADMCP_ARCH record, plus the topology focuses topo_dangling_endpoint, topo_near_miss, topo_interior_crossing — on network layers no P&ID or architectural focus reads, silent on every sheet this server draws), then saves to disk, exports a screenshot, and returns the DWG path.

The validator and the critique share one read of the drawing - every entity of every space, model and paper, with no cap (one DXF export on the live engine). A drawing over MAX_QA_ENTITIES (default 2,000,000; 0 disables) is not read in part: the validator reports scan_incomplete and each entity check reports an issue with detail.code scan_incomplete, so the gate fails. A check that raises is an error issue with detail.code check_failed, never a clean result.

Raises ToolError if any validator 'error' finding is present, or if critique reports an 'error' (or, with strict_critique=True, any critique issue). Critique warnings are surfaced under payload['critique'] without failing the gate by default. A quarantined document is refused.

With requirements (the drawing_verify_requirements shape) every requirement is measured on the CAD geometry after the save: the payload adds geometry_acceptance (the full report), drafting_quality (the score, unchanged), artifact_integrity (the saved file's sha256 and reverified: every requirement measured again on the saved file, read fresh and re-bound by handle, feature tag, then geometry, with the before / after comparison; a saved file that cannot be re-read - a .dwg AutoCAD will not let us copy - fails the acceptance) and coverage, and a requirement that does not pass, stale evidence or a dimension that disagrees with its geometry raises failed_acceptance - a high drafting score never offsets it. Requirements that do not parse are refused before anything is saved (invalid_args).

Input Schema

Name	Required	Description
`expected`	No	Optional contract: {'part_type', 'helix_angle', 'must_have_bore', 'must_have_keyway'}
`save_path`	No	If given, save drawing here before validation. Pass full path including extension.
`requirements`	No	Source requirements to verify on the CAD geometry (the drawing_verify_requirements shape). A requirement that does not pass fails the gate (failed_acceptance), whatever the drafting score.
`screenshot_path`	No	If given, write PNG screenshot to this path.
`strict_critique`	No	If true, ANY critique issue (including warnings) fails the gate — the full premium discipline. Default false: only critique 'error' issues (e.g. leftover construction geometry) fail; warnings are surfaced in the payload.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.7.0Oct 29, 2026

addedInput schema / properties / requirements

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "items": {},
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Source requirements to verify on the CAD geometry (the drawing_verify_requirements shape). A requirement that does not pass fails the gate (failed_acceptance), whatever the drafting score."
+}

First observedv1.4.0Jul 29, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes far beyond the destructiveHint annotation: it discloses the failure model (validator 'error' raises ToolError, critique warnings only fail under strict_critique, quarantined documents refused), the MAX_QA_ENTITIES cap with scan_incomplete semantics, check_failed behaviour, and the post-save sha256/reverified acceptance flow. This is exactly the mutation-risk context an agent needs before calling a destructive tool.

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

Conciseness2/5

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

Front-loaded correctly with the gate summary, but then spends most of its length enumerating roughly thirty internal critique focus codes (iso128, pid_*, mech_*, arch_*, topo_*) that add nothing to tool selection or invocation. The signal-to-noise ratio is poor; the same information would fit in a third of the words.

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?

Given a destructive multi-effect tool with an output schema, the description covers preconditions, failure modes, requirement verification, and quarantine refusal, so an agent can call it safely. Minor gap: it never states whether the save is atomic or what happens to a pre-existing file at save_path, but the behavioural picture is otherwise complete.

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; the description earns above that by adding gate semantics the schema doesn't carry — e.g. requirements that fail or carry stale evidence raise failed_acceptance regardless of drafting score, and unparsable requirements are refused before anything is saved (invalid_args). The expected and screenshot_path parameters are left to the schema, which is acceptable given full coverage.

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 framing — 'Premium completion gate' — that names the composite action precisely: run the 8-step validator plus the premium critique, then save, export a screenshot, and return the DWG path. That distinguishes it from single-purpose siblings like validation_check, drawing_critique, drawing_save, and drawing_export_pdf without needing their 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 phrase 'Premium completion gate' and the strict_critique explanation make the usage context clear (final sign-off, not incremental work). However it never explicitly contrasts itself with drawing_preflight, drawing_deliver, or drawing_critique, so the agent must infer which gate to pick at which stage.

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

Deploy Server