Edits selected AutoCAD entities in one atomic step. Target by exact handles or a filter, then apply property changes, move, copy, rotate, scale, mirror, or erase.
Atomically edit entities selected by exact handles or a constrained filter. Supports properties, move, copy, rotate, scale, mirror, and erase.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| allowEmpty | No | ||
| operations | Yes |
Changes observed during successful MCP inspections.
v0.0.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the agent knows this mutates state. The description adds one genuine behavioral trait beyond that: 'Atomically', signaling all-or-nothing execution. It does not disclose side effects of erase, interaction with undo history, or what happens when zero entities match and allowEmpty is false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler, and the entity-selection mechanism is front-loaded ahead of the operation inventory.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with a nested, largely undocumented schema and no output schema, the description covers the headline capability but leaves meaningful gaps: the 50-operation cap, the meaning of allowEmpty, and the coordinate formats expected by move/copy/rotate/scale/mirror are all unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across three parameters with deep nesting, so the description must compensate and only partially does. It explains 'exact handles' vs 'constrained filter' for target and its operation-name list maps onto the operation discriminators, but allowEmpty, the filter fields (layer, types, window, colorIndex, textContains), and the geometry parameters (base, angle, factor, first/second, eraseSource) remain undocumented anywhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb (edit) and resource (entities), states the two selection modes (exact handles or constrained filter), and enumerates the supported operation set. It is clear what the tool does, though it never contrasts itself with the generic sibling cad_command, which an agent might reach for instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the description tells you the tool edits entities and how targets are selected, but gives no when-to-use guidance, no rule for choosing handles vs filter, and no exclusions relative to cad_draw, cad_command, or cad_undo.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.