AutoCAD MCP Pro

by U-C4N

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Material Hatch (ISO 128-50)

hatch_material

Hatch a cut face with the ISO 128-50 pattern to indicate its material in AutoCAD drawings.

Instructions

Section-hatch a cut face with the pattern ISO 128-50 gives its material.

Refusals: an unknown material (named, with the full list, before anything is drawn), neither boundary nor handles (or both), a boundary with fewer than three points, and a non-positive scale. With handles the loop is chained by boundary_from_entities, which the COM engine refuses (capability boundary_trace) - pass boundary on a live seat, or run headlessly. The HATCH layer is created first when the drawing lacks it: ActiveX refuses an entity on an absent layer and would otherwise leave the hatch orphaned on layer 0.

The payload states its own accuracy, as analysis_measure_entity does: area is the polygon actually hatched, boundary_area the exact area of the chained loop, and accuracy is "exact" or "flatten_tolerance" - an arc edge reaches entity_create_hatch as chords, so a curved cut face is hatched to within HATCH_FLATTEN_SAGITTA of itself rather than being replaced by its chord polygon. With handles, the outline boundary_from_entities draws is scaffolding and is deleted; traced reports its handle and whether the delete succeeded. A loop enclosing no area is refused instead of writing a HATCH of area 0.0.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`angle`	No	Replaces the material's own pattern angle (degrees) when given.
`layer`	No	Override the HATCH role layer.
`scale`	No	Multiplies the material's own pattern scale.
`handles`	No	Entities to chain into one closed loop instead of a boundary.
`boundary`	No	Closed boundary as [[x, y], ...] — at least three points.
`material`	No	Material name; an unknown one is refused with the list.	steel

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.6.0Sep 28, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations carry only destructiveHint=false, so the description bears the behavioral burden and does so richly: it enumerates every refusal (unknown material with list, neither/both boundary and handles, <3-point boundary, non-positive scale, zero-area loop), explains the HATCH layer auto-creation and why (ActiveX refuses entities on absent layers), and discloses the accuracy semantics of area/boundary_area/accuracy and the scaffolding deletion with `traced`.

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 one-line purpose before the dense constraint paragraphs, and every clause carries information (refusals, layer handling, payload accuracy). It is long but not padded; a slightly tighter grouping of the refusal list would improve it.

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 6-parameter creation tool with no required params, an output schema present, and only destructiveHint=false in annotations, the description covers refusals, prerequisites, capability limitations, and return-payload semantics — nothing an agent needs to call it correctly 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 schema already documents each field; the baseline would be 3. The description goes beyond it by explaining the mutual exclusivity of `boundary` vs `handles`, the chaining/scaffolding behavior of `handles`, and how `scale` and `material` validation interact with the refusals — genuine added meaning.

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 (section-hatch) and resource (a cut face) with the governing standard ISO 128-50, and implicitly separates itself from the generic siblings hatch_add_boundary and entity_create_hatch by tying the pattern to the material. An agent can tell what this produces without opening the schema.

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 strong conditional guidance: use `handles` only when the loop can be chained, but the COM engine refuses `boundary_from_entities` (capability `boundary_trace`), so pass `boundary` on a live seat or run headlessly. It does not explicitly contrast with hatch_add_boundary/entity_create_hatch, which keeps it from a 5.

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

Deploy Server