AutoCAD MCP Pro

Overview Schema Source Related Servers Discussions Admin

Drawing: Refine

drawing_refine

Destructive

Critique and repair drawing entities in a bounded loop, preview proposed changes via dry run, and block stale updates using revision or handle fingerprints.

Instructions

Run a bounded, transaction-safe critique/repair/re-critique loop.

dry_run=True returns the plan with preview - the content revision and the exact fingerprint of every handle a planned repair touches - also when the score already meets min_score: threshold_met then says an apply at that min_score would stop before repairing. Applied with the preview's revision (expected_revision) and/or preconditions, the call is refused with kind stale_revision and nothing changed when the document moved since; the result then carries revision ({checked, after, interleaved}).

Input Schema

Name	Required	Description
`focus`	No	Critique focuses to repair; None runs all.
`dry_run`	No	Return the repair plan and its `preview` without modifying the drawing.
`min_score`	No
`max_rounds`	No
`preconditions`	No	A dry run's `preview.preconditions` ({handle, fingerprint} per entity a planned repair touches): repair only if each is unchanged; otherwise refused stale_revision and nothing is repaired.
`allowed_repairs`	No	Optional allowlist of repair focus names.
`expected_revision`	No	Repair only at this content revision (a dry run's `preview.revision`); otherwise refused stale_revision and nothing is repaired.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.7.0Oct 29, 2026

changedInput schema / properties / dry_run / description

Previous value: -"Return the repair plan without modifying the drawing."New value: +"Return the repair plan and its `preview` without modifying the drawing."

addedInput schema / properties / expected_revision

Added value: +{
+  "anyOf": [
+    {
+      "minimum": 0,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Repair only at this content revision (a dry run's `preview.revision`); otherwise refused stale_revision and nothing is repaired."
+}

addedInput schema / properties / preconditions

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "A dry run's `preview.preconditions` ({handle, fingerprint} per entity a planned repair touches): repair only if each is unchanged; otherwise refused stale_revision and nothing is repaired."
+}

First observedv1.4.0Jul 29, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations only declare destructiveHint=true, and the description adds real behavioral context beyond that: the loop is bounded by max_rounds, transaction-safe, and a stale_revision refusal changes nothing. It also explains that dry_run returns a preview even when the score already meets min_score, with threshold_met reporting that an apply would stop early. Missing: any mention of required permissions or the cost/time of a round.

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 core statement is front-loaded in one sentence, followed by the dry-run/apply contract grouped into coherent paragraphs. It is dense but largely earns its length; the trailing detail about the revision tuple ({checked, after, interleaved}) edges into output-schema territory.

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 7-parameter mutation tool with annotations, this covers what matters: the bounded loop, the preview-then-apply contract, the stale-revision refusal, and early stopping at min_score. An output schema exists, so detailed return shapes need not be restated here.

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 71% schema coverage the schema already documents most parameters, yet the description adds genuine semantics: expected_revision and preconditions are sourced from the dry run's preview.revision and preview.preconditions, and min_score governs early stopping via threshold_met. focus and allowed_repairs are left to their schema text.

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 first line states a specific action on a specific resource: a bounded critique/repair/re-critique loop over the drawing. 'Refine' is thereby distinguished from a pure critique tool by the repair and re-critique steps. It stops short of naming drawing_critique as the prerequisite sibling, so sibling differentiation is implied rather than stated.

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 conveyed indirectly: dry_run yields a plan plus preview, and applying with expected_revision/preconditions is refused when the document has moved. That sketches the intended two-step workflow (preview, then apply) but never says explicitly when to prefer this tool over drawing_critique or drawing_verify_requirements, nor when to skip it.

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

Deploy Server