AutoCAD MCP Pro

Overview Schema Source Related Servers Discussions Admin

Understand: Verify Requirements

drawing_verify_requirements

Measures CAD geometry against source requirements and reports pass, fail, unknown, unsupported, or ambiguous status with evidence, plus verifies saved artifacts or delivery manifests.

Instructions

Measure source requirements on the CAD geometry and say, per requirement, pass / fail / unknown / unsupported / ambiguous - with the evidence.

Each requirement is bound to the real feature (by handle, feature tag, arch element, geometric predicate or DIMENSION; two equal candidates are ambiguous, never a pick) and measured on the geometry read from the drawing

never on a label, a stored model or the numbers that were typed in. A row gives target, measured, delta, tolerance basis, status, handles and source; counts gives the denominators (required = pass + fail + unknown + unsupported + ambiguous). status is pass only when every requirement passes; accepted also needs fresh evidence and no dimension_mismatch finding (a DIMENSION whose text or DIMLFAC disagrees with the geometry).

Modes:

requirements ({"units": ..., "items": [typed requirements]}, or a legacy {"dimensions": {...}} that is carried read-only and verifies nothing) or use_stored=True: measured on the current document. evidence records its id and content revision; a later revision makes the report stale.
artifact_path: measured on that saved file, read fresh (a .dwg on a live seat through a private copy), each feature re-bound from the current document - by handle while handles are stable, then by feature tag, then by geometry, two candidates being unknown - with rebinding and the before / after comparison in the report. A count or absence is counted afresh on the file, never carried over; a DIMENSION not found again there is a blocking dimension_unverified finding. provenance says whether the current document can be the file's source (at least half of the entities match unchanged); when not, a blocking artifact_source_mismatch finding, no comparison, and a handle-naming requirement is unknown.
manifest_path: re-hashes a drawing_deliver bundle and lists every artifact whose sha256 no longer matches (stale) or that is gone (missing).

report_path writes the report as JSON (.json) or Markdown (.md); nothing else is written, and the drawing never is.

Refused before any work: requirements together with use_stored (invalid_args); neither of them without manifest_path (missing_requirement); use_stored on a drawing that stores no requirements (missing_requirement); requirements that do not parse (invalid_args, the offending path named); a binding_policy other than strict / lenient; manifest_path together with requirements, use_stored or artifact_path; an artifact_path or manifest_path that does not exist; a manifest that is not a delivery manifest; a report_path not ending in .json or .md (only .json in manifest mode); a DWG artifact on the headless engine (capability dwg). A quarantined document is refused.

Input Schema

Name	Required	Description	Default
`use_stored`	No	Verify the set drawing_plan(persist_requirements=True) stored in the drawing.
`report_path`	No	Also write the report here: .json, or .md (Markdown; not in manifest mode).
`requirements`	No	Typed requirements ({units, items: [{id, quantity, target, features, provenance, source, ...}]}) or a legacy {dimensions: {...}} carried read-only.
`artifact_path`	No	A saved file of this drawing (.dxf; a .dwg only on a live seat) to measure instead of the open document - read fresh, never the model in memory.
`manifest_path`	No	A drawing_deliver manifest.json: re-hash its artifacts and list the stale and missing ones. Its own mode.
`binding_policy`	No	strict or lenient: how a requirement is bound to its feature. Two equal candidates are ambiguous under both.	strict

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.7.0Oct 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses that only the report is written and never the drawing, that evidence goes stale on a later revision, provenance thresholds (at least half of entities matching), and which conditions raise blocking findings (dimension_unverified, artifact_source_mismatch). Refusal reasons and error codes are enumerated up front, which is unusually complete behavioral disclosure.

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-loaded with the core purpose, then modes, then refusals — a sensible structure. Dense parenthetical asides make it heavier than it needs to be, but nearly every clause carries operational information an agent needs.

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?

With an output schema present plus annotations, this definition still explains row fields, counts denominators, the pass vs accepted distinction, and staleness rules. Nothing an agent needs in order to choose a mode and interpret the result 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: what binding_policy strict/lenient controls and that ambiguity rule applies under both, the legacy {dimensions: {...}} shape being carried read-only and verifying nothing, and the .json-only report restriction in manifest mode. That is meaningful semantics 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 and resource: measure source requirements against CAD geometry and return per-requirement pass/fail/unknown/unsupported/ambiguous with evidence. The requirement-bound-to-real-feature framing ('measured on the geometry ... never on a label, a stored model or the numbers that were typed in') clearly separates it from generic checks like validation_check or drawing_preflight.

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 Modes block gives explicit conditions for each of the four modes (requirements/use_stored on the current document, artifact_path on a saved file, manifest_path for a delivery bundle re-hash), plus a detailed list of refused argument combinations. It does not name sibling tools as alternatives, but mode selection and the preconditions are spelled out rather than implied.

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

Deploy Server