AutoCAD MCP Pro

Overview Schema Source Related Servers Discussions Admin

Drawing: Deliver Auditable Bundle

drawing_deliver

Destructive

Create a hashed, validated DXF delivery bundle and verify save/reopen parity; optionally measure requirements to block delivery unless acceptance checks pass.

Instructions

Create a hashed, validated delivery bundle and verify DXF save/reopen parity.

The result status is success, failed_validation, failed_export or failed_acceptance. Failure intentionally keeps all generated artifacts for diagnosis.

The open document is never re-pointed or saved: the DXF is a copy (live: Document.Export), and the manifest records the document's id, revision, path and saved flag, the DXF version, every sha256 and the build. Parity reads the delivered DXF back and compares it with a fresh serialisation of the document over every space: zero changed, added or removed entities, the same counts per space, the same block definitions. Both sides are exports, so parity cannot see content the export itself loses (parity.scope says so); with requirements, parity.content_check is acceptance, the check that can.

With requirements every requirement is measured on the delivered DXF, read fresh and re-bound from the document; the bundle gains acceptance.json and acceptance.md, the result geometry_acceptance, drafting_quality (the unchanged score), artifact_integrity, coverage and blocking, and a requirement that does not pass, stale evidence or a dimension that disagrees with its geometry makes the status failed_acceptance whatever the score (failed_export and failed_validation are reported first). Refused before any work: requirements that do not parse (invalid_args).

Input Schema

Name	Required	Description
`formats`	No	Requested formats: dxf, pdf, png.
`expected`	No	Optional validator expectations for the drawing.
`min_score`	No	Minimum accepted quality score.
`output_dir`	Yes	Output directory for drawing artifacts and manifest.json.
`requirements`	No	Source requirements to verify (the drawing_verify_requirements shape). A requirement that does not pass makes the status failed_acceptance, whatever the drafting score.
`strict_critique`	No	Block delivery on every non-info critique issue.

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 (the drawing_verify_requirements shape). A requirement that does not pass makes the status failed_acceptance, whatever the drafting score."
+}

First observedv1.4.0Jul 29, 2026

TDQS

A4/5.0

Behavior5/5

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

Extremely rich beyond the single destructiveHint annotation: it enumerates the four status outcomes, explains that failure keeps artifacts for diagnosis, clarifies the open document is never re-pointed or saved (DXF is a copy), and details what the manifest and acceptance.json record. It also states parity's scope limitation and how requirements escalate to failed_acceptance, which are exactly the behavioral traits an agent cannot get from structured fields.

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?

Purpose is front-loaded and every sentence carries behavioral content, but the prose is dense and backtick-heavy (e.g. the parity.content_check clause) and harder to parse than needed. It is appropriately sized for a complex tool but could be tightened without losing signal.

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?

Given an output schema and annotations that only signal destructiveness, the description fills the critical gaps: status vocabulary, failure/artifact retention, parity limitations, and requirements acceptance flow. An agent has enough to call it correctly and interpret results.

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 real meaning: it explains that requirements trigger acceptance.json/acceptance.md and acceptance status regardless of score, and that unparseable requirements are refused as invalid_args. These semantics go beyond the schema's terse property descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb+resource: create a hashed, validated delivery bundle and verify DXF save/reopen parity. That is clearly a bundle/delivery operation distinct from single-format exports like drawing_export_dxf. It never explicitly names a sibling, so it stops short of the top band.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through the detailed behavioral description (bundle, parity, requirements acceptance) rather than stated. There is no explicit 'use this instead of drawing_export_dxf/drawing_finalize when...' and no exclusion conditions, so the agent must infer when this tool is the right choice over the many export/finalize siblings.

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

Deploy Server