Skip to main content
Glama
U-C4N

AutoCAD MCP Pro

by U-C4N
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Drawing: Critique (premium quality checks)

drawing_critique
Read-only

Run quality checks on AutoCAD drawings as a production gate before finalizing; returns issues or empty array. Specify focus areas for targeted validation.

Instructions

Run premium-quality checks. Returns zero issues for a clean drawing.

Standard production gate: must return [] before drawing_finalize.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
focusNoSubset of: iso128, layer_color, dim_overlap, untrimmed_corner, duplicate_entities, construction_left, gdt, 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 drawing with no P&ID symbols), and 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 drawing with no mechanical part), and the architectural focuses arch_room_unlabelled, arch_wall_gap, arch_opening_clash (silent on a drawing with no ACADMCP_ARCH record), and the topology focuses topo_dangling_endpoint, topo_near_miss, topo_interior_crossing (network layers no P&ID or architectural focus reads). None = run all.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.6.0
    • changedInput schema / properties / focus / description
      Previous value: -"Subset of: iso128, layer_color, dim_overlap, untrimmed_corner, duplicate_entities, construction_left. None = run all."New value: +"Subset of: iso128, layer_color, dim_overlap, untrimmed_corner, duplicate_entities, construction_left, gdt, 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 drawing with no P&ID symbols), and 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 drawing with no mechanical part), and the architectural focuses arch_room_unlabelled, arch_wall_gap, arch_opening_clash (silent on a drawing with no ACADMCP_ARCH record), and the topology focuses topo_dangling_endpoint, topo_near_miss, topo_interior_crossing (network layers no P&ID or architectural focus reads). None = run all."
  2. First observedv1.4.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral value beyond that: it returns zero issues for a clean drawing and acts as a blocking gate before finalize, which is a workflow constraint the annotations cannot express.

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

Conciseness5/5

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

Three tight sentences, front-loaded with the action and then the gate condition; no filler.

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?

An output schema exists so return values need no explanation, and the description supplies the gating semantics and clean-drawing outcome. The only omission is any hint of the diagnostic focus areas or relationship to the other check tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single optional focus parameter is exhaustively enumerated in the schema, including silence behavior per focus family. The description adds nothing about focus, so the baseline 3 applies.

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?

States a specific verb+resource: runs premium-quality checks on a drawing and reports issues. It is clear enough on its own, but it never distinguishes itself from sibling diagnostics like validation_check, drawing_audit, drawing_preflight, or drawing_topology_check, leaving the agent to guess which checker applies.

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?

Gives a concrete usage rule: it is a standard production gate that must return [] before calling drawing_finalize. That is strong when-to-use context, though it offers no exclusions or explicit comparison to the other validation-flavored siblings.

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

Deploy Server

Other Tools